Search results for "contribute to wiki"

kdudka pushed to coreutils (f33). "Resolves: #1919775 - expr: fix invalid read with unmatched $...$"

by notifications＠fedoraproject.org

Notification time stamped 2021-02-02 15:14:19 UTC From d5245cc71c67b66e42ee7efb29ae582253b94720 Mon Sep 17 00:00:00 2001 From: Kamil Dudka <kdudka(a)redhat.com> Date: Feb 02 2021 14:25:51 +0000 Subject: Resolves: #1919775 - expr: fix invalid read with unmatched $...$ --- diff --git a/coreutils-8.32-expr-unmatched-par.patch b/coreutils-8.32-expr-unmatched-par.patch new file mode 100644 index 0000000..1a82384 --- /dev/null +++ b/coreutils-8.32-expr-unmatched-par.patch @@ -0,0 +1,81 @@ +From 9618fb718b75920f37e5be2049ad1d0bb5c4a28c Mon Sep 17 00:00:00 2001 +From: Paul Eggert <eggert(a)cs.ucla.edu> +Date: Tue, 26 Jan 2021 09:23:54 -0800 +Subject: [PATCH] expr: fix bug with unmatched $...$ + +Problem reported by Qiuhao Li. +* doc/coreutils.texi (String expressions): +Document the correct behavior, which POSIX requires. +* src/expr.c (docolon): Treat unmatched $...$ as empty. +* tests/misc/expr.pl: New test. + +Upstream-commit: 735083ba24878075235007b4417982ad5700436d +Signed-off-by: Kamil Dudka <kdudka(a)redhat.com> +--- + doc/coreutils.texi | 14 ++++++++------ + src/expr.c | 9 +++++++-- + tests/misc/expr.pl | 3 +++ + 3 files changed, 18 insertions(+), 8 deletions(-) + +diff --git a/doc/coreutils.texi b/doc/coreutils.texi +index 2382a16..5b2bb2c 100644 +--- a/doc/coreutils.texi ++++ b/doc/coreutils.texi +@@ -13529,12 +13529,14 @@ second is considered to be a (basic, a la GNU @code{grep}) regular + expression, with a @code{^} implicitly prepended. The first argument is + then matched against this regular expression. + +-If the match succeeds and @var{regex} uses @samp{$} and @samp{$}, the +-@code{:} expression returns the part of @var{string} that matched the +-subexpression; otherwise, it returns the number of characters matched. +- +-If the match fails, the @code{:} operator returns the null string if +-@samp{$} and @samp{$} are used in @var{regex}, otherwise 0. ++If @var{regex} does not use @samp{$} and @samp{$}, the @code{:} ++expression returns the number of characters matched, or 0 if the match ++fails. ++ ++If @var{regex} uses @samp{$} and @samp{$}, the @code{:} expression ++returns the part of @var{string} that matched the subexpression, or ++the null string if the match failed or the subexpression did not ++contribute to the match. + + @kindex $ @r{regexp operator} + Only the first @samp{\( @dots{} $} pair is relevant to the return +diff --git a/src/expr.c b/src/expr.c +index e134872..0616a42 100644 +--- a/src/expr.c ++++ b/src/expr.c +@@ -721,8 +721,13 @@ docolon (VALUE *sv, VALUE *pv) + /* Were $...$ used? */ + if (re_buffer.re_nsub > 0) + { +- sv->u.s[re_regs.end[1]] = '\0'; +- v = str_value (sv->u.s + re_regs.start[1]); ++ if (re_regs.end[1] < 0) ++ v = str_value (""); ++ else ++ { ++ sv->u.s[re_regs.end[1]] = '\0'; ++ v = str_value (sv->u.s + re_regs.start[1]); ++ } + } + else + { +diff --git a/tests/misc/expr.pl b/tests/misc/expr.pl +index e45f8e7..e57f79d 100755 +--- a/tests/misc/expr.pl ++++ b/tests/misc/expr.pl +@@ -84,6 +84,9 @@ my @Tests = + # In 5.94 and earlier, anchors incorrectly matched newlines. + ['anchor', "'a\nb' : 'a\$'", {OUT => '0'}, {EXIT => 1}], + ++ # In 8.32, $ ... $ that did not match caused memory errors. ++ ['emptysub', '"a" : "\$b\$*"', {OUT => ''}, {EXIT => 1}], ++ + # These tests are taken from grep/tests/bre.tests. + ['bre1', '"abc" : "a\$b\$c"', {OUT => 'b'}], + ['bre2', '"a(" : "a("', {OUT => '2'}], +-- +2.26.2 + diff --git a/coreutils.spec b/coreutils.spec index d6980da..3f2be33 100644 --- a/coreutils.spec +++ b/coreutils.spec @@ -1,7 +1,7 @@ Summary: A set of basic GNU tools commonly used in shell scripts Name: coreutils Version: 8.32 -Release: 16%{?dist} +Release: 17%{?dist} License: GPLv3+ Url: https://www.gnu.org/software/coreutils/ Source0: https://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz @@ -31,6 +31,9 @@ Patch5: coreutils-8.32-new-fs-types.patch # rm: do not skip files upon failure to remove an empty dir (#1905481) Patch6: coreutils-8.32-rm-stray-skip.patch +# expr: fix invalid read with unmatched $...$ (#1919775) +Patch7: coreutils-8.32-expr-unmatched-par.patch + # disable the test-lock gnulib test prone to deadlock Patch100: coreutils-8.26-test-lock.patch @@ -284,6 +287,9 @@ rm -f $RPM_BUILD_ROOT%{_infodir}/dir %license COPYING %changelog +* Tue Feb 02 2021 Kamil Dudka <kdudka(a)redhat.com> - 8.32-17 +- expr: fix invalid read with unmatched $...$ (#1919775) + * Tue Jan 26 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild https://src.fedoraproject.org/rpms/coreutils/c/d5245cc71c67b66e42ee7efb29...

