On Sat, Feb 17, 2024 at 6:32 PM Orion Poplawski wrote:
> simdjson is failing to build with GCC 14 on x86_64:
>
> /usr/bin/cmake -S/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4
> -B/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
> --check-build-system CMakeFiles/Makefile.cmake 0
On Wed, Feb 14, 2024 at 5:55 PM Tom Hughes via devel
wrote:
>
> On 14/02/2024 15:48, Richard W.M. Jones wrote:
> > On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> >> On 14/02/2024 14:54, Richard W.M. Jones wrote:
> >>
> >>> https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
On 14/02/2024 15:48, Richard W.M. Jones wrote:
On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
On 14/02/2024 14:54, Richard W.M. Jones wrote:
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
The answer is th
On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> On 14/02/2024 14:54, Richard W.M. Jones wrote:
>
> >https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
> >
> >I don't think what Tom is saying there is correct, or is it?
>
> The answer is that I'm wrong about it breaking thin
On 14/02/2024 14:54, Richard W.M. Jones wrote:
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not t
Am Do., 7. Sept. 2023 um 14:02 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> I'm testing the upgrade to F39, and I see the following:
>
> Installing group/module packages:
> tlwg-waree-fontsnoarch 0.7.3-9.fc39 fedora
> 250.3 KiB
>replacing thai-scalable-fonts-comm
On Thu, 13 Jul 2023 at 21:45, Miao, Jun wrote:
> Hi Guys,
>
>
>
> AFAIK, the Yocto Project is an open source collaboration project that
> provides tools, templates, and methods to help developers create custom
> Linux-based systems for embedded devices.
>
>
>
> My confusion is that:
>
>1. wha
On Mon, 2023-07-17 at 02:58 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > This is the wrong question, kinda. There is no detailed step-by-step
> > process. The process for creating a compose is, more or less, "push the
> > magic COMPOSE NOW" button. (Okay, there's a *bit* more t
Adam Williamson wrote:
> This is the wrong question, kinda. There is no detailed step-by-step
> process. The process for creating a compose is, more or less, "push the
> magic COMPOSE NOW" button. (Okay, there's a *bit* more to it than that,
> but not a lot). The SOP for it is
> https://docs.pagure
On Sun, 2023-07-16 at 15:24 -0400, Christopher wrote:
> >
> > There is more than one tool in use. The main build tool is Koji, but it
> > depends on other underlying tools such as Mock, DNF, RPM, etc. Also keep in
> > mind that in Fedora, all binaries are natively compiled, not cross-compiled
> >
Am 16.07.23 um 21:24 schrieb Christopher:
On Sun, Jul 16, 2023 at 7:30 AM Kevin Kofler via devel
wrote:
Miao, Jun wrote:
Hi Guys,
First of all, we are not all guys. (I happen to be one though.)
I would advise not to get too picky about this. The term "guys" isn't
necessarily gender-specif
On Sun, Jul 16, 2023 at 7:30 AM Kevin Kofler via devel
wrote:
>
> Miao, Jun wrote:
> > Hi Guys,
>
> First of all, we are not all guys. (I happen to be one though.)
I would advise not to get too picky about this. The term "guys" isn't
necessarily gender-specific. In its plural form, it has basical
Miao, Jun wrote:
> Hi Guys,
First of all, we are not all guys. (I happen to be one though.)
> AFAIK, the Yocto Project is an open source collaboration project that
> provides tools, templates, and methods to help developers create custom
> Linux-based systems for embedded devices.
>
> My confusi
Thanks to all respondents - an interesting discussion. I think I'm now
equipped to respond to upstream.
Bob
On Wed, 30 Nov 2022 at 08:15, Björn Persson wrote:
> Vitaly Zaitsev via devel wrote:
> > On 29/11/2022 17:33, Todd Zullinger wrote:
> > > One of reasons being that it's (at least slightly
Vitaly Zaitsev via devel wrote:
> On 29/11/2022 17:33, Todd Zullinger wrote:
> > One of reasons being that it's (at least slightly) easier to
> > notice a change to the public key / keyring when it's in
> > dist-git versus the lookaside cache
>
> It depends on public key format. Armored (ASCII f
On 29/11/2022 20:57, Neal Gompa wrote:
If they're ASCII armored format, then store them in Git, by all means.
Yep. The example[1] stores the keys in binary format. Missing --armor
option.
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_exceptions
--
Sincerely,
Vitaly Zait
On Tue, Nov 29, 2022 at 2:50 PM Vitaly Zaitsev via devel
wrote:
>
> On 29/11/2022 17:33, Todd Zullinger wrote:
> > One of reasons being that it's (at least slightly) easier to
> > notice a change to the public key / keyring when it's in
> > dist-git versus the lookaside cache
>
> It depends on pub
On Tue, Nov 29, 2022, at 3:24 AM, Bob Hepple wrote:
> Here's a question from one of my upstream devels. Not sure I understand
> exactly what he's asking but I thought I'd post here in the hope that
> someone can enlighten him (and me!).
>
> "... Arch supports signed git tags. I'm hoping Fedora
On 29/11/2022 17:33, Todd Zullinger wrote:
One of reasons being that it's (at least slightly) easier to
notice a change to the public key / keyring when it's in
dist-git versus the lookaside cache
It depends on public key format. Armored (ASCII format) vs. binary keys.
Storing binaries in Git
Vitaly Zaitsev via devel wrote:
> On 29/11/2022 09:24, Bob Hepple wrote:
>> "... Arch supports signed git tags. I'm hoping Fedora does too.
>
> On Fedora you must upload source tarball, its signature and public key to
> the Fedora look-aside cache
A minor expansion on that; the public key / upstr
On Tue, Nov 29, 2022 at 3:24 AM Bob Hepple wrote:
>
> Here's a question from one of my upstream devels. Not sure I understand
> exactly what he's asking but I thought I'd post here in the hope that someone
> can enlighten him (and me!).
>
> "... Arch supports signed git tags. I'm hoping Fedora d
On Tue, 29 Nov 2022 at 07:29, Björn Persson wrote:
>
> As to why the builders lack Internet access, I wasn't around when that
> was decided but it helps ensure that the source RPM packages actually
> contain the source code.
>
>
During the early days of packaging, there were a set of packages whi
Bob Hepple wrote:
> If we _do_ support "signed git tags" how do we code for it in the spec
> file?
As the builders lack Internet access, they can't pull directly from the
upstream Git repository. To verify a signed Git tag during the build,
it would be necessary to package up the whole Git reposit
Adding to what Vitaly has said:
The other question is where you get those signatures from. If upstream does not
sign tarballs any more then there is nothing to check, sadly.
In a source-git based workflow, or if you roll your own using rpkg or such, you
have the upstream source available so tha
On 29/11/2022 09:24, Bob Hepple wrote:
"... Arch supports signed git tags. I'm hoping Fedora does too.
On Fedora you must upload source tarball, its signature and public key
to the Fedora look-aside cache, because builders have no network access
for security reasons.
--
Sincerely,
Vitaly
That did it - thank you very much!
On 30/04/2022 23:26, Paweł Marciniak wrote:
I think you need
%pre -n
the same for
%preun %post %postun or all systemd macros will not work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
I think you need
%pre -n
the same for
%preun %post %postun or all systemd macros will not work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://d
Hello Remi, Thank you very much for your reply! I am a PHP user for years.
I like PHP very much except for breaking compatibility :P
How do you think about adding something similar to the following sentences
to naming scheme of PHP packaging guidelines[1]. I understand the preference
is to updat
Le 19/02/2022 à 13:58, Hirotaka Wakabayashi via devel a écrit :
Hello, I have a question about Fedora Package Naming.
php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version
by upstream. The latest version is 7.4.1.
https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzle
Hello Neal. Thank you for reply! I will firstly ask to update the main package.
I think it's ideal if Fedora users can always use the latest packages and they
don't use inactive(EOL?) packages naturally.
I don't completely understand the Fedora infra, but I am wondering if a mass
rebuild can sk
On Sat, Feb 19, 2022 at 7:59 AM Hirotaka Wakabayashi via devel
wrote:
>
> Hello, I have a question about Fedora Package Naming.
>
> php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version by
> upstream. The latest version is 7.4.1.
> https://src.fedoraproject.org/rpms/php-guzzlehtt
Am 25.01.22 um 21:22 schrieb Miro Hrončok:
If I assume correctlty that both python-augeas and python-boto3 are in RHEL
7,
yes.
this exception applies:
"""
>
The package exists in both Fedora and RHEL, but the packager wants to
ship it in EPEL under an alternative name (as required by EPEL
On 25. 01. 22 21:05, Felix Schwarz wrote:
Hi,
(I sent this to epel-devel but did not get any reply there so maybe
fedora-devel is a better place for this question even though this is about EPEL
packages?)
the packaging guidelines have a few excemptions for the package review process
[1]. I'
> So far there has been no action on the bug to get it reviewed.
> Does it usually take a while to get the review started?
Well, the thing is - there isn't really anyone obliged to review package
submissions.
Almost every single review is done by volunteers, using their free time.
> Do I need to
JT wrote on 2021/12/28 23:22:
I didn't find the BT that helpful... Although it's possible I've completely
forgotten everything I previously knew about gdb and I need to relearn
everything from the ground up.
I'm perplexed by the BT because the first of the steps it shows on the way
to the segfaul
I didn't find the BT that helpful... Although it's possible I've completely
forgotten everything I previously knew about gdb and I need to relearn
everything from the ground up.
I'm perplexed by the BT because the first of the steps it shows on the way
to the segfault is for main.cpp:79.
> (gdb) b
Is the backtrace not helpful in figuring out where to set up
breakpoints? As in, “gdb foo”, then “run”, wait for the crash, and type
“bt”?
The darktable development documentation suggests[1] the following to log
useful backtraces:
|$ gdb darktable ... crash dt here ... (gdb) set paginatio
On Mon, Nov 29, 2021 at 03:15:24PM -0500, Matthew Miller wrote:
> shown that the answer is "probably not, actually". And it's _really
> hard_ for me to go to Red Hat and say "hey, um, I know you're paying
> for this Gitlab contract we can use, but can you please do this huge
> project, with ongoing
* Daniel P. Berrangé:
> We do much the same in libvirt
>
> https://github.com/libvirt/libvirt-python/pull/4#issuecomment-662443409
>
> FWIW, there's no need to write a bot to achieve this - there's a
> a github action:
>
> https://github.com/apps/repo-lockdown
>
> you can simply enable for you
On Wed, Dec 01, 2021 at 11:40:43AM -0500, Matthew Miller wrote:
> On Wed, Dec 01, 2021 at 01:20:53PM +, Daniel P. Berrangé wrote:
> > Note the GNOME auto-closer provides a comment telling the user that the
> > primary repo is on gitlab and pointing them to where it is. Logging
>
>
> How hard
On Wed, Dec 1 2021 at 11:40:43 AM -0500, Matthew Miller
wrote:
How hard would it be to actually automatically mirror the PR?
It actually does that, but if you don't follow up on GitLab it's just
going to get closed, since PRs from new contributors are never good
enough to merge the first tim
On Wed, Dec 01, 2021 at 01:20:53PM +, Daniel P. Berrangé wrote:
> Note the GNOME auto-closer provides a comment telling the user that the
> primary repo is on gitlab and pointing them to where it is. Logging
How hard would it be to actually automatically mirror the PR?
--
Matthew Miller
F
On Mon, Nov 29 2021 at 04:22:42 PM -0600, Michael Catanzaro
wrote:
Well that would be what I was missing. I guess this should be much
less controversial, then, if it's OK for people to just continue
using dist-git forever and completely ignore src-git? Nobody is ever
required to use something
On Wed, Dec 01, 2021 at 02:12:29PM +0100, Miro Hrončok wrote:
> On 01. 12. 21 0:37, Michael Catanzaro wrote:
> > On Wed, Dec 1 2021 at 12:27:35 AM +0100, Emmanuel Seyman
> > wrote:
> > > How do people using this setup prevent people from submitting PR and
> > > issues to the Github mirror where th
On 01. 12. 21 0:37, Michael Catanzaro wrote:
On Wed, Dec 1 2021 at 12:27:35 AM +0100, Emmanuel Seyman
wrote:
How do people using this setup prevent people from submitting PR and
issues to the Github mirror where they cannot be applied/fixed?
For GNOME we just set up a bot that autocloses ever
On 01. 12. 21 13:03, Hunor Csomortáni wrote:
Packit developer and Source-git SIG member here, joining two days late
to this thread.
One important thing to call out: the source-git workflow is not
officially adopted by the Fedora Community. All the work that is
ongoing in this space is experiment
On Mon, Nov 29, 2021 at 7:09 PM Michael Catanzaro wrote:
>
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
>
> Fedora Council has already effectively stated tha
On Wed, Dec 1 2021 at 12:27:35 AM +0100, Emmanuel Seyman
wrote:
How do people using this setup prevent people from submitting PR and
issues to the Github mirror where they cannot be applied/fixed?
For GNOME we just set up a bot that autocloses every PR.
___
On Wed, Dec 01, 2021 at 12:27:35AM +0100, Emmanuel Seyman wrote:
> * Michel Alexandre Salim [30/11/2021 15:22] :
> >
> > At the risk of straying off-topic, an approach I really like (which is
> > in the spirit of Git being distributed) is to use an open source forge
> > primarily, with GitHub only
* Michel Alexandre Salim [30/11/2021 15:22] :
>
> At the risk of straying off-topic, an approach I really like (which is
> in the spirit of Git being distributed) is to use an open source forge
> primarily, with GitHub only as backup.
How do people using this setup prevent people from submitting P
On Mon, Nov 29, 2021 at 03:58:09PM -0500, Matthew Miller wrote:
> Whenever this topic has come up, I've see lots of this, except people don't
> say the first part out loud: "Of course _I_ use GitHub for most of my stuff,
> because of all of the advantages — but Fedora, Fedora should never." We
> ca
Daniel P. Berrangé wrote:
> Also bear in mind you can't actually forbid source git repositories
> on any platforms.
>
> Some maintainers already use source git repositories, they just don't
> happen to be blessed by the Fedora project. If what Fedora offers
> is kneecapped, the maintainers can ign
Daniel P. Berrangé wrote:
> It is more than just sysadmin time involved though. One of the most
> compelling parts of GitLab is its CI framework and the free runners it
> provides projects.
Any kind of CI support should be considered nice-to-have and not a required
feature of a git forge. You can
Stephen John Smoogen wrote:
> The second issue has been the general rule that Fedora systems run by
> infrastructure use Fedora Linux or RHEL. Packaging up all the ruby
> gems and various services needed is a large task and usually falls on
> someone like Neal Gompa to try a stab at it.
Even if it
Matthew Miller wrote:
> Nope! The Packit Service bot works just like a human packager and syncs
> back changes other packagers have made.
I do not see how that can work for things like conditionally-applied
patches. Unless you just drop them into src-git as patches, which entirely
defeats the po
Michael Catanzaro wrote:
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
IMHO (as a non-candidate), it is sad that this question has to be asked at
all: Fedora
On Mon, Nov 29, 2021 at 04:22:42PM -0600, Michael Catanzaro wrote:
On Mon, Nov 29 2021 at 04:42:18 PM -0500, Matthew Miller
wrote:
Nope! The Packit Service bot works just like a human packager and
syncs
back changes other packagers have made.
Well that would be what I was missing. I guess th
On Mon, Nov 29, 2021 at 03:25:29PM -0600, Michael Catanzaro wrote:
On Mon, Nov 29 2021 at 03:15:24 PM -0500, Matthew Miller
wrote:
source-git is intended to be
distributed and close to upstreams.
Interesting. Why? What you and David are both saying seems so weird to
me, I suddenly wonder if
On Mon, Nov 29, 2021 at 12:06:13PM -0600, Michael Catanzaro wrote:
> Hi, I have a question for the FESCo and Council candidates: do you support
> allowing Fedora src-git repositories to be hosted on gitlab.com, which a
> proprietary software git forge?
>
> Fedora Council has already effectively st
On Mon, Nov 29, 2021 at 03:25:29PM -0600, Michael Catanzaro wrote:
> On Mon, Nov 29 2021 at 03:15:24 PM -0500, Matthew Miller
> wrote:
> > source-git is intended to be
> > distributed and close to upstreams.
>
> Interesting. Why? What you and David are both saying seems so weird to me, I
> sudden
On Mon, Nov 29, 2021 at 03:15:24PM -0500, Matthew Miller wrote:
> On Mon, Nov 29, 2021 at 12:06:13PM -0600, Michael Catanzaro wrote:
> > Hi, I have a question for the FESCo and Council candidates: do you
> > support allowing Fedora src-git repositories to be hosted on
> > gitlab.com, which a propri
On Mon, Nov 29, 2021 at 04:22:42PM -0600, Michael Catanzaro wrote:
> Well that would be what I was missing. I guess this should be much
> less controversial, then, if it's OK for people to just continue
> using dist-git forever and completely ignore src-git? Nobody is ever
> required to use somethi
I echo your views and agree with you completely. FOSS implementations
should be used whenever available. - Ahmed Almeleh (Candidate for FESCo,
the youngest of them.)
On Mon, 29 Nov 2021 at 19:59, Fabio Valentini wrote:
> On Mon, Nov 29, 2021 at 7:06 PM Michael Catanzaro
> wrote:
> >
> > Hi, I h
On Mon, Nov 29 2021 at 04:42:18 PM -0500, Matthew Miller
wrote:
Nope! The Packit Service bot works just like a human packager and
syncs
back changes other packagers have made.
Well that would be what I was missing. I guess this should be much less
controversial, then, if it's OK for people t
On Mon, 29 Nov 2021 at 16:26, Michael Catanzaro wrote:
>
> > Could we set up open-source Gitlab and run that? Well, history has
> shown that the answer is "probably not, actually".
>
> I don't believe it. If GNOME and KDE and freedesktop.org and Debian and
> Purism can all do it, I'm pretty sure
On Mon, Nov 29, 2021 at 03:25:29PM -0600, Michael Catanzaro wrote:
> src-git is exclusively used for downstream Fedora packaging, so I
> don't expect upstreams to be interested at all, unless upstream
> developers are also the Fedora packagers, right? I'm also assuming
So, we do have a lot of sof
On Mon, Nov 29 2021 at 03:15:24 PM -0500, Matthew Miller
wrote:
source-git is intended to be
distributed and close to upstreams.
Interesting. Why? What you and David are both saying seems so weird to
me, I suddenly wonder if I am seriously misunderstanding something,
because I know you're re
On Mon, Nov 29, 2021 at 03:53:54PM -0500, David Cantrell wrote:
> coordinate their work. Even if you spend your time working solely
> upstream, src-git still ultimately goes through dist-git via PackIt as
> would existing package maintenance. dist-git therefore is the
> authoritative source of wh
On Mon, Nov 29, 2021 at 08:58:58PM +0100, Fabio Valentini wrote:
> interview, but it doesn't hurt to ask.
> I actually briefly mentioned this topic in my last interview for
> FESCo, one year ago (last paragraph, the "open question"):
> https://communityblog.fedoraproject.org/fesco-election-intervie
On Mon, Nov 29, 2021 at 12:06:13PM -0600, Michael Catanzaro wrote:
Hi, I have a question for the FESCo and Council candidates: do you
support allowing Fedora src-git repositories to be hosted on
gitlab.com, which a proprietary software git forge?
Fedora Council has already effectively stated t
On Mon, Nov 29, 2021 at 8:58 PM Fabio Valentini wrote:
>
> On Mon, Nov 29, 2021 at 7:06 PM Michael Catanzaro
> wrote:
> >
> > Hi, I have a question for the FESCo and Council candidates: do you
> > support allowing Fedora src-git repositories to be hosted on
> > gitlab.com, which a proprietary so
On Mon, Nov 29, 2021 at 12:06:13PM -0600, Michael Catanzaro wrote:
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
I am not one of these candidates, but I think
On Mon, Nov 29, 2021 at 7:06 PM Michael Catanzaro wrote:
>
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
>
> Fedora Council has already effectively stated tha
On Mon, Nov 29, 2021 at 7:05 PM Matthew Miller wrote:
> I mean... that would have been a good way to make sure everyone at least
> provided some answer, but I don't think we have (or should have) any rule
> against asking FESCo or Council people questions at other times.
I think asking FESCo or
> It's too late for the questionnaire, yes, but... too late to ask???
>
> I mean... that would have been a good way to make sure everyone at
> least
> provided some answer, but I don't think we have (or should have) any
> rule
> against asking FESCo or Council people questions at other times.
>
>
On Mon, Nov 29, 2021 at 10:19:53AM -0800, Gary Buhrmaster wrote:
> One should have proposed such a question during the period when such
> questions were being vetted. It is too late now that the questions asked
> were the decided, the responses made, and the election has begun. Perhaps
> you should
On Mon, Nov 29, 2021, 10:06 Michael Catanzaro wrote:
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
>
One should have proposed such a question
during the per
On Mon, Nov 29, 2021 at 2:35 AM Sergio Belkin wrote:
> Hi,
> I've been playing a bit with toolbox, what is it intended for?
>
> I understand that was intended primarily for immutable OS. But
> documentation says that it can be used on the Workstation edition too.
> AFAIK it's only useful if you d
Since we're talking about toolbox, is there a way to get rid of or change
the hexagon in the prompt after you enter a toolbox?
My google-fu failed me on that one.
That being said, I'm having way too much fun making custom toolbox images
for the devs at my workplace.
It's a pretty big hit here. H
Sergio Belkin kirjoitti 29.11.2021 klo 3.32:
Hi,
I've been playing a bit with toolbox, what is it intended for?
I understand that was intended primarily for immutable OS. But
documentation says that it can be used on the Workstation edition too.
AFAIK it's only useful if you don't want to mess u
On Mon, Nov 22, 2021 at 08:58:06AM +, Ankur Sinha wrote:
> On Sat, Nov 20, 2021 04:35:20 +, Globe Trotter via devel wrote:
> > Thank you, your answer makes sense and clarifies to me what is on the
> > instructions page. If I were editing the page, I would make sure that it
> > says somewh
On Sat, Nov 20, 2021 04:35:20 +, Globe Trotter via devel wrote:
> Thank you, your answer makes sense and clarifies to me what is on the
> instructions page. If I were editing the page, I would make sure that it says
> somewhere that we need to ssh in and then create the directories and
> per
Thank you, your answer makes sense and clarifies to me what is on the
instructions page. If I were editing the page, I would make sure that it says
somewhere that we need to ssh in and then create the directories and
permissions. the first part is not mentioned anywhere on that page.
Thanks aga
I am guessing that the public_html/ directory in your home directory
does not exist or does not have the read and/or execute bits set for all
users. Try:
$ ssh aa...@fedorapeople.org 'mkdir -p public_html; chmod 0755 public_html'
to make sure the directory exists with the correct permissions.
Hello Alfredo,
Thanks you for your kind reply! I will check the RDO's packages and submit
re-reviews.
Best Regards,Hirotaka Wakabayashi
On Monday, July 26, 2021, 5:45:17 PM GMT+9, Alfredo Moralejo Alonso
wrote:
Hi,
On Sat, Jul 24, 2021 at 6:24 AM Hirotaka Wakabayashi wrote:
Hell
Hi,
On Sat, Jul 24, 2021 at 6:24 AM Hirotaka Wakabayashi
wrote:
> Hello Alfredo,
>
> I would like to maintain the following retired packages that you have
> formerly
> maintained[1]. Upstream of each package is alive. I would be happy if you
> could tell me if you know additional issues with the
Thanks for the quick response! I've submitted a new build to rawhide
that fixes this.
Marty
On 7/7/21 12:46 PM, Paweł Marciniak wrote:
but do I also need to obsolete older versions of the
vim-syntastic-rnc subpackage?
Yes, you have to. See:
https://docs.fedoraproject.org/en-US/packaging-gu
PS. rnc subpackage is still built.
You should remove this line "#%add_subpackage -n rnc rnv" or replace with this
line "#%%add_subpackage -n rnc rnv"
Please note the additional percent sign.
You should also remove unnecessary files. e.g. "rm -r syntax_checkers/rnc"
And of course add obsoletes (se
> but do I also need to obsolete older versions of the
> vim-syntastic-rnc subpackage?
Yes, you have to. See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
___
devel mailing list -- devel@lists.fedo
On Wed, Jul 7, 2021 at 12:42 PM Martin Jackson wrote:
>
> Hello,
>
> I use and like vim-syntastic, so I took it from the orphan list.
>
> There is an open bug on it that led to its retirement, that the rnc
> subpackage fails to install because rnv is no longer available.
>
> It's straightforward e
On 5/28/21 10:39 AM, Richard Shaw wrote:
On Fri, May 28, 2021 at 9:32 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I understand that we should put "Obsoletes" statements in a spec file when
a package changes its name, so the package with the new name can replace the package with
On Fri, May 28, 2021 at 9:32 AM Steven A. Falco
wrote:
> I understand that we should put "Obsoletes" statements in a spec file when
> a package changes its name, so the package with the new name can replace
> the package with the old name.
>
> But how long should the Obsoletes statements be left
El jue, 27 may 2021 a las 19:45, Anita Zhang ()
escribió:
> "Scope" from that Wiki is referring to the scope section of the proposal (
> https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Scope). As of
> systemd 248 the missing features are landed so
> ManagedOOMMemoryPressureLimit= is now a
"Scope" from that Wiki is referring to the scope section of the proposal
(https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Scope). As of systemd
248 the missing features are landed so ManagedOOMMemoryPressureLimit= is now
available (this was named something else in 247).
On Mon, 2021-04-19 at 09:27 +0200, Ondrej Dubaj wrote:
>
>
> On Fri, Apr 16, 2021 at 3:30 PM David Cantrell
> wrote:
> > On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote:
> > >Hijacking this thread originally about
> > >https://fedoraproject.org/wiki/Changes/Autoconf_271
> > >
On Thu, Jan 28, 2021 at 08:05:45AM -0700, Orion Poplawski wrote:
> Is it possible to still do updates in side-tags for rawhide during the mass
> rebuild? What are the ramifications if any for this?
Should be fine.
If your packages aready were (re)built by mass rebuild, and you build
them in a s
On Thu, Jan 28, 2021 at 5:48 PM Miro Hrončok wrote:
>
> On 28. 01. 21 16:05, Orion Poplawski wrote:
> > Is it possible to still do updates in side-tags for rawhide during the mass
> > rebuild? What are the ramifications if any for this?
>
> I've just did so let's see.
>
> https://bodhi.fedoraproj
On 28. 01. 21 16:05, Orion Poplawski wrote:
Is it possible to still do updates in side-tags for rawhide during the mass
rebuild? What are the ramifications if any for this?
I've just did so let's see.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-675d1948a8
Note that the packages alrea
On Tue, Sep 8, 2020, 9:16 AM Kaleb Keithley wrote:
> I confess I'm a bit ignorant about how the ELN builds are going to be
> used. Especially the ELN builds of glusterfs and ceph.
>
> That aside—
>
> Red Hat ships GlusterFS and Ceph (RHGS and RHCS respectively) as products,
> and generally speaki
On Mon, 25 Nov 2019, Till Maas wrote:
On Mon, Nov 25, 2019 at 10:33:54AM -0500, Steven A. Falco wrote:
Yet according to koji, there is no build for fc31:
https://koji.fedoraproject.org/koji/packageinfo?packageID=avr-libc
I'm not saying that anything is wrong - I'm just curious as to why the
1 - 100 of 326 matches
Mail list logo