https://bodhi.fedoraproject.org/updates/FEDORA-2019-6f5be50fd9
Two other ceph updatest submitted around the same time moved to testing
okay.
If it is stuck, can someone with appropriate privs please kick it.
Thanks,
--
Kaleb
___
devel mailing list --
W dniu 10.09.2019 o 06:47, Raphael Groner pisze:
> Hi,
>
>> My package requires libxslt.
>
> You're obviously not alone with this issue. The better question is *why* the
> package as a commonly used library got orphaned, propably silently without
> warning (at least I can not find any announcem
Hi,
> My package requires libxslt.
You're obviously not alone with this issue. The better question is *why* the
package as a commonly used library got orphaned, propably silently without
warning (at least I can not find any announcement, officially).
Regards
Raphael
___
On Monday, September 9, 2019 12:44:42 PM MST DJ Delorie wrote:
> "vvs vvs" writes:
>
> > Ok, now I see that Fedora is just for activists. If I'm not one of
> > them then I don't deserve any possibility to use it and should blame
> > myself. Thanks for explaining it to me.
>
>
> I think you're o
On Monday, September 9, 2019 1:00:51 PM MST Anderson, Charles R wrote:
> On Mon, Sep 09, 2019 at 07:57:20PM -, vvs vvs wrote:
>
> > Well, thanks for sharing.
> >
> > I'm not complaining that nobody wants to fix things for me. I'm
> > complaining because there is no possibility to fix things m
On Monday, September 9, 2019 12:09:49 PM MST vvs vvs wrote:
> Ok, now I see that Fedora is just for activists. If I'm not one of them then
> I don't deserve any possibility to use it and should blame myself. Thanks
> for explaining it to me.
Please don't let the hostilities of this list get to you
On Monday, September 9, 2019 11:58:08 AM MST vvs vvs wrote:
> I would argue that it might be difficult to distinguish work needed to find
> out if it was i686 specific when there already is similar bug on x86_64.
> Also, it's difficult to rate bug importance for most users. As I've already
> said t
On Monday, September 9, 2019 8:36:45 AM MST vvs vvs wrote:
> There is no either right or wrong stance here. We are discussing possible
> alternatives to "just drop it" attitude.
> What work should be done? Please, be more specific. Right now I'm running a
> i686 userland and it works. If I would
On Monday, September 9, 2019 8:51:48 AM MST Tomasz Torcz wrote:
> On Mon, Sep 09, 2019 at 04:39:47AM -0700, John M. Harris Jr. wrote:
>
> > > >
> > > > This is precisely the issue with GNOME entirely. It assumes the user
> > > > shouldn't
> > > > have a choice, that some designers know best.
> >
On Monday, September 9, 2019 10:29:23 AM MST Bruno Wolff III wrote:
> On Mon, Sep 09, 2019 at 14:52:07 -,
> vvs vvs wrote:
>
> >May be there are more interested people that we know, but they are not
> >reading that list. There will just be just every man for himself and
> >Fedora has failed
On Monday, September 9, 2019 6:42:35 AM MST Solomon Peachy wrote:
> On Mon, Sep 09, 2019 at 06:22:46AM -0700, John M. Harris Jr. wrote:
> > The system I'm sending this email from only has 4 GiB of memory in
> > total. Does that mean that this system makes ASLR completely
> > ineffective? Should thi
On Mon, Sep 09, 2019 at 11:49:17PM +0200, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fed
Dear all,
You are kindly invited to the meeting:
Modularity Team (weekly) on 2019-09-10 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting of the Modularity Team.
More information available at: [Modularity Team
Docs](https://docs.pagure.o
I filed an issue offering to take this and a few others.
Sent from ProtonMail mobile
\ Original Message
On Sep 9, 2019, 7:31 PM, < mcatanz...@gnome.org> wrote:
>
>
>
> On Mon, Sep 9, 2019 at 4:49 PM, Miro Hrončok
> <[mhron...@redhat.com][mhroncok_redhat.com]>
> wrote:
> > li
On Tue, 2019-09-10 at 02:41 +0200, Kevin Kofler wrote:
> Miro Hrončok wrote:
> > openvswitch aconole, chrisw, orphan, 0 weeks ago
> > tgraf, tredaell
>
> This one is a dependency of NetworkManager, so surely it should not go away.
> (Or is the
On Mon, 2019-09-09 at 14:14 +, Fedora compose checker wrote:
> No missing expected images.
>
> Compose FAILS proposed Rawhide gating check!
> 21 of 45 required tests failed, 19 results missing
> openQA tests matching unsatisfied gating requirements shown with **GATING**
> below
> Unsatisfied
Miro Hrončok wrote:
> openvswitch aconole, chrisw, orphan, 0 weeks ago
> tgraf, tredaell
This one is a dependency of NetworkManager, so surely it should not go away.
(Or is the plan to drop support for it from NM?) So can either one of the
ex
On Mon, Sep 9, 2019 at 4:49 PM, Miro Hrončok
wrote:
libxslt orphan, veillard 0
weeks ago
Looks pretty important, any takers?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an ema
On 9/9/19 3:35 PM, vvs vvs wrote:
I didn't answered your other question because I've answered the same question
several times already. Yes, I have a use cases where I'll get a severe
performance hit if I was not careful. And this is related to available memory
and swapping. And I can't afford
On 9/9/19 3:35 PM, vvs vvs wrote:
> So, you are insisting that Koji just doesn't work without any assistance? And
> that it's impossible to build a separate i686 repository without affecting
> all others?
We used to build secondary architectures separately, using koji-shadow
to chase the primary
Elliott Sales de Andrade writes:
> On Mon, 9 Sep 2019 at 18:02, David Sommerseth wrote:
>>
>> On 09/09/2019 23:49, Miro Hrončok wrote:
>> > The following packages are orphaned and will be retired when they
>> > are orphaned for six weeks, unless someone adopts them. If you know for
>> > sure
>>
Oh, brother...
So, you are insisting that Koji just doesn't work without any assistance? And
that it's impossible to build a separate i686 repository without affecting all
others? And that you can't exclude that architecture for a specific package? If
that's the case then it's very different fr
On 9/9/19 4:49 PM, Miro Hrončok wrote:
libxslt orphan, veillard 0 weeks ago
This is a big one...
@Daniel, can you take it over as primary maintainer?
Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscr
On Mon, 9 Sep 2019 at 18:02, David Sommerseth wrote:
>
> On 09/09/2019 23:49, Miro Hrončok wrote:
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know for sure
> > that the package should be retired, please do
On 09/09/2019 23:49, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/H
On 9/9/19 2:15 PM, vvs vvs wrote:
I said it already several times, that I don't need volunteers to fix things for
me! I just need an already built repository which I could just use and fix
things myself if needed. But Fedora is refusing to provide such repository
which was built automatically
And if I don't use those packages, then why should I be unable to use
everything else just because there are some small problems? Especially because
there are not much users of that architecture anyway.
That happens all the time already and I see no big problem with that. If these
packages affe
And why people are not reading all the answers? That was a rhethorical question.
I said it already several times, that I don't need volunteers to fix things for
me! I just need an already built repository which I could just use and fix
things myself if needed. But Fedora is refusing to provide s
I'm going to deprecate clalsadrv, because it has been deprecated and
replaced by zita-alsa-pcmi upstream.
Nothing depends on it in rawhide:
dnf --disablerepo='*' --enablerepo=rawhide --enablerepo=rawhide-source
repoquery --whatdepends clalsadrv --alldeps
reports only
clalsadrv-devel-0:2.0.0-20.
And I thought that should be obvious, silly me. Just kidding.
Of course I would do it if there were no better choice. I'm just struggling to
find out if there is no other possibility whatsoever. There might be reasons
why Fedora is just unable to keep it updated that I don't know. And of course
On 9/9/19 12:47 PM, vvs vvs wrote:
I don't even know anyone whom I could address. I'm already spent too much time
on that list trying to convince everyone that I'm ready to take all the burden
of using unsupported packages, but was told that it's against Fedora policies.
What much could I do?
On Mon, Sep 09, 2019 at 07:57:20PM -, vvs vvs wrote:
> Well, thanks for sharing.
>
> I'm not complaining that nobody wants to fix things for me. I'm complaining
> because there is no possibility to fix things myself. After removing i686
> repository I'm either should start building it myself
Well, thanks for sharing.
I'm not complaining that nobody wants to fix things for me. I'm complaining
because there is no possibility to fix things myself. After removing i686
repository I'm either should start building it myself or switch to another
distribution. I'm not trying to hurt anyone'
I don't even know anyone whom I could address. I'm already spent too much time
on that list trying to convince everyone that I'm ready to take all the burden
of using unsupported packages, but was told that it's against Fedora policies.
What much could I do?
As for using i686 userland just look
"vvs vvs" writes:
> Ok, now I see that Fedora is just for activists. If I'm not one of
> them then I don't deserve any possibility to use it and should blame
> myself. Thanks for explaining it to me.
I think you're overreacting a bit, but there is some truth in this.
Fedora is created and mainta
No, just a memory bound behavior. It will eat all memory that you throw on it
and one gigabyte just for starters. After that it will start swapping but some
careful optimization management can avoid that. But if it starts swapping there
will be a major performance hit. And it isn't mission criti
https://fedoraproject.org/wiki/Changes/Jekyll4
== Summary ==
This Change will bring the latest version of Jekyll, 4.0.0 (or later), to
fedora. It includes minor backwards-incompatible changes, but also brings a lot
of clean-ups and bug fixes compared to the 3.8 branch.
== Owner ==
* Name: [[Use
https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
== Summary ==
This change will toggle the default firewalld backend from iptables to
nftables. All of firewalld's primitives will use nftables while direct
rules continue to use iptables/ebtables.
== Owner ==
* Name: [[User:erig
On 9/9/19 11:15 AM, vvs vvs wrote:
BTW, that just means that Fedora is refusing to provide much needed services
even to a people who are ready to accept most of that support burden themselves
and I'm one of them.
I don't understand how you keep completely missing the point. No one is
"refus
On Mon, May 20, 2019 at 4:33 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
>
After working to implement this proposal over the summer, we have
discovered two issues with the Taiga UI that make this proposal more
annoying to community contributors than I'm w
I don't have time to search for it right now, but there is a law which states
that no matter how much resources you already get they will be stretched thin
anyway.
I did upgrades many times but every time it was proved that it still wasn't
enough. It's a useless rat race. We have much more impo
On 9/9/19 11:47 AM, Martin Kolman wrote:
Yeah, I've recently switched an old Atom A330[0] based system[1] with 2 GB of
RAM (that's the maximum it supports)
from a 32-bit to a 64-bit based distro (after finding out it can actually run
64-bit code).
It has been running just fine and actually feel
On Mon, Sep 09, 2019 at 19:01:59 -,
vvs vvs wrote:
No, I don't think so. I'm using some (non Fedora related) applications which
use every bit of available memory. It's a bit stressed just as it is, but
losing additional couple of megabytes for no useful reason will be too much a
hit. And
On Mon, Sep 09, 2019 at 07:09:49PM -, vvs vvs wrote:
> Ok, now I see that Fedora is just for activists. If I'm not one of
> them then I don't deserve any possibility to use it and should blame
> myself. Thanks for explaining it to me.
If I may quote from the landing page on https://getfedora
Ok, now I see that Fedora is just for activists. If I'm not one of them then I
don't deserve any possibility to use it and should blame myself. Thanks for
explaining it to me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send a
On Mon, Sep 09, 2019 at 07:01:59PM -, vvs vvs wrote:
> No, I don't think so. I'm using some (non Fedora related) applications
> which use every bit of available memory. It's a bit stressed just as
> it is, but losing additional couple of megabytes for no useful reason
> will be too much a hi
On 9/9/19 4:39 AM, John M. Harris Jr. wrote:
on my RHEL 7 deployments, where some of my users prefer GNOME), and where
users request that I install gnome-tweak-tool for them so that they can make
basic preference changes which just aren't available otherwise.
Just in case you aren't aware, gnom
On Mon, Sep 09, 2019 at 08:47:24PM +0200, Martin Kolman wrote:
> Yeah, I've recently switched an old Atom A330[0] based system[1] with
> 2 GB of RAM (that's the maximum it supports) from a 32-bit to a 64-bit
> based distro (after finding out it can actually run 64-bit code). It
> has been runnin
In the interests of not making this thread a bunch longer, I am just
going to answer a number of things here in one place.
On 9/7/19 11:44 AM, Victor V. Shkamerda wrote:
> I totally agree with that view. Making such decisions without public
> discussion is not respecting user's freedom of choice.
No, I don't think so. I'm using some (non Fedora related) applications which
use every bit of available memory. It's a bit stressed just as it is, but
losing additional couple of megabytes for no useful reason will be too much a
hit. And I can't change their code, because that codebase is big an
I would argue that it might be difficult to distinguish work needed to find out
if it was i686 specific when there already is similar bug on x86_64. Also, it's
difficult to rate bug importance for most users. As I've already said that I
was completely satisfied with the status quo and it was a b
On Mon, 2019-09-09 at 13:27 -0500, Bruno Wolff III wrote:
> On Mon, Sep 09, 2019 at 18:06:02 -,
> vvs vvs wrote:
> > Yes, thanks. Sadly, I see that I have no choice but to switch to another
> > distribution even though I'm using 64-bit
> > CPU. It's just that the memory can't be upgraded an
On Mon, Sep 09, 2019 at 06:23:18PM -, vvs vvs wrote:
> But how do you now that I'm not fixed it myself and forgot to post on
> that list? Or that I'm even just used to live with that bug and just
> don't want to spend all my time chasing it?
It's simple; if you (and everyone else) doesn't sa
On Mon, Sep 09, 2019 at 18:23:18 -,
vvs vvs wrote:
Anyway, I'm not expecting that something will change because of that
discussion. It is just bad that the interests of users are of a lower priority
then some purely bureaucratic reasons.
It isn't happening because of bureaucratic reaso
On 9/9/19 7:52 AM, Miro Hrončok wrote:
> On 09. 09. 19 16:40, Fabio Valentini wrote:
>> Did some policy change occur which I am not aware of, or is bodhi just
>> misconfigured again for branched?
>
> https://pagure.io/fedora-infrastructure/issue/8161
>
Turns out this was a typo in a variable. Sh
On Mon, Sep 09, 2019 at 18:06:02 -,
vvs vvs wrote:
Yes, thanks. Sadly, I see that I have no choice but to switch to another
distribution even though I'm using 64-bit CPU. It's just that the memory can't
be upgraded and buying new computer just to keep running Fedora is not viable.
It's 1
But how do you now that I'm not fixed it myself and forgot to post on that
list? Or that I'm even just used to live with that bug and just don't want to
spend all my time chasing it?
I'm pretty sure that I can point point out bugs in official Fedora repository
that were dormant for several year
I am a little beyond the 8-week window for the "no-hassle" unretire, so I need
a new review for the fastbit packagethat I retired a few months ago. It's
already in the Fedora git tree. I have it building cleanly again and would
liketo resurrect it. I have gone over the review items locally,
On Mon, Sep 09, 2019 at 17:55:06 -,
vvs vvs wrote:
First of all thanks for the link. It just proves that the SIG's expectations
were too high.
If I understand it all correctly, the main reason to drop i686 repo was the
mailing list inactivity? Is that right? So everyone interested in tha
Thanks for the suggestion. But I'm sure that I don't need so much bureaucracy
just to run my little errands. If that's how Fedora is operated, than it won't
make much difference for me to just using another distribution.
BTW, that just means that Fedora is refusing to provide much needed service
On Mon, Sep 09, 2019 at 05:55:06PM -, vvs vvs wrote:
> If I understand it all correctly, the main reason to drop i686 repo
> was the mailing list inactivity? Is that right? So everyone interested
> in that architecture is now deprived from using it on Fedora because
> some formalities were n
Am 09.09.19 um 18:39 schrieb Antonio Trande:
> New `libb2-0.98.1` will be released by 10 days on Rawhide.
> Packages currently involved:
>
> $ repoquery --release rawhide --disablerepo=* --enablerepo=fedora-source
> --enablerepo=updates-source --whatrequires libb2-devel
>
> Last metadata expirati
Yes, thanks. Sadly, I see that I have no choice but to switch to another
distribution even though I'm using 64-bit CPU. It's just that the memory can't
be upgraded and buying new computer just to keep running Fedora is not viable.
It's 12 years old, is in good condition and I'm completely satisf
First of all thanks for the link. It just proves that the SIG's expectations
were too high.
If I understand it all correctly, the main reason to drop i686 repo was the
mailing list inactivity? Is that right? So everyone interested in that
architecture is now deprived from using it on Fedora bec
On Mon, Sep 09, 2019 at 14:52:07 -,
vvs vvs wrote:
May be there are more interested people that we know, but they are not reading
that list. There will just be just every man for himself and Fedora has failed
to recognize that.
This requires time and effort too. Nobody will appear just b
Il giorno lun, 09/09/2019 alle 19.02 +0200, alcir...@gmail.com ha
scritto:
> Hello.
> My name is Alessio.
> FAS: alciregi
Welcome to Fedora...
> I work as an unpretentious sysadmin, mostly as the "IT guy".
> I've been a long-time user/administrator of *nix systems, starting
> with
> Red Hat Linux
I'd like to unretire ladspa-swh-plugins in rahwide, f31 and f30,
because it is a dependency of some packages I maintain:
ams
jamin
It's a dependency of pulseeffects too.
I will file a review request ASAP, I have already made a scratch build
in rawhide:
https://koji.fedoraproject.org/koji/taskinf
Hello.
My name is Alessio.
FAS: alciregi
I work as an unpretentious sysadmin, mostly as the "IT guy".
I've been a long-time user/administrator of *nix systems, starting with
Red Hat Linux 6 in 1999. I've been a user of other distributions as
well. Yeah, just a user.
After some years of distro hop
On Mon, Sep 9, 2019 at 4:52 PM Miro Hrončok wrote:
>
> On 09. 09. 19 16:40, Fabio Valentini wrote:
> > Did some policy change occur which I am not aware of, or is bodhi just
> > misconfigured again for branched?
>
> https://pagure.io/fedora-infrastructure/issue/8161
Ah, so I remembered correctly,
On Mon, Sep 09, 2019 at 03:36:45PM -, vvs vvs wrote:
>
> What work should be done? Please, be more specific.
Deja vu… please read https://pagure.io/fesco/issue/1737
(Proposal: i686 SIG needs to be functional by F27 release date or we
drop i686 kernel from F28) with all the links.
--
Tomas
vvs vvs píše v Po 09. 09. 2019 v 15:44 +:
> I'm happy with any support no matter how it is defined. In fact I
> didn't get very much support from Fedora either over more than 20
> years, so my expectations are quite low.
You seem to have a rather narrow view of support. It's not just someone
w
Hi all.
New `libb2-0.98.1` will be released by 10 days on Rawhide.
Packages currently involved:
$ repoquery --release rawhide --disablerepo=* --enablerepo=fedora-source
--enablerepo=updates-source --whatrequires libb2-devel
Last metadata expiration check: 0:00:02 ago on lun 9 set 2019, 18:31:15
No I didn't, but I must be sure that you speak on behalf of everyone before
making my choices.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://do
So, if I'd start to use Debian i686 instead of Fedora or will use ARM32 device
instead of ARM64 the world will be a safer place? Also, I was told that
maintaining i686 Fedora code base myself would be fine, but in the same time
I'm told that it's not acceptable from the safety point of view. Why
On Mon, Sep 09, 2019 at 03:44:49PM -, vvs vvs wrote:
> If there is something more relevant than freedom of choice, then there
> is no point arguing further, because I value community relations over
> any technical reasons.
You seem to forget that "freedom of choice" also applies to those
wo
swift-lang has been fixed with a patch and scratch builds on F32 build
properly:
https://koji.fedoraproject.org/koji/taskinfo?taskID=37348234
On 4 Sep 2019, at 17:39, Miro Hrončok wrote:
Hello packagers!
The following packages failed to build on Fedora 32 with Python 3.8
and they still requ
On Mon, Sep 09, 2019 at 04:39:47AM -0700, John M. Harris Jr. wrote:
> > >
> > > This is precisely the issue with GNOME entirely. It assumes the user
> > > shouldn't
> > > have a choice, that some designers know best.
> >
> >
> > Yes, precisely *your* issue. I’d rather someone think for me as fa
I'm happy with any support no matter how it is defined. In fact I didn't get
very much support from Fedora either over more than 20 years, so my
expectations are quite low.
If there is something more relevant than freedom of choice, then there is no
point arguing further, because I value commun
OLD: Fedora-Rawhide-20190908.n.0
NEW: Fedora-Rawhide-20190909.n.1
= SUMMARY =
Added images:1
Dropped images: 8
Added packages: 5
Dropped packages:21
Upgraded packages: 101
Downgraded packages: 0
Size of added packages: 88.39 MiB
Size of dropped packages
There is no either right or wrong stance here. We are discussing possible
alternatives to "just drop it" attitude.
What work should be done? Please, be more specific. Right now I'm running a
i686 userland and it works. If I would be able to build the whole repository
myself I'm pretty sure that
On Mon, Sep 09, 2019 at 02:41:15PM -, vvs vvs wrote:
> OTOH, if Debian has resources to maintain the support for at least
> next five years it means one of two things: either they have more
> resources than Fedora, or something is wrong with your assessment.
Or (3) Debian defines "support" q
- Original Message -
> From: "vvs vvs"
> To: devel@lists.fedoraproject.org
> Sent: Monday, September 9, 2019 4:52:07 PM
> Subject: Re: Fedora 31 System-Wide Change proposal (late): No i686
> Repositories
>
> May be there are more interested people that we know, but they are not
> readi
I will do whatever I can and it's not much for ANY architecture, x86_64 is not
an exception. That's because I'm not very young and have a lot of other more
important activities which is not related to computers.
That said, I'm not expecting very much in return either. If it would somehow
work o
On 09. 09. 19 16:40, Fabio Valentini wrote:
Did some policy change occur which I am not aware of, or is bodhi just
misconfigured again for branched?
https://pagure.io/fedora-infrastructure/issue/8161
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
May be there are more interested people that we know, but they are not reading
that list. There will just be just every man for himself and Fedora has failed
to recognize that.
This requires time and effort too. Nobody will appear just by a miracle. I
recognize that there is much less people in
Ok, if that's so hard then I'm apologize for not recognizing the pain.
OTOH, if Debian has resources to maintain the support for at least next five
years it means one of two things: either they have more resources than Fedora,
or something is wrong with your assessment.
I'd help with maintainin
Hi everybody,
I seem to remember that bodhi updates for branched releases only
required 3 days in testing until they could be pushed to stable.
However, for fedora 31, the default (and minimum) is 7 days, and for
critpath packages, the default (and minimum) 14 days, like for normal
"released" fedo
On Mon, Sep 9, 2019 at 7:16 AM Michael J Gruber wrote:
> Okay, just quickly two good news:
>
> - Nikola Forró has a patch that got me much further, there's hope for a
> working dblatex on py3!
> - Upstream showed life signs, I'll try to coordinate (and get patches
> upstreamed now or later once
On 9/9/19 9:28 AM, vvs vvs wrote:
Boy, am I glad you've said that. I was waiting for it.
But looks like you are mistaken. First of all, it's not one, but at least two
of them. Second, nobody else seems to be supporting your point.
E-mails to this list don't get work done. Code commits get wor
Boy, am I glad you've said that. I was waiting for it.
But looks like you are mistaken. First of all, it's not one, but at least two
of them. Second, nobody else seems to be supporting your point.
___
devel mailing list -- devel@lists.fedoraproject.org
I'm planning on building a new version of PySide2 as it contains a lot of
bug fixes. Nothing appears to depend on it yet so shouldn't cause any
issues and I want to get the latest release built before porting over
freecad and the two consumers of PySide1.
Thanks,
Richard
__
No missing expected images.
Compose FAILS proposed Rawhide gating check!
21 of 45 required tests failed, 19 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.W
On Mon, Sep 09, 2019 at 06:22:46AM -0700, John M. Harris Jr. wrote:
> The system I'm sending this email from only has 4 GiB of memory in
> total. Does that mean that this system makes ASLR completely
> ineffective? Should this arch also be removed from Fedora, because of
> that?
*Address Space*
OLD: Fedora-31-20190908.n.0
NEW: Fedora-31-20190909.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 0
Dropped packages:1
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:1.26 MiB
Size of
On Monday, September 9, 2019 5:16:23 AM MST Vitaly Zaitsev via devel wrote:
> On 9/9/19 1:47 PM, John M. Harris Jr. wrote:
>
> > ASLR has nothing to do with the wild claims made in that email, that
> > having an
x86 system will somehow taint or 'infect' other systems.
> > Additionally, you don't
Okay, just quickly two good news:
- Nikola Forró has a patch that got me much further, there's hope for a working
dblatex on py3!
- Upstream showed life signs, I'll try to coordinate (and get patches
upstreamed now or later once we have them ready).
_
Seems evolve (tip) is not installable on python3:
python3 setup.py install --user
Traceback (most recent call last):
File "setup.py", line 37, in
version=get_version(),
File "setup.py", line 15, in get_version
return get_metadata()['__version__']
File "setup.py", line 10, in get_met
No missing expected images.
Failed openQA tests: 4/152 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20190908.n.0):
ID: 445958 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/445958
Old failures (same test failed in Fedora-31-20190
Hello packagers,
I've just orphaned both adapta-gtk-theme and adapta-backgrounds.
The upstream project is more or less dead, since the main developer
left after getting a lot of negative feedback for the release of a big
refresh / redesign of the Adapta GTK theme (which was then reverted).
The fe
* John M. Harris, Jr.:
> ASLR has nothing to do with the wild claims made in that email, that
> having an x86 system will somehow taint or 'infect' other
> systems. Additionally, you don't need to run a 64 bit system to get
> ASLR.
I'm not saying that the analogy is appropriate, but it is just no
1 - 100 of 117 matches
Mail list logo