3 years, 4 months

Re: CPE Git Forge Decision

by Leigh Griffin

On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline <jeremy(a)jcline.org> wrote: > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote: > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <mkonecny(a)redhat.com> > > wrote: > > > On 03/04/2020 01:25, Jeremy Cline wrote: > > > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote: > > > > > The number of active developers on Fedora initiatives has gone > > > > > up > > > > > drastically since I joined the team in 2019. You are possibly > > > > > not > > > > > seeing that as the team have moved from a model of siloed work > > > > > on > > > > > multiple apps, swimming against the tid working 16 hour days, > > > > > to > > > > > working on team oriented initiatives to add real value to the > > > > > ecosystem. So the noise of working on multiple small things at > > > > > once > > > > > is not as loud as it was in 2018 which is giving that illusion. > > > > I'd always suspected my work added no real value, but never had > > > > the > > > > proof. I appreciate the validation . > Sorry I missed this among the thread splits and dozens of other replies. Ping me offlist if you have specific concerns as I do not believe my comment infers a lack of value in your work or any other contributor for that matter and the wealth of positive comments since is validating that your contributions were indeed most welcome and appreciative. If I did somehow infer that your work had no value, I do apologise, lets connect though if you have concerns. > > > > > > > > - Jeremy > > > I bow before you mighty Jeremy and the work you did. The fedora > > > messaging is really nice replacement of the fedmsg, although is not > > > used > > > by every application yet. > > > > > > I also want to thank you for handing me off the Anitya and > > > the-new-hotness. It helped me grow my wizard realm in Fedora > > > Universe. :-) > > > > I would also like to echo my appreciation of Jeremy and his work. In > > particular, anitya is one of the tools I literally rely on to keep > > track of my packages and keep them fresh. Without anitya, I would be > > unable to do so. And we've slowly started to see other distributions > > starting to rely on it too (Arch, Alpine, PLD, Mageia, openSUSE). > > > > So, thank you for building such an awesome tool, and thank you Michal > > for taking up the reigns after that. > > > > I can hardly take credit for anitya. pingou started it as far as I know > and the project has over 50 contributors to the code, not to mention > all the issues and work to map projects on release-monitoring.org > itself. > > I appreciate all the kind words from folks and I do know that my work > has, on occasion, provided more value than the trouble it caused. > > - Jeremy > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgriffin(a)redhat.com M: +353877545162 IM: lgriffin @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs> @redhatjobs <https://instagram.com/redhatjobs> <https://red.ht/sig>

4 years, 2 months

[fedora-arm] Re: Request for testing: Raspberry Pi 3 WiFi testing

by Zamir SUN

