On Saturday, July 25, 2020 11:31:18 PM MST Qiyu Yan wrote:
> John M. Harris Jr 于 2020年7月26日周日 下午2:25写道：
>
> > On Saturday, July 25, 2020 10:29:45 PM MST Qiyu Yan wrote:
> > > But your advice to use dnf is not a good one. The thread is about the
> >
> > topic
> >
> > > of using silverblue, dnf w
John M. Harris Jr 于 2020年7月26日周日 下午2:25写道：
> On Saturday, July 25, 2020 10:29:45 PM MST Qiyu Yan wrote:
> > But your advice to use dnf is not a good one. The thread is about the
> topic
> > of using silverblue, dnf won't apply here unless with fedora-toolbox and
> > using rpm-ostree to layering n
On Saturday, July 25, 2020 10:29:45 PM MST Qiyu Yan wrote:
> But your advice to use dnf is not a good one. The thread is about the topic
> of using silverblue, dnf won't apply here unless with fedora-toolbox and
> using rpm-ostree to layering needs reboot and is not the best-practice.
What does Si
John M. Harris Jr 于 2020年7月26日周日 下午1:02写道：
> On Saturday, July 25, 2020 4:28:19 PM MST Erich Eickmeyer wrote:
> > On 7/25/2020 3:39 PM, John M. Harris Jr wrote:
> > > The solution is to run the following command:
> > >
> > > `dnf install $package`. This will install your arch's version of the
> >
On Saturday, July 25, 2020 4:28:19 PM MST Erich Eickmeyer wrote:
> On 7/25/2020 3:39 PM, John M. Harris Jr wrote:
> > The solution is to run the following command:
> >
> > `dnf install $package`. This will install your arch's version of the
> > package you're looking for.
>
> John,
>
> This is n
On Sat, Jul 25, 2020 at 11:52 PM Kevin Fenzi wrote:
>
> On Sun, Jul 26, 2020 at 11:18:40AM +0800, Qiyu Yan wrote:
> > John Doe 于2020年7月26日周日 上午10:47写道：
> > >
> > > > I don't have a machine of other than x86_64 so I can't test, but does
> > > > this
> > > > mean fedora's flatpak source is totally
On Sun, Jul 26, 2020 at 11:18:40AM +0800, Qiyu Yan wrote:
> John Doe 于2020年7月26日周日 上午10:47写道：
> >
> > > I don't have a machine of other than x86_64 so I can't test, but does this
> > > mean fedora's flatpak source is totally unavailable on secondary arches?
> > > Or
> > > I have any misunderstand
John Doe 于2020年7月26日周日 上午10:47写道：
>
> > I don't have a machine of other than x86_64 so I can't test, but does this
> > mean fedora's flatpak source is totally unavailable on secondary arches? Or
> > I have any misunderstanding of flatpak image building?
>
> It looks like it, but it shouldnt be har
> I don't have a machine of other than x86_64 so I can't test, but does this
> mean fedora's flatpak source is totally unavailable on secondary arches? Or
> I have any misunderstanding of flatpak image building?
It looks like it, but it shouldnt be hard to add aarch64 and ppc64le, just a
matter o
John Doe 于 2020年7月26日周日 上午3:23写道：
> Hello!
>
> I am looking for the place where Fedora flatpaks are built, as explained
> here: https://docs.fedoraproject.org/en-US/flatpak/concepts/#_oci_images
>
> I could find a koji task that builds one:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=
On 7/25/2020 3:39 PM, John M. Harris Jr wrote:
> The solution is to run the following command:
>
> `dnf install $package`. This will install your arch's version of the package
> you're looking for.
John,
This is neither helpful, nor warranted. It is clear that you don't like
the direction that F
On Saturday, July 25, 2020 12:23:11 PM MST John Doe wrote:
> Hello!
>
> I am looking for the place where Fedora flatpaks are built, as explained
> here: https://docs.fedoraproject.org/en-US/flatpak/concepts/#_oci_images
> I could find a koji task that builds one:
> https://koji.fedoraproject.org
On Sat, 25 Jul 2020 at 09:11, Jeff Law wrote:
> On Fri, 2020-07-24 at 22:29 +0100, Richard W.M. Jones wrote:
> > Just upgraded a development machine to:
> >
> > binutils-2.34.0-10.fc33.x86_64
> > gcc-10.1.1-2.fc33.x86_64
> > glibc-2.31.9000-21.fc33.x86_64
> >
> > and a very simple C compile (non-
Hello!
I am looking for the place where Fedora flatpaks are built, as explained here:
https://docs.fedoraproject.org/en-US/flatpak/concepts/#_oci_images
I could find a koji task that builds one:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1520683 - and there we
can observe in orchest
On Fri, Jul 24, 2020 at 05:00:16PM +0200, Fabio Valentini wrote:
> > BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <=
> > 0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004
> > because there used to be a different libelf implementation (with a dead
> > upstream
On Sat, Jul 25, 2020 at 11:25 AM Jeff Law wrote:
>
> On Sat, 2020-07-25 at 10:46 +0100, Peter Robinson wrote:
> > On Sat, Jul 25, 2020 at 10:35 AM Neal Gompa wrote:
> > > Hey all,
> > >
> > > So I was trying to update libseccomp last night, and I was able to
> > > build it for everything except a
On Sat, 2020-07-25 at 10:46 +0100, Peter Robinson wrote:
> On Sat, Jul 25, 2020 at 10:35 AM Neal Gompa wrote:
> > Hey all,
> >
> > So I was trying to update libseccomp last night, and I was able to
> > build it for everything except aarch64 on Rawhide because it says the
> > compiler can't build
On Sat, Jul 25, 2020 at 09:31:31AM -0400, Eric Wood wrote:
> Same thing happens to me on a Ubuntu install. Very annoying. I haven't
> dug into figuring it out either.Eric
I have similar problem with .js files, completely unusable (with .py
files it works fine BTW, 4-space indents, just the way I
Same thing happens to me on a Ubuntu install. Very annoying. I haven't dug into
figuring it out either.Eric
Original message From: Richard Shaw
Date: 7/25/20 9:22 AM (GMT-05:00) To: Development discussions related to
Fedora Subject: vim has lost it's damn mind
After upgrad
After upgrading to Fedora 32 I've noticed when editing files, especially
spec files that vim does some crazy jumps/indents that it didn't do before.
Right now I'm pressing i to insert a line before a Requires: and when I hit
enter it jumps to the next line (fine) but with 4 indents and one space..
On Sat, Jul 25, 2020 at 01:11:25AM -0600, Jeff Law wrote:
> So at a high level ar makes a call to lrealpath. That naturally goes through
> the
> PLT. The PLT stub loads the value out of the GOT and jumps to it. The
> problem
> is the entry in the GOT is *zero* when it should be pointing to the
On Sat, Jul 25, 2020 at 10:35 AM Neal Gompa wrote:
>
> Hey all,
>
> So I was trying to update libseccomp last night, and I was able to
> build it for everything except aarch64 on Rawhide because it says the
> compiler can't build executables[1].
>
> Looking a bit closer, it looks like the compiler
Hey all,
So I was trying to update libseccomp last night, and I was able to
build it for everything except aarch64 on Rawhide because it says the
compiler can't build executables[1].
Looking a bit closer, it looks like the compiler stack is out of sync
again with annobin.
Is there anything that
On Fri, 2020-07-24 at 22:29 +0100, Richard W.M. Jones wrote:
> Just upgraded a development machine to:
>
> binutils-2.34.0-10.fc33.x86_64
> gcc-10.1.1-2.fc33.x86_64
> glibc-2.31.9000-21.fc33.x86_64
>
> and a very simple C compile (non-LTO) is now segfaulting:
>
> make[3]: Entering directory '/ho
24 matches
Mail list logo