Hi Peter, Stefan, See in-line. On 12/22/18 10:47 AM, Peter Robinson wrote: >>> Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative >>> feedback. >>> >>> I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before >>> the update. But after the update and reboot, wifi disappeared. Moreover, >>> reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help. >> >> i assume you have a 3 B not a B+. From the PCB it is RPi 3B v1.2. >> >> Can you provide a complete dmesg? >> Sure, here it is. https://paste.fedoraproject.org/paste/TlsJIanigMq6JVfMgezzeA >>> >>> >>> [root@rpi3 ~]# ip a >>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN >>> group default qlen 1000 >>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>> inet 127.0.0.1/8 scope host lo >>> valid_lft forever preferred_lft forever >>> inet6 ::1/128 scope host >>> valid_lft forever preferred_lft forever >>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state >>> UP group default qlen 1000 >>> link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff >>> inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic >>> noprefixroute eth0 >>> valid_lft 3563sec preferred_lft 3563sec >>> inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute >>> valid_lft forever preferred_lft forever >>> [root@rpi3 ~]# nmcli device wifi list >>> [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" >>> [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware >>> from 2018-09-21 15:44 >>> [ 21.876808] platform regulatory.0: Direct firmware load for >>> regulatory.db failed with error -2 >>> [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 >>> [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 >>> [ 22.101025] usbcore: registered new interface driver brcmfmac >>> [ 32.708983] bluetooth hci0: Direct firmware load for >>> brcm/BCM43430A1.hcd failed with error -2 >>> [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found >> >> Interesting the wifi chip is found, so the devicetree bugfix is working. >> So this seems to be a different a issue. > > I've found on a lot of devices if you just reboot with the fix it > doesn't always work, a full unplug reset of the power generally makes > it work again. > I've read about the comments in that bug. And I do cold reboot it. By this I mean, each time I test it, I poweroff and then set the socket to off from my PDU, and then set to ON, so I believe this is a different story. >> Does Fedora provide the necessary Bluetooth firmware? > > No, because they're not upstream in linux-firmware and from the > discussion I've had with RPi foundation either they or Cyprus need to > do the redistribution bits so they can be added to linux-firmware so > all linux distros can benefit from the improved bluetooth. The BT does > work without it, but it is a lot more stable and gets proper MACs etc > with the newer firmware. > I have downloaded the firmware from Peter's blog. https://nullr0ute.com/2018/04/the-raspberry-pi-3-b-in-fedora/ >> Would be interesting to see what happends after providing the bluetooth >> firmware. >> As I mentioned above, I just tried download the firmware again and it makes no different. The console log is what I got after downloading the firmware. If you think this worth a separate bug to be tracked, or some more information I can provide, I would like to help. >> Regards >> Stefan -- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/

5 years, 5 months

Re: Fedora disconnection?

by Gain Paolo Mureddu

Jeff Spaleta escribió: > On Fri, Jul 25, 2008 at 2:45 PM, Gian Paolo Mureddu > <gmureddu(a)prodigy.net.mx> wrote: > >> There has been a heated discussion over several threads in >> www.fedoraforum.org about how disconnected some users feel from the >> development team, as well as a general "lack of direction" in Fedora's >> leadership. The latest of these discussions started about an article (posted >> a few months back here in the marketing list) about PackageKit and from >> there it spanned a rather heated discussion about Fedora and a perceived >> increasing developers<-->users gap. >> I just saw your reply, sorry for the late response. > > What exactly do the people who feel disconnected want? Will they be > content just knowing that their opinions are heard? Communication is a > project wide stumbling block. Developers get frustrated at just trying > to talk among themselves, we certainly aren't going to require that > all the developers try to track general user discussion lists and > forums. We can probably do a better job at communication, on a number > of fronts but such effort can only go so far. Rambling complaint > threads on a forum or even the mailing list are just going to get > ignored by the vast majority of people. Letting users pretend that > participating in these sorts of long discussion amongst themselves > will result in developer action is a disservice to everyone. > This poses an excellent question, one which answer I have not been able to properly put into words. Generally speaking it would seem as if an important number of users (or would be users) see Fedora as the mythical Hydra... A huge body (the community) with lots and lots of heads (projects) that sort of feel disconnected to one another; i.e. there still lacks a bit of cohesion. That is what I have been able to deduce after having participating in many more discussions that I care to remember about _what_ Fedora really is. The message here seems to be clear: The project home page seems to not be as successful as we might have thought once in regards to telling people (especially new users) what Fedora is all about... Sure for old timers the simple words "Fedora is a community driven project around a community...." etc, etc, may tell us exactly what it is, but it would seem as if many new comers are having a hard time grasping and understanding even the basic philosophy of Fedora. > Or is the an unspoken expectation in the discontented userbase that > popular userbase opinion is suppose to drive the direction of the > project? Let me dispel that right now. Popular userbase opinion will > not control the direction of any technology development that > individual contributors want to use. That is not going to change. > Here's the deal. Fundamentally Fedora runs on the power of its > contributor-base... not its userbase. If there are group of users who > feel they are not being served, they have the ability to organize and > get involved as contributors. We could do a better job of encouraging > those sorts of users to grow into contributors. > I know that about Fedora, and I know there are several levels at which users may contribute back to the project, the point is that this very message doesn't seem to be *reaching* the users. Common complaints include: * Scarcity of information available in the Wiki, by this I mean that not all the concepts seem (from user input) to be being covered. * Dispersion of information. Another common complaint is that there seems to be a lot of different "sites" covering all the different aspects of the distro, but there is lacking a central site which may explain (to a certain simple degree) what these other aspects *do* (I know we have some information regarding this in the Wiki, maybe it is not as exposed as it should? Maybe directly in the Overview section or link to a new page with information about projects and what they are?). > So knowing what should be done, really comes down to knowing what the > discontented users are expecting. > > -jef > > Exactly. Which is why I've thought about a liaison of sorts (Ambassador[s]) for the forums on-line community and Fedora-proper. It will take some investigating to find-out what do these users really expect... Which could in turn give place to have better means for feedback from users, not necessarily from this particular "arm" of the community. I myself some times have resented a sorts of careless attitude towards simple users from some community members. As if some contributors/developers/management/etc people really couldn't care less about who uses Fedora or what their opinions are. I know that isn't necessarily the case, but (besides myself) some other users have stated they've felt some kind of hostility in the official channels of communication. I know addressing individuals is not practical and a waste, and that's why Fedora moves in clusters of people with common interests. Like Paul suggests, maybe it would be a good time to conduct a usability study among Fedora users? I understand that Fedora advances through its contributors, but it's supported by its users.

15 years, 10 months

[389-devel] Re: Deref plugin entries == NULL #4525

by Pierre Rogier

Hi William, > It's a scenario we will need to fix via your BE work because of the MVCC transaction model that > LMDB will force us to adopt :) As I see things in the early phases the lmdb read txn will probably only be managed at the db plugin level rather than at backend level. That means that we will have the same inconsistency risk than today (i.e as if using bdb and the implicit txn). The txn model redesign you are speaking about should only occur in one of the last phases (once bdb does no more coexists with lmdb). It must be done because it could provide a serious performance boost for read operations (IMHO, In most cases we could avoid to duplicate the db data) But we should not do it while bdb is still around because of the risk of lock issue and excessive retries. Note I put a phasing section in https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-ph... explaining that. But I guess I should move it within Ludwig's document that englobs it. Pierre On Thu, Jan 14, 2021 at 12:01 AM William Brown <wbrown(a)suse.de> wrote: > > > > On 13 Jan 2021, at 21:24, Pierre Rogier <progier(a)redhat.com> wrote: > > > > Thank you Willian, > > So far your scenario (entry found when reading base entry but no more > existing when computing the candidates) is the only one that matches the > symptoms. > > It's a scenario we will need to fix via your BE work because of the MVCC > transaction model that LMDB will force us to adopt :) > > > And that triggered a thought: > > We cannot do anything for SUBTREE and ONE_LEVEL searches > > because the fact that the base entry id is not in the candidate may be > normal > > but IMHO we should improve the BASE search case. > > In this case the candidate list is directly set to the base entry id > > ==> if the candidate entry (in ldbm_back_next_search_entry) is not > found and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY > error .. > > I suspect that Mark has seen this email and submitted a PR to resolve this > exact case :) > > > > > > Pierre > > > > > > On Wed, Jan 13, 2021 at 1:45 AM William Brown <wbrown(a)suse.de> wrote: > > Hey there, > > > > https://github.com/389ds/389-ds-base/pull/4525/files > > > > I had a look and I can see a few possible contributing factors, but > without a core and the exact state I can't be sure if this is correct. It's > all just hypothetical from reading the code. > > > > > > The crash is in deref_do_deref_attr() which is called as part of > deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by > "./ldap/servers/slapd/result.c:1488: rc = plugin_call_plugins(pb, > SLAPI_PLUGIN_PRE_ENTRY_FN);" > > > > > > I think what's important here is that the search is conducted in > ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* > in a transaction. That means that while the single search in be_search() is > consistent due to an implied transaction, the subsequent search in > deref_pre_entry() is likely conducted in a seperate transaction. This > allows for other operations to potentially interleave and cause changes - > modrdn or delete would certainly be candidates to cause a DN to be remove > between these two points. It would be extremely hard to reproduce as a race > condition of course. > > > > > > A question you asked is why don't we get a "no such entry" error or > similar? I think that this is because build_candidate_list in ldbm_search.c > doesn't actually create an error if the base_candidates list is empty, > because an IDL is allocated with a value of 0 (no matching entries). this > allows the search to proceed, and there are no errors, and the result set > is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in > this process, but without looking further into it, my suspicion is that > entries of size 0 WONT return an error condition to internal_search_pb, so > it's valid for this to be empty. > > > > Anyway, again, this is just reading the code for 20 minutes, and is not > a complete in depth investigation, but maybe it's some ideas about what > happened? > > > > Hope it helps :) > > > > > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server > > SUSE Labs, Australia > > _______________________________________________ > > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-leave(a)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/389-devel@lists.fedoraproje... > > > > > > -- > > -- > > > > 389 Directory Server Development Team > > _______________________________________________ > > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-leave(a)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/389-devel@lists.fedoraproje... > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > _______________________________________________ > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave(a)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/389-devel@lists.fedoraproje... > -- -- 389 Directory Server Development Team

3 years, 4 months

Re: Heads-up / for discussion: dnf not working with 1G of RAM or less

by Brian (bex) Exelbierd

On Mon, Aug 29, 2022 at 5:24 AM Adam Williamson <adamwill(a)fedoraproject.org> wrote: > Hey folks! I apologize for the wide distribution, but this seemed like > a bug it'd be appropriate to get a wide range of input on. > > There's a bug that was proposed as an F37 Beta blocker: > https://bugzilla.redhat.com/show_bug.cgi?id=1907030 > > it's quite an old bug, but up until recently, the summary was > apparently accurate - dnf would run out of memory with 512M of RAM, but > was OK with 1G. However, as of quite recently, on F36 at least (not > sure if anyone's explicitly tested F37), dnf operations are commonly > failing on VMs/containers with 1G of RAM due to running out of RAM and > getting OOM-killed. I wonder if we should take another approach here. Assuming no serious bugs in dnf, rather than tuning dnf for low memory environments could we suggest those folks use Fedora Silverblue, CoreOS, or IoT? I use Fedora IoT on GCPs free tier offering and it is fine. I a, assuming `rpm-ostree install` doesn’t have this issue. Regards, bex > > There's some discussion in the bug about what might be causing this and > potential ways to resolve it, and please do dig into/contribute to that > if you can, but the other question here I guess is: how much do we care > about this? How bad is it that you can't reliably run dnf operations on > top of a minimal Fedora environment with 1G of RAM? > > This obviously has some overlap with our stated hardware requirements, > so here they are for the record: > > > https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/... > > that specifies 2GB as the minimum memory for "the default > installation", by which I think it's referring to a default Workstation > install, though this should be clarified. But then there's a "Low > memory installations" boxout, which suggests that "users with less than > 768MB of system memory may have better results performing a minimal > install and adding to it afterward", which kinda is recommending that > people do exactly the thing that doesn't work (do a minimal install > then use dnf on it), and implying it'll work. > > After some consideration I don't think it makes sense to take this bug > as an F37 blocker, since it already affects F36, and that's what I'll > be suggesting at the next blocker review meeting. However, it does seem > a perfect candidate for prioritized bug status, and I've nominated it > for that. > > I guess if folks can chime in with thoughts here and/or in the bug > report, maybe a consensus will emerge on just how big of an issue this > is (and how likely it is to get fixed). There will presumably be a > FESCo ticket related to prioritized bug status too. > > Thanks folks! > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Don't rush to reply to this email. Enjoy work/life balance. I read email once a day and am in the CE(S)T timezone. If you have an urgent email, ping me, and consider other mediums in the future. Brian "bex" Exelbierd (he/him/his) Business Strategist for Communities and Developers Red Hat Enterprise Linux @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com

1 year, 9 months

Re: To preview my pitch on Fedora Magazine

by suruchi dharma

Thanks, I'll check it out. And try to complete the article about as soon as possible. On Thu, 25 Apr 2019 at 13:15, Clement Verna <cverna(a)fedoraproject.org> wrote: > On Thu, 25 Apr 2019 at 09:25, suruchi dharma <dharmasuruchi(a)gmail.com> > wrote: > > > > Yes, I can try to do that. I will need some time to know more about it > and > > I'll try to complete this article. > > You can take a look at this for inspiration and to play around > https://github.com/fedora-infra/fpdc/blob/master/Makefile. Then you > can look into more details about the podman pod command. > > > > > On Thu, 25 Apr 2019 at 02:02, Paul W. Frields <stickster(a)gmail.com> > wrote: > > > > > Hi Suruchi, > > > > > > Are you interested in taking up this alternative article instead of > > > the one you proposed? Here's the outline already provided: > > > https://fedoramagazine.org/?p=24533&preview=1&_ppp=22ab981719 > > > > > > We can assign it over to you, if you are willing to write it. > > > > > > Paul > > > > > > On Wed, Apr 17, 2019 at 08:39:22AM +0200, Clement Verna wrote: > > > > Hi suruchi, > > > > > > > > we have already published an article about podman > > > > (https://fedoramagazine.org/running-containers-with-podman/) and I > > > > think most of your pitch was covered by this article. > > > > However we have another pitch about podman "How to replace > > > > docker-compose with podman" > > > > (https://fedoramagazine.org/?p=24533&preview=1&_ppp=3dcee04627) this > > > > was already approved by the editors but nobody is currently working > on > > > > it. So if you wish to work on it you are more than welcome. > > > > > > > > Also there is no need to send multiple emails to this mailing list > > > > asking for the same thing (I consider this to be spam), this mailing > > > > list is relatively low traffic so it might take more than few days to > > > > get an answer so please be patient :-). > > > > > > > > Thanks > > > > Clément > > > > > > > > On Wed, 17 Apr 2019 at 07:23, suruchi dharma < > dharmasuruchi(a)gmail.com> > > > wrote: > > > > > > > > > > My pitch is about Podman, which is container management > technology. It > > > is > > > > > to aware people about daemonless container management. > > > > > > > > > > On Wed, 17 Apr 2019 at 09:37, suruchi dharma < > dharmasuruchi(a)gmail.com> > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I want to contribute to Fedora Magazine. Preview link of my > pitch. > > > > > > > > > > > > > > > > https://fedoramagazine.org/?p=27396&preview=true&preview_id=27396#like-27396 > > > > > > > > > > > > > > > > https://fedoramagazine.org/?p=27394&preview=true&preview_id=27394#like-27394 > > > > > > The content is about Podman technology. > > > > > > Kindly look into this. > > > > > > > > > > > > Thank you! > > > > > _______________________________________________ > > Fedora Magazine mailing list -- magazine(a)lists.fedoraproject.org > > To unsubscribe send an email to magazine-leave(a)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/magazine@lists.fedoraprojec... >

5 years, 1 month

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

by K. M. Peterson

I'm going to reply to myself, after several more hours of digging, I discovered that although it wasn't true at the time I posted the above question, eventually, as with the original post from Lachlan Musicman <https://lists.fedorahosted.org/archives/users/463432472638105722575414590...>, the WebUI died, and that meant no self-service for the rest of the team. And that made it into an emergency. So, I fired up my LDAP editor (I've been using JXWorkBench) and went to eradicate all the traces of the failed replica. Which fixed the issue; and I'm fairly sure there aren't any lingering effects. I think. But this was the first time I've used the editor to actual effect any changes to things; and I'm going to post the underlying question that raised in a new thread... This seems to have bitten at least a few of us; I'd be happy to know how to file a bug if there's a useful contribution there. Thanks! On Sat, Jan 5, 2019 at 4:47 PM K. M. Peterson <kmp.lists(a)gmail.com> wrote: > Hate _hate_ to open old threads, but... > > I'm also seeing this. I've been trying to add another replica to our > topology (this would be on a different subnet than the current pair); the > ipa-replica-install command has been failing for various reasons that > I've been fixing or circumventing and I've just been re-spinning the new > server between each attempt to keep the environment clean. The latest > death was apparently because of an issue with /etc/openldap/ldap.conf > which I was debugging and was about to remove the server from IPA and reset > it. > > However, I'm not able to do so. All attempts are met with "ERROR: > invalid 'PKINIT enabled server': all masters must have IPA master role > enabled" - in fact, even poking around trying to do an ipa config-show > (on either of the current masters) just generates that error. I've also > tried uninstalling the replica and client on the new host, and it seems to > have completed successfully, but I can't re-enroll it either, so it's "dead > to the other masters", except... > > There is nothing I want to do at this point other than another iteration > on my problem adding another replica. There's no data on replica, nothing > is relying on it, and I've tried as hard as possible to make the > installation entirely vanilla. I haven't manually enabled PKINIT; > ipa-pkinit-manage status on the current masters says it's enabled. As > for the server roles, server-role-find shows the two current servers and > the new one; the latter's "role status" for CA Server is "absent". I've > had issues before where I've had to enumerate the RUVs and remove them > (done that). Just want the references to this to go away, so that I can > keep working towards the most minimal and concise installation. > > Any ideas on where I can go to get out of this situation? Many thanks! > > (Everything completely updated to *4.6.4-10.el7.centos, initial > installation was about one year ago, domain level 1; tried all the ipa > server del and ipa-replica-manage del suggestions which aren't working for > me this time, no AD integration...) > > On Tue, Nov 20, 2018 at 1:48 AM Brian Topping via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org> wrote: > >> Oh, forgot to mention, current domain level is `1`... >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to >> freeipa-users-leave(a)lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... >> >

5 years, 4 months

Re: [Ambassadors] Re: Fedora 9 CD/DVDs

by ElectroMech

Yes, It is always good to recognize a work done by the community people. Even if it is small contribution of CD / DVD or other monitory terms should be recognize. But need to check properly , and it a duty of Ambassadors. On Mon, Aug 4, 2008 at 10:27 PM, Francesco Ugolini < fugolini(a)fedoraproject.org> wrote: > > On Mon, 4 Aug 2008, Paul W. Frields wrote: > > On Mon, 2008-08-04 at 02:42 -0400, David Nalley wrote: >> >>> 2008/7/30 Paul W. Frields <stickster(a)gmail.com>: >>> >>>> On Wed, 2008-07-30 at 22:39 +0200, Gerold Kassube wrote: >>>> >>>>> LUCA ... >>>>> >>>>> Am Mittwoch, den 30.07.2008, 21:55 +0200 schrieb Luca Foppiano: >>>>> >>>>>> On Wed, 2008-07-30 at 21:28 +0200, Max Spevack wrote: >>>>>> >>>>>> I can help make sure that you get some Fedora 9 Live CDs. How many >>>>>>> do >>>>>>> you think you will need? >>>>>>> >>>>>> >>>>>> we wish to have about 1000 cd/dvds, but only just printed CD... >>>>>> in my previous email I meant I didn't want fedora spends money to >>>>>> print fedora 9 cds ;-) >>>>>> >>>>> ^^ >>>>> for sure?????? ONE Thousand DvDs???? We burned for Linuxtag with more >>>>> than 10.000 visitors, and three other events 600 .... >>>>> >>>> >>>> Gerold -- I don't know if this is on the Ambassadors areas of the wiki >>>> somewhere, but it's very useful information. If Ambassadors have some >>>> guidelines for how many pieces of media they should consider requesting, >>>> it helps in the overall budget planning as well. >>>> >>>> It may not be as simple as saying "1 CD for every {5,10,...} people." >>>> For some small events, it makes sense to have 1 piece of media for each >>>> person. For some larger ones, the ratio may need to be smaller if we >>>> want to stay within budget! >>>> >>>> This would be a useful thing to consider drafting and having the >>>> Ambassador community think about. I don't think it needs to be an >>>> absolute rule, but rather a guideline for planning. >>>> >>> >>> Indeed - we should add a field to the Events and Archived Events page >>> to denote money and media and swag handed out - that would be >>> tremendously useful for future planning. >>> >> >> This is an issue that FAMSCo should take up at their next meeting -- >> setting some guidelines for media production. The budget will be the >> biggest factor in the number of pieces of media available at an event. >> Therefore FAMSCo should be thinking about what portion of the money is >> sensible to spend on media for events. >> >> -- >> Paul W. Frields >> gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 >> http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ >> irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug >> >> > Ok, I'll add this in FAmSCo meeting agenda. I invite the interested persons > to join the discussion, it's important to understand you necessities, > starting from your voice. > > Regards > > Francesco Ugolini > > > -- > Fedora-ambassadors-list mailing list > Fedora-ambassadors-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-ambassadors-list > -- -- Nilesh Vaghela ElectroMech Redhat Channel Partner and Training Partner 16, Sun Rise complex, Nr. Mansi cross Road, Satellite Rd, Ahmedabad 25, The Emperor, Fatehgunj, Baroda. www.electromech.info

15 years, 10 months

pagure pushed to python-cffsubr (rawhide). "Update to 0.2.9 (close RHBZ#2017405) (..more)"

by notifications＠fedoraproject.org

Notification time stamped 2021-10-27 10:22:15 UTC From fcfee78a18251aa9d0c8281e752d557d16e4bc5a Mon Sep 17 00:00:00 2001 From: Benjamin A. Beasley <code(a)musicinmybrain.net> Date: Oct 26 2021 14:00:48 +0000 Subject: Update to 0.2.9 (close RHBZ#2017405) Add a man page for the new CLI entry point. --- diff --git a/.gitignore b/.gitignore index 091729a..f4105a8 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ /cffsubr-0.2.8.tar.gz +/cffsubr-0.2.9.tar.gz diff --git a/cffsubr.1 b/cffsubr.1 new file mode 100644 index 0000000..c792c3d --- /dev/null +++ b/cffsubr.1 @@ -0,0 +1,39 @@ +.TH CFFSUBR "1" "October 2021" "" "User Commands" +.SH NAME +.B cffsubr +\(en compress OpenType Font\(cqs CFF or CFF2 table by computing subroutines +.SH SYNOPSIS +.B cffsubr +.RB [ \-h ] +.RB [ \-o \ \fIOUTPUT_FILE \ |\ \-i ] +.RB [ \-f \ { 1 , 2 }] +.RB [ \-N ] +.RB [ \-d ] +.I input_file +.SH OPTIONS +.SS "POSITIONAL ARGUMENTS" +.TP +.I input_file +Input font file. +Must contain either CFF or CFF2 table +.SS "OPTIONAL ARGUMENTS" +.TP +.BR \-h ,\ \-\-help +Show a help message and exit. +.TP +.B \-o\ \fIOUTPUT_FILE\fR,\ \fB\-\-output\-file\ \fIOUTPUT_FILE +Optional path to output file. +By default, dump binary data to +.IR stdout . +.TP +.BR \-i ,\ \-\-inplace +Whether to overwrite the input file. +.TP +.B \-f\ \fR{\fB1\fR,\fB2\fR},\fB\ \-\-cff\-version\ \fR{\fB1\fR,\fB2\fR} +Output CFF table format version. +.TP +.BR \-N ,\ \-\-no\-glyph\-names +Whether to drop postscript glyph names when converting from CFF to CFF2. +.TP +.BR \-d ,\ \-\-desubroutinize +Don\(cqt subroutinize, instead remove all subroutines (in any). diff --git a/python-cffsubr.spec b/python-cffsubr.spec index c8d92ee..9837afa 100644 --- a/python-cffsubr.spec +++ b/python-cffsubr.spec @@ -1,13 +1,21 @@ %global srcname cffsubr Name: python-%{srcname} -Version: 0.2.8 -Release: 5%{?dist} +Version: 0.2.9 +Release: 1%{?dist} Summary: Standalone CFF subroutinizer based on the AFDKO tx tool +# The entire source is ASL 2.0, except the following, which are OFL (but are +# not packaged, so they do not contribute to the overall package License +# field): +# - tests/data/SourceSansPro-Regular.subset.ttx +# - tests/data/SourceSansVariable-Regular.subset.ttx +# See NOTICE. License: ASL 2.0 URL: https://pypi.org/project/%{srcname} Source0: %{pypi_source} +# Written for Fedora in groff_man(7) format based on the output of “cffsubr --help” +Source1: %{srcname}.1 BuildArch: noarch @@ -47,11 +55,14 @@ sed -r -i 's/(ext_modules=)/# \1/' setup.py # Remove bundled adobe-afdko: rm -rf external +cp -p '%{SOURCE1}' . + %build -%py3_build +%pyproject_wheel %install -%py3_install +%pyproject_install +%pyproject_save_files %{srcname} # Workaround to prevent a dangling symlink: install -d "%{buildroot}$(dirname '%{txbin}')" @@ -61,26 +72,39 @@ ln -s '%{txbin}' '%{buildroot}%{txbin}' ln -s '%{buildroot}%{txbin}' %{buildroot}/%{python3_sitelib}/%{srcname}/tx symlinks -c -o %{buildroot}/%{python3_sitelib}/%{srcname}/tx +install -t '%{buildroot}%{_mandir}/man1' -D -p -m 0644 '%{srcname}.1' + %check %if 0%{?fedora} == 33 # Fixing this would require an adobe-afdko update; see # https://github.com/adobe-type-tools/cffsubr/issues/13. -%global koption -k 'not (TestSubroutinize and test_non_standard_upem_mute_font_matrix_warning)' +k="${k-}${k+ and }not (TestSubroutinize and test_non_standard_upem_mute_font_matrix_warning)" %endif -%pytest %{?koption} +%pytest -k "${k-}" -%files -n python3-%{srcname} -%license LICENSE +%files -n python3-%{srcname} -f %{pyproject_files} +# pyproject-rpm-macros handles the LICENSE file; verify with “rpm -qL -p …” %doc README.md -%{python3_sitelib}/%{srcname} -%{python3_sitelib}/%{srcname}-%{version}-py%{python3_version}.egg-info + +# Symbolic link to the “tx” executable; we patched out building a separate copy +# for the Python package, so the Python build does not know about this and we +# must list it explicitly. +%{python3_sitelib}/%{srcname}/tx # This was just a workaround: %exclude %{txbin} +%{_bindir}/%{srcname} +%{_mandir}/man1/%{srcname}.1* + %changelog +* Tue Oct 26 2021 Benjamin A. Beasley <code(a)musicinmybrain.net> - 0.2.9-1 +- Update to 0.2.9 (close RHBZ#2017405) +- Add a man page for the new “cffsubr” CLI entry point + * Tue Oct 26 2021 Benjamin A. Beasley <code(a)musicinmybrain.net> - 0.2.8-5 - Drop python3dist(setuptools) BR because it is implied by pyproject-rpm-macros, and pyproject-rpm-macros BR because it is (now) implied by python3-devel +- Use the full set of pyproject-rpm-macros * Fri Jul 23 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.2.8-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild diff --git a/sources b/sources index 9d75b86..b1e9873 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -SHA512 (cffsubr-0.2.8.tar.gz) = 3792b3e6899004947a074a6750ff8dfa0c51f84609bf14bb25b2f94195c4842c3141254d265a638662657b252f32511e1d8948bfe89b893491d34b17975676f7 +SHA512 (cffsubr-0.2.9.tar.gz) = 600b6b63ad70e5f00da0f64dd1410d49af622ac923aea3346c904e47e490410a6205fc5b2c2ddc6c684af04face3c217a2c722141f67d5f8ce5b87543eb363e4 https://src.fedoraproject.org/rpms/python-cffsubr/c/fcfee78a18251aa9d0c82...

2 years, 7 months

Search results for query "contribute to wiki"