Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)

[Björn 'besser82' Esser]

Am Sonntag, den 19.04.2020, 18:22 +0200 schrieb Björn 'besser82' Esser:
> gluster-block is currently FTBFS for some reason related to the
> glusterfs package [2].


The reason for gluster-block has been FTBFS was fixed [1].  There was a
clash between config.h in the build-tree and located in /usr/include/.

So there are currently (and hopfully will be) no FTBFS packages for the
upcoming rebuild so far.


[1]  https://koji.fedoraproject.org/koji/taskinfo?taskID=43552367


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Announcement: taking over classloader-leak-test-framework

[Ondrej Dubaj]

Hi,
announcing taking over classloader-leak-test-framework, as it is needed by
postgresql-jdbc., which I am maintainer of.

Best regards,
Ondrej Dubaj
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

[Panu Matilainen]

On 4/17/20 5:09 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 17, 2020 at 04:48:11PM +0300, Panu Matilainen wrote:

On 3/26/20 1:32 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Mar 26, 2020 at 01:16:22PM +0200, Panu Matilainen wrote:

Right. I realize %posttrans is not a good idea. But *some* mechanism
is necessary, because without that the change will mostly be a noop
for most users. So I think this needs to be decided somehow.


[...]

- a one-shot service: this is easier to implement, it just needs to
   happen in one place. The hard part is making sure that the machine
   does not get reboot while the upgrade is happening. This is in
   particular a problem with VMs and containers. The rebuild should be
   wrapped with systemd-inhibit and other guards to make it hard to
   interrupt.


Looking at the details of how to do this now.

The idea is to install a generic "rebuild rpmdb on boot" one-shot
service, which can be flagged for action by 'touch
/var/lib/rpm/.rebuilddb'. That would be done from rpm %posttrans
when the rpmdb default changes, basically:

'[ -f /var/lib/rpm/Packages ] && touch /var/lib/rpm/.rebuilddb'

Should it become necessary, the same mechanism can be used to
convert back. This will of course trigger some "extra" rebuilds for
anybody staying on BDB backend but I'd say that's a feature...


Shouldn't this be a one-time thing instead?
E.g. '%triggerpostun rpm < n.n.n-n', where n.n.n-n is the first
version with the changed default?


Not really, because with a once in a lifetime opportunity there are too 
many ways things can go wrong. Also, we need to be herding people away 
from BDB with increasing intensity so even if we allow them to stay on 
BDB in F33, they will need to switch over at a not-so-distant future 
point, and that's not tied to rpm package versions anymore.





I'm thinking of something like this for
/usr/lib/systemd/rpmdb-rebuild.service:

---
[Unit]
Description=RPM database rebuild
ConditionPathExists=/var/lib/rpm/.rebuilddb

[Service]
Type=oneshot
ExecStart=/usr/bin/rpmdb --rebuilddb
ExecStartPost=rm -f /var/lib/rpm/.rebuilddb

[Install]
WantedBy=basic.target


[Unit]
Description=RPM database rebuild
ConditionPathExists=/var/lib/rpm/.rebuilddb
DefaultDependencies=no
After=sysinit.target


Should we also add Requires=sysinit.target I don't think we want this 
running on a boot where basics are failing...



Before=basic.target shutdown.target
Conflicts=shutdown.target


Hmm, what's with the shutdown.target This is not a service that will 
remain active so shutdown doesn't seem relevant.




[Service]
Type=oneshot
ExecStart=rpmdb --rebuilddb
ExecStartPost=rm -f /var/lib/rpm/.rebuilddb

[Install]
WantedBy=basic.target

(Service units have default dependency on basic.target, so if this
is to be ordered before basic.target, it needs DefaultDependencies=no.)


I guess the question is rather, is running before basic.target actually 
reasonable or even desireable? At the very least, we'd need to also add


RequiresMountsFor=/var /var/tmp

...because obviously /var needs to be there for this. And that makes me 
wonder what else is missing that we'd need.


- Panu -




This should be run quite early in the boot, before other daemons
that potentially access the rpmdb get started (abrt, dnfdaemon),
basically just as soon as /etc, /usr and /var are mounted. Is there
something else I should add, or something better to hook onto? Other
finer details that I'm missing?

It'll need a preset to enable by default if this ends up being the
route taken, but lets hear the feedback first before I go file the
bug...


Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-30-20200420.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone fails with Permission denied (publickey).

[Pavel Zhukov]

Hi,

I've changed my FAS ssh key and it's not updated for a few hours
(fedorapeople and pkgs both have an old one). Should I report the
issue somewhere?

Thank you

On Sun, Mar 29, 2020 at 8:35 PM Kevin Fenzi  wrote:
>
> On Sun, Mar 29, 2020 at 12:32:33PM -0500, Richard Shaw wrote:
> > Long story short I lost my home directory where I do all of my packager
> > activities (separate from my main user) so I'm setting things up from
> > scratch.
> >
> > I created new ssh keys and uploaded the public key to
> > admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
> > and I'm still getting:
>
> Yeah, please try again now.
>
> Currently the sync time is really long due to various reasons.
> I'll try and impove this next week...
>
> In the mean time I have done a manual sync.
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Pavel Zhukov
Software Engineer
IRC: landgraf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: python3dist provides

[Miro Hrončok]

On 19. 04. 20 18:01, Jerry James wrote:

On Sun, Apr 19, 2020 at 10:00 AM Miro Hrončok  wrote:

On 19. 04. 20 17:49, Miro Hrončok wrote:

On 19. 04. 20 17:09, Miro Hrončok wrote:

I'll send a PR shortly.

Finishing the commit message...


https://src.fedoraproject.org/rpms/python-nb2plots/pull-request/2


Thank you!


You are welcome and sorry for the trouble with the broken generator -- although 
it uncovered a problem in nb2plots.


As a side note I must say I really dislike how versioneer hardcodes the version 
information in the file with bundled copy of versioneer itself.


There is at least https://github.com/warner/python-versioneer/issues/199 for 
environment variable support.


But latest commit in the project is from 2017.

If you have close relationship with nb2plots upstream, please consider 
suggesting them to switch to setuptools-scm, the de-facto standard to do what 
versioneer is doing (however I don't know the history, maybe they have chosen 
versioneer over setuptools-scm for a reason).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[Vít Ondruch]

Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a):
> Thanks for answers, comment in the text follows.
>
> On Tue, Apr 14, 2020 at 12:16 PM clime  > wrote:
>
> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch  > wrote:
> >
> >
> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
> >
> > TLDR: Is $SUBJ function reasonable to implement in fedpkg?
> >
> > Hi,
> >
> > some time ago, fedpkg issue tracker got a request [1] for
> method, that allows direct builds. That means without sending
> srpms via "--srpm" argument. Currently, user's changes can be built:
> >
> >     fedpkg scratch-build --srpm
> >
> > This way, fedpkg sends srpm file to koji. Without "--srpm",
> fedpkg sends just (git) hash id to koji. But fedpkg needs
> modification to send a right hash id for user changes.
> Additionally, koji doesn't allow building hash ids from forked repos.
> >
> >
> > Even if this was possible, that would also mean that the sources
> have to be uploaded into look-a-side cache. Then it very much
> depend what is the content of the PR. If I am building Ruby
> nightly snapshots, I don't think it is fair to pollute look-a-side
> cache with them and I am afraid this is not the only case. I wish
> we had a way to override the look-a-side cache somehow 
>
> If I understand correctly, this would have to be done, if sources
> changed only, right? I.e. if there is a change just in patch or a spec
> file, the sources could be fetched from the main project.
>
>
> Yes, just sources (and eventually other binary files) are uploaded to
> lookaside cache. In the case of specfile and patches, there is no
> lookaside modification. Fork shares the same lookaside cache with the
> main project.
>  
>
>
> Should there be a possibility to upload sources for a fork that would
> then be moved to the main project when the pull request is merged?
>
>
> That sounds complicated to me and maybe it is not worth the intended
> result. Or I didn't find the right (easier) approach. ... New sources
> (and binaries) in fork need to be saved somewhere.
>  - In a parallel lookaside (for forks)
>  - In git repo (omitting lookaside)
> During the merge, some trigger would move the sources to the main
> lookaside. This creates a new file hash(es). And it would result in
> another commit done by a trigger.


Why it should create new hash(es)? If the fork/PR contains an updated
sources file (and it really should), then there is no reason for new commit.


Vít


> I think it is an unwanted situation.
> Some pollution of lookaside seems inevitable. But it happens even now
> without possibility to take uploaded file back.
>  
>
> >
> >
> > Vít
> >
> >
> > The question to the community. Is reasonable to implement this
> way of building scratches? --srpm argument would still work as
> previously.
> >
> > There is a suggested PR for this here: [2]. It is not completed yet.
> >
> > Risks:
> > * approach could confuse users. Users are used to work with
> fedpkg differently.
> > * koji would have to allow these builds
> > * more code complexity; currently there is a way how to reach
> your result even without this function
> >
> > Thanks
> > Ondrej
> >
> > [1] https://pagure.io/fedpkg/issue/282
> > [2] https://pagure.io/fedpkg/pull-request/390
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> 
> > To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> 
> > To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fe

Re: Call for testers for rpmautospec in staging

[Nicolas Mailhot via devel]

Hi,

Another solution would be to just save the state from which autobump is
computed in the srpm, and bump from this state at the rpmbuild level.
As long as the previous counter value is available computing a new one
is just a few lines of lua macro code

That would remove any adherence to
koji, mock or Fedora git.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning soundtracker

[Peter Hanecak]

Hello,

On 2020-04-09 16:10, Erich Eickmeyer wrote:
> Hi all,
> 
> soundtracker is FTBFS and is basically gnome 1 software that
> necro-limped along like a zombie for a few years (read: decades). As it
> FTBFS and is dead upstream, I believe it's suffering bitrot so it's
> probably time to let it die.
> 
> As such, I'm orphaning this package, and it will probably be retired.

given recent commits in GTK2 branch, I'll give it a shot.

Please, give me few hours/days, to look-up "how to take over a package".
I'm a little bit rusty.

Sincerely

Peter



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity Survey

[Nicolas Mailhot via devel]

Le lundi 13 avril 2020 à 13:34 -0400, Matthew Miller a écrit :
> On Sat, Apr 11, 2020 at 01:30:57PM +0200, Kevin Kofler wrote:
> > That is another major concern, that decisions made by Fedora for
> > Fedora 
> > users depend more and more on input from people (and companies) who
> > are NOT 
> > Fedora users. What makes sense for RHEL and/or CentOS does not
> > necessarily 
> > make sense for Fedora (and for that matter, what makes sense for
> > RHEL also 
> > does not necessarily make sense for CentOS). Fedora decisions
> > should depend 
> > ONLY on the input and needs of Fedora users.
> 
> Fedora has huge impact beyond our immediate userbase because we are
> the upstream for RHEL, CentOS, and their further derivatives.
> 
> Take a look https://imgur.com/a/58OXYve. This is Fedora EPEL (which
> is part of our project!), not the downstreams themselves, but shows
> just *one* aspect of that impact.

Another way to see things is that Fedora has a huge impact precisely
because Fedora decicions are depening ONLY on the input and needs of
Fedora users, and Fedora users have been consistently refusing the
short-termist non future-proof self-defeating shortcuts that plague
some of Fedora’s downstreams.

Fedora takes the long view. Over a significant span of time, that
produces better results than quick hacks.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 20, 2020 at 10:38:18AM +0300, Panu Matilainen wrote:
> On 4/17/20 5:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, Apr 17, 2020 at 04:48:11PM +0300, Panu Matilainen wrote:
> >>On 3/26/20 1:32 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>>On Thu, Mar 26, 2020 at 01:16:22PM +0200, Panu Matilainen wrote:
> >>>
> >>>Right. I realize %posttrans is not a good idea. But *some* mechanism
> >>>is necessary, because without that the change will mostly be a noop
> >>>for most users. So I think this needs to be decided somehow.
> >>>
> >>[...]
> >>>- a one-shot service: this is easier to implement, it just needs to
> >>>   happen in one place. The hard part is making sure that the machine
> >>>   does not get reboot while the upgrade is happening. This is in
> >>>   particular a problem with VMs and containers. The rebuild should be
> >>>   wrapped with systemd-inhibit and other guards to make it hard to
> >>>   interrupt.
> >>
> >>Looking at the details of how to do this now.
> >>
> >>The idea is to install a generic "rebuild rpmdb on boot" one-shot
> >>service, which can be flagged for action by 'touch
> >>/var/lib/rpm/.rebuilddb'. That would be done from rpm %posttrans
> >>when the rpmdb default changes, basically:
> >>
> >>'[ -f /var/lib/rpm/Packages ] && touch /var/lib/rpm/.rebuilddb'
> >>
> >>Should it become necessary, the same mechanism can be used to
> >>convert back. This will of course trigger some "extra" rebuilds for
> >>anybody staying on BDB backend but I'd say that's a feature...
> >
> >Shouldn't this be a one-time thing instead?
> >E.g. '%triggerpostun rpm < n.n.n-n', where n.n.n-n is the first
> >version with the changed default?
> 
> Not really, because with a once in a lifetime opportunity there are
> too many ways things can go wrong. Also, we need to be herding
> people away from BDB with increasing intensity so even if we allow
> them to stay on BDB in F33

While I don't disagree with this assessment, doing the conversion each time
rpm is upgraded sounds wrong. I.e. if someone decides (for whatever reason)
to skip the update in F33, they shouldn't be badgered until F34 comes along.
When the switch is mandatory at some point (e.g. in F34), than we can
update the scriptlet to perform the upgrade unconditionally.

Basically, "allow them to stay on BDB in F33" and "try to perform the upgrade
each time rpm.rpm is upgaded" seem incompatible.

> >>I'm thinking of something like this for
> >>/usr/lib/systemd/rpmdb-rebuild.service:
> >>
> >>---
> >>[Unit]
> >>Description=RPM database rebuild
> >>ConditionPathExists=/var/lib/rpm/.rebuilddb
> >>
> >>[Service]
> >>Type=oneshot
> >>ExecStart=/usr/bin/rpmdb --rebuilddb
> >>ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
> >>
> >>[Install]
> >>WantedBy=basic.target
> >
> >[Unit]
> >Description=RPM database rebuild
> >ConditionPathExists=/var/lib/rpm/.rebuilddb
> >DefaultDependencies=no
> >After=sysinit.target
> 
> Should we also add Requires=sysinit.target I don't think we want
> this running on a boot where basics are failing...

Yes.

> >Before=basic.target shutdown.target
> >Conflicts=shutdown.target
> 
> Hmm, what's with the shutdown.target This is not a service that will
> remain active so shutdown doesn't seem relevant.

Conflicts=shutdown.target is normally added to all units where
DefaultDependencies=no, to mimick the dependencies that would be added
by default. It ensures that the service is stopped before a shutdown.
It most cases it would not matter, but it's more correct to have it.

> >[Service]
> >Type=oneshot
> >ExecStart=rpmdb --rebuilddb
> >ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
> >
> >[Install]
> >WantedBy=basic.target
> >
> >(Service units have default dependency on basic.target, so if this
> >is to be ordered before basic.target, it needs DefaultDependencies=no.)
> 
> I guess the question is rather, is running before basic.target
> actually reasonable or even desireable? At the very least, we'd need
> to also add
> 
>   RequiresMountsFor=/var /var/tmp
> 
> ...because obviously /var needs to be there for this. And that makes
> me wonder what else is missing that we'd need.

/var and /var/tmp would be ordered before local-fs.target, so the
dependency on sysinit.target should be enough to handle this.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: f32-backgrounds look like crap

[Roberto Ragusa]

On 2020-04-19 22:26, Peter Oliver wrote:

Well, I don't see how it makes sense to deliberately create a low-quality
image with no technical need (nor technical benefits such as size saving).


I'd suggest it's for roughly the same reason that people still paint paintings 
when, nowadays, they could just take a photograph.  I don't pretend to know 
much about art, but that seems to be pretty intrinsic to how it works.



The problem is when the artistic touch leads people to thinking their graphics 
drivers
are defective.

Showing to someone who has just installed a new system some color
dithering from 1990 is not a good idea. Absolutely not for a default choice.

(and this is also the kind of background that can really waste a lot of network 
traffic
when doing screen sharing)

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

[Panu Matilainen]

On 4/20/20 1:07 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Apr 20, 2020 at 10:38:18AM +0300, Panu Matilainen wrote:

On 4/17/20 5:09 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 17, 2020 at 04:48:11PM +0300, Panu Matilainen wrote:

On 3/26/20 1:32 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Mar 26, 2020 at 01:16:22PM +0200, Panu Matilainen wrote:

Right. I realize %posttrans is not a good idea. But *some* mechanism
is necessary, because without that the change will mostly be a noop
for most users. So I think this needs to be decided somehow.


[...]

- a one-shot service: this is easier to implement, it just needs to
   happen in one place. The hard part is making sure that the machine
   does not get reboot while the upgrade is happening. This is in
   particular a problem with VMs and containers. The rebuild should be
   wrapped with systemd-inhibit and other guards to make it hard to
   interrupt.


Looking at the details of how to do this now.

The idea is to install a generic "rebuild rpmdb on boot" one-shot
service, which can be flagged for action by 'touch
/var/lib/rpm/.rebuilddb'. That would be done from rpm %posttrans
when the rpmdb default changes, basically:

'[ -f /var/lib/rpm/Packages ] && touch /var/lib/rpm/.rebuilddb'

Should it become necessary, the same mechanism can be used to
convert back. This will of course trigger some "extra" rebuilds for
anybody staying on BDB backend but I'd say that's a feature...


Shouldn't this be a one-time thing instead?
E.g. '%triggerpostun rpm < n.n.n-n', where n.n.n-n is the first
version with the changed default?


Not really, because with a once in a lifetime opportunity there are
too many ways things can go wrong. Also, we need to be herding
people away from BDB with increasing intensity so even if we allow
them to stay on BDB in F33


While I don't disagree with this assessment, doing the conversion each time
rpm is upgraded sounds wrong. I.e. if someone decides (for whatever reason)
to skip the update in F33, they shouldn't be badgered until F34 comes along.
When the switch is mandatory at some point (e.g. in F34), than we can
update the scriptlet to perform the upgrade unconditionally.

Basically, "allow them to stay on BDB in F33" and "try to perform the upgrade
each time rpm.rpm is upgaded" seem incompatible.


Where does the service say anything about conversion? It merely rebuilds 
the rpmdb, which is something BDB in particular will benefit from in two 
ways: it restores performance, and fixes any unnoticed breakage from 
indexes going out of sync. So it's a secret service being done to BDB 
users ;) which will as a side-effect handle database conversions too.



I'm thinking of something like this for
/usr/lib/systemd/rpmdb-rebuild.service:

---
[Unit]
Description=RPM database rebuild
ConditionPathExists=/var/lib/rpm/.rebuilddb

[Service]
Type=oneshot
ExecStart=/usr/bin/rpmdb --rebuilddb
ExecStartPost=rm -f /var/lib/rpm/.rebuilddb

[Install]
WantedBy=basic.target


[Unit]
Description=RPM database rebuild
ConditionPathExists=/var/lib/rpm/.rebuilddb
DefaultDependencies=no
After=sysinit.target


Should we also add Requires=sysinit.target I don't think we want
this running on a boot where basics are failing...


Yes.


Before=basic.target shutdown.target
Conflicts=shutdown.target


Hmm, what's with the shutdown.target This is not a service that will
remain active so shutdown doesn't seem relevant.


Conflicts=shutdown.target is normally added to all units where
DefaultDependencies=no, to mimick the dependencies that would be added
by default. It ensures that the service is stopped before a shutdown.
It most cases it would not matter, but it's more correct to have it.


[Service]
Type=oneshot
ExecStart=rpmdb --rebuilddb
ExecStartPost=rm -f /var/lib/rpm/.rebuilddb

[Install]
WantedBy=basic.target

(Service units have default dependency on basic.target, so if this
is to be ordered before basic.target, it needs DefaultDependencies=no.)


I guess the question is rather, is running before basic.target
actually reasonable or even desireable? At the very least, we'd need
to also add

RequiresMountsFor=/var /var/tmp

...because obviously /var needs to be there for this. And that makes
me wonder what else is missing that we'd need.


/var and /var/tmp would be ordered before local-fs.target, so the
dependency on sysinit.target should be enough to handle this.


For local /var yes, but basic.target has this:

# We support /var, /tmp, /var/tmp, being on NFS, but we don't pull in
# remote-fs.target by default, hence pull them in explicitly here. Note 
that we
# require /var and /var/tmp, but only add a Wants= type dependency on 
/tmp, as
# we support that unit being masked, and this should not be considered 
an error.

RequiresMountsFor=/var /var/tmp
Wants=tmp.mount

Not that BDB rpmdb on NFS is supported, except for read-only mounts maybe...

- Panu -
___
devel mailing list -- devel@l

Co-Maintainers wanted for python-lockfile EPEL branches

[Fabio Valentini]

Hi everybody,

I took over python-lockfile some time ago because it was FTBFS in
fedora / orphaned at the time, but it's a dependency of some of my
packages.

However, I have zero interest in maintaining the EPEL branches of that
package, because I have no packages in EPEL myself, and it seems I
can't even figure out how to determine which EPEL packages require
python*-lockfile.

I have received two PRs for the epel7 branch already, and I don't even
know if they're fine or not, so any help would be appreciated.

If nobody steps up within the next two weeks, I will probably retire
the epel7 and epel8 branches of python-lockfile.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[Ondrej Nosek]

On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch  wrote:

>
> Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a):
>
> Thanks for answers, comment in the text follows.
>
> On Tue, Apr 14, 2020 at 12:16 PM clime  wrote:
>
>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch  wrote:
>> >
>> >
>> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
>> >
>> > TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>> >
>> > Hi,
>> >
>> > some time ago, fedpkg issue tracker got a request [1] for method, that
>> allows direct builds. That means without sending srpms via "--srpm"
>> argument. Currently, user's changes can be built:
>> >
>> > fedpkg scratch-build --srpm
>> >
>> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg
>> sends just (git) hash id to koji. But fedpkg needs modification to send a
>> right hash id for user changes. Additionally, koji doesn't allow building
>> hash ids from forked repos.
>> >
>> >
>> > Even if this was possible, that would also mean that the sources have
>> to be uploaded into look-a-side cache. Then it very much depend what is the
>> content of the PR. If I am building Ruby nightly snapshots, I don't think
>> it is fair to pollute look-a-side cache with them and I am afraid this is
>> not the only case. I wish we had a way to override the look-a-side cache
>> somehow 
>>
>> If I understand correctly, this would have to be done, if sources
>> changed only, right? I.e. if there is a change just in patch or a spec
>> file, the sources could be fetched from the main project.
>>
>
> Yes, just sources (and eventually other binary files) are uploaded to
> lookaside cache. In the case of specfile and patches, there is no lookaside
> modification. Fork shares the same lookaside cache with the main project.
>
>
>>
>> Should there be a possibility to upload sources for a fork that would
>> then be moved to the main project when the pull request is merged?
>>
>
> That sounds complicated to me and maybe it is not worth the intended
> result. Or I didn't find the right (easier) approach. ... New sources (and
> binaries) in fork need to be saved somewhere.
>  - In a parallel lookaside (for forks)
>  - In git repo (omitting lookaside)
> During the merge, some trigger would move the sources to the main
> lookaside. This creates a new file hash(es). And it would result in another
> commit done by a trigger.
>
>
> Why it should create new hash(es)? If the fork/PR contains an updated
> sources file (and it really should), then there is no reason for new commit.
>

Oh. In my last post, I wanted to say, that no commit is needed if you are
using main lookaside. Just in case you have parallel lookaside or other
storage, you have to upload sources from your alternative storage to main
lookaside and it would result in the extra commit.
But I looked at code how lookaside works internally. Hash is computed
locally and the upload path (except the host) should be the same for both
lookasides. So I realized that during merge, only download the sources from
parallel lookaside and upload it to the main lookaside would work. Without
extra commit. But is it a win? This might bring other problems. Timeouts
when some large source is processed?
Parallel lookaside is intended to not mess the main lookaside. So I think
the parallel lookaside should be cleaned somehow. Periodically? Based on
age? How should I recognize if the file is safe to delete? Do users always
use forked projects as temporary so they wouldn't mind that unmerged source
is deleted from lookaside after one month?

> Vít
>
>
> I think it is an unwanted situation.
> Some pollution of lookaside seems inevitable. But it happens even now
> without possibility to take uploaded file back.
>
>
>> >
>> >
>> > Vít
>> >
>> >
>> > The question to the community. Is reasonable to implement this way of
>> building scratches? --srpm argument would still work as previously.
>> >
>> > There is a suggested PR for this here: [2]. It is not completed yet.
>> >
>> > Risks:
>> > * approach could confuse users. Users are used to work with fedpkg
>> differently.
>> > * koji would have to allow these builds
>> > * more code complexity; currently there is a way how to reach your
>> result even without this function
>> >
>> > Thanks
>> > Ondrej
>> >
>> > [1] https://pagure.io/fedpkg/issue/282
>> > [2] https://pagure.io/fedpkg/pull-request/390
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproj

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[clime]

On Mon, 20 Apr 2020 at 13:54, Ondrej Nosek  wrote:
>
>
>
> On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch  wrote:
>>
>>
>> Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a):
>>
>> Thanks for answers, comment in the text follows.
>>
>> On Tue, Apr 14, 2020 at 12:16 PM clime  wrote:
>>>
>>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch  wrote:
>>> >
>>> >
>>> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
>>> >
>>> > TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>>> >
>>> > Hi,
>>> >
>>> > some time ago, fedpkg issue tracker got a request [1] for method, that 
>>> > allows direct builds. That means without sending srpms via "--srpm" 
>>> > argument. Currently, user's changes can be built:
>>> >
>>> > fedpkg scratch-build --srpm
>>> >
>>> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends 
>>> > just (git) hash id to koji. But fedpkg needs modification to send a right 
>>> > hash id for user changes. Additionally, koji doesn't allow building hash 
>>> > ids from forked repos.
>>> >
>>> >
>>> > Even if this was possible, that would also mean that the sources have to 
>>> > be uploaded into look-a-side cache. Then it very much depend what is the 
>>> > content of the PR. If I am building Ruby nightly snapshots, I don't think 
>>> > it is fair to pollute look-a-side cache with them and I am afraid this is 
>>> > not the only case. I wish we had a way to override the look-a-side cache 
>>> > somehow 
>>>
>>> If I understand correctly, this would have to be done, if sources
>>> changed only, right? I.e. if there is a change just in patch or a spec
>>> file, the sources could be fetched from the main project.
>>
>>
>> Yes, just sources (and eventually other binary files) are uploaded to 
>> lookaside cache. In the case of specfile and patches, there is no lookaside 
>> modification. Fork shares the same lookaside cache with the main project.
>>
>>>
>>>
>>> Should there be a possibility to upload sources for a fork that would
>>> then be moved to the main project when the pull request is merged?
>>
>>
>> That sounds complicated to me and maybe it is not worth the intended result. 
>> Or I didn't find the right (easier) approach. ... New sources (and binaries) 
>> in fork need to be saved somewhere.
>>  - In a parallel lookaside (for forks)
>>  - In git repo (omitting lookaside)
>> During the merge, some trigger would move the sources to the main lookaside. 
>> This creates a new file hash(es). And it would result in another commit done 
>> by a trigger.
>>
>>
>> Why it should create new hash(es)? If the fork/PR contains an updated 
>> sources file (and it really should), then there is no reason for new commit.
>
>
> Oh. In my last post, I wanted to say, that no commit is needed if you are 
> using main lookaside. Just in case you have parallel lookaside or other 
> storage, you have to upload sources from your alternative storage to main 
> lookaside and it would result in the extra commit.
> But I looked at code how lookaside works internally. Hash is computed locally 
> and the upload path (except the host) should be the same for both lookasides. 
> So I realized that during merge, only download the sources from parallel 
> lookaside and upload it to the main lookaside would work. Without extra 
> commit. But is it a win? This might bring other problems. Timeouts when some 
> large source is processed?

This should be ideally solved by hardlinks if the forks cache and the
main cache can be on the same filesystem Otherwise copying is needed,
which may be quite expensive. I.e. during merge you just create
hardlink on the new location in the main repo that points to the
source in the forks repo.

> Parallel lookaside is intended to not mess the main lookaside. So I think the 
> parallel lookaside should be cleaned somehow. Periodically? Based on age? How 
> should I recognize if the file is safe to delete? Do users always use forked 
> projects as temporary so they wouldn't mind that unmerged source is deleted 
> from lookaside after one month?

I think periodic cleaning is a very good idea here but people would
need to know about it and be ok with it.

>>
>> Vít
>>
>>
>> I think it is an unwanted situation.
>> Some pollution of lookaside seems inevitable. But it happens even now 
>> without possibility to take uploaded file back.
>>
>>>
>>> >
>>> >
>>> > Vít
>>> >
>>> >
>>> > The question to the community. Is reasonable to implement this way of 
>>> > building scratches? --srpm argument would still work as previously.
>>> >
>>> > There is a suggested PR for this here: [2]. It is not completed yet.
>>> >
>>> > Risks:
>>> > * approach could confuse users. Users are used to work with fedpkg 
>>> > differently.
>>> > * koji would have to allow these builds
>>> > * more code complexity; currently there is a way how to reach your result 
>>> > even without this function
>>> >
>>> > Thanks
>>> > Ondrej
>>> >
>>> > [1] https://pagure.io/fedpkg/issue/282
>>> > [2] https://pagure.io/fedpkg/p

Orphaned package istatd

[Lorenzo Dalrio]

Hi, I just orphaned istatd since it is not actively maintained anymore.

Have a nice day,
-- 
Lorenzo Dalrio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[Vít Ondruch]

Dne 20. 04. 20 v 13:52 Ondrej Nosek napsal(a):
>
>
> On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch  > wrote:
>
>
> Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a):
>> Thanks for answers, comment in the text follows.
>>
>> On Tue, Apr 14, 2020 at 12:16 PM clime > > wrote:
>>
>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch
>> mailto:vondr...@redhat.com>> wrote:
>> >
>> >
>> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
>> >
>> > TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>> >
>> > Hi,
>> >
>> > some time ago, fedpkg issue tracker got a request [1] for
>> method, that allows direct builds. That means without sending
>> srpms via "--srpm" argument. Currently, user's changes can be
>> built:
>> >
>> >     fedpkg scratch-build --srpm
>> >
>> > This way, fedpkg sends srpm file to koji. Without "--srpm",
>> fedpkg sends just (git) hash id to koji. But fedpkg needs
>> modification to send a right hash id for user changes.
>> Additionally, koji doesn't allow building hash ids from
>> forked repos.
>> >
>> >
>> > Even if this was possible, that would also mean that the
>> sources have to be uploaded into look-a-side cache. Then it
>> very much depend what is the content of the PR. If I am
>> building Ruby nightly snapshots, I don't think it is fair to
>> pollute look-a-side cache with them and I am afraid this is
>> not the only case. I wish we had a way to override the
>> look-a-side cache somehow 
>>
>> If I understand correctly, this would have to be done, if sources
>> changed only, right? I.e. if there is a change just in patch
>> or a spec
>> file, the sources could be fetched from the main project.
>>
>>
>> Yes, just sources (and eventually other binary files) are
>> uploaded to lookaside cache. In the case of specfile and patches,
>> there is no lookaside modification. Fork shares the same
>> lookaside cache with the main project.
>>  
>>
>>
>> Should there be a possibility to upload sources for a fork
>> that would
>> then be moved to the main project when the pull request is
>> merged?
>>
>>
>> That sounds complicated to me and maybe it is not worth the
>> intended result. Or I didn't find the right (easier) approach.
>> ... New sources (and binaries) in fork need to be saved somewhere.
>>  - In a parallel lookaside (for forks)
>>  - In git repo (omitting lookaside)
>> During the merge, some trigger would move the sources to the main
>> lookaside. This creates a new file hash(es). And it would result
>> in another commit done by a trigger.
>
>
> Why it should create new hash(es)? If the fork/PR contains an
> updated sources file (and it really should), then there is no
> reason for new commit.
>
>
> Oh. In my last post, I wanted to say, that no commit is needed if you
> are using main lookaside. Just in case you have parallel lookaside or
> other storage, you have to upload sources from your alternative
> storage to main lookaside and it would result in the extra commit.
> But I looked at code how lookaside works internally. Hash is computed
> locally and the upload path (except the host) should be the same for
> both lookasides. So I realized that during merge, only download the
> sources from parallel lookaside and upload it to the main lookaside
> would work. Without extra commit. But is it a win? This might bring
> other problems. Timeouts when some large source is processed?
> Parallel lookaside is intended to not mess the main lookaside. So I
> think the parallel lookaside should be cleaned somehow.


It should be cleaned as often as the stalled PRs? I know we don't have
infrastructure for this, but it would be logical answer to your question.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[clime]

On Mon, 20 Apr 2020 at 14:24, Vít Ondruch  wrote:
>
>
> Dne 20. 04. 20 v 13:52 Ondrej Nosek napsal(a):
>
>
>
> On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch  wrote:
>>
>>
>> Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a):
>>
>> Thanks for answers, comment in the text follows.
>>
>> On Tue, Apr 14, 2020 at 12:16 PM clime  wrote:
>>>
>>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch  wrote:
>>> >
>>> >
>>> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
>>> >
>>> > TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>>> >
>>> > Hi,
>>> >
>>> > some time ago, fedpkg issue tracker got a request [1] for method, that 
>>> > allows direct builds. That means without sending srpms via "--srpm" 
>>> > argument. Currently, user's changes can be built:
>>> >
>>> > fedpkg scratch-build --srpm
>>> >
>>> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends 
>>> > just (git) hash id to koji. But fedpkg needs modification to send a right 
>>> > hash id for user changes. Additionally, koji doesn't allow building hash 
>>> > ids from forked repos.
>>> >
>>> >
>>> > Even if this was possible, that would also mean that the sources have to 
>>> > be uploaded into look-a-side cache. Then it very much depend what is the 
>>> > content of the PR. If I am building Ruby nightly snapshots, I don't think 
>>> > it is fair to pollute look-a-side cache with them and I am afraid this is 
>>> > not the only case. I wish we had a way to override the look-a-side cache 
>>> > somehow 
>>>
>>> If I understand correctly, this would have to be done, if sources
>>> changed only, right? I.e. if there is a change just in patch or a spec
>>> file, the sources could be fetched from the main project.
>>
>>
>> Yes, just sources (and eventually other binary files) are uploaded to 
>> lookaside cache. In the case of specfile and patches, there is no lookaside 
>> modification. Fork shares the same lookaside cache with the main project.
>>
>>>
>>>
>>> Should there be a possibility to upload sources for a fork that would
>>> then be moved to the main project when the pull request is merged?
>>
>>
>> That sounds complicated to me and maybe it is not worth the intended result. 
>> Or I didn't find the right (easier) approach. ... New sources (and binaries) 
>> in fork need to be saved somewhere.
>>  - In a parallel lookaside (for forks)
>>  - In git repo (omitting lookaside)
>> During the merge, some trigger would move the sources to the main lookaside. 
>> This creates a new file hash(es). And it would result in another commit done 
>> by a trigger.
>>
>>
>> Why it should create new hash(es)? If the fork/PR contains an updated 
>> sources file (and it really should), then there is no reason for new commit.
>
>
> Oh. In my last post, I wanted to say, that no commit is needed if you are 
> using main lookaside. Just in case you have parallel lookaside or other 
> storage, you have to upload sources from your alternative storage to main 
> lookaside and it would result in the extra commit.
> But I looked at code how lookaside works internally. Hash is computed locally 
> and the upload path (except the host) should be the same for both lookasides. 
> So I realized that during merge, only download the sources from parallel 
> lookaside and upload it to the main lookaside would work. Without extra 
> commit. But is it a win? This might bring other problems. Timeouts when some 
> large source is processed?
> Parallel lookaside is intended to not mess the main lookaside. So I think the 
> parallel lookaside should be cleaned somehow.
>
>
> It should be cleaned as often as the stalled PRs? I know we don't have 
> infrastructure for this, but it would be logical answer to your question.

Imho, you need to think also about repos from which pull requests are
never created and that can have uploaded sources.

>
>
> Vít
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-31-20200420.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

boost package in fedora

[Vascom]

Will Boost ever be updated on Fedora again?

https://bugzilla.redhat.com/show_bug.cgi?id=1558278
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Co-Maintainers wanted for python-lockfile EPEL branches

[Troy Dawson]

On a RHEL8 machine, doing a
  dnf repoquery --whatrequires python3-lockfile
  dnf repoquery --whatrequires python2-lockfile
Shows that the following depend on it
  duplicity
  python3-fedora
  pungi-legacy

I haven't checked EPEL7 yet.

On Mon, Apr 20, 2020 at 4:46 AM Fabio Valentini  wrote:
>
> Hi everybody,
>
> I took over python-lockfile some time ago because it was FTBFS in
> fedora / orphaned at the time, but it's a dependency of some of my
> packages.
>
> However, I have zero interest in maintaining the EPEL branches of that
> package, because I have no packages in EPEL myself, and it seems I
> can't even figure out how to determine which EPEL packages require
> python*-lockfile.
>
> I have received two PRs for the epel7 branch already, and I don't even
> know if they're fine or not, so any help would be appreciated.
>
> If nobody steps up within the next two weeks, I will probably retire
> the epel7 and epel8 branches of python-lockfile.
>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Co-Maintainers wanted for python-lockfile EPEL branches

[Miro Hrončok]

On 20. 04. 20 15:24, Troy Dawson wrote:

On a RHEL8 machine, doing a
   dnf repoquery --whatrequires python3-lockfile
   dnf repoquery --whatrequires python2-lockfile
Shows that the following depend on it
   duplicity
   python3-fedora
   pungi-legacy

I haven't checked EPEL7 yet.


$ repoquery --repo=epel7{,-source} --whatrequires python3-lockfile
(nada)

$ repoquery --repo=epel7{,-source} --whatrequires python2-lockfile
(nada)

$ repoquery --repo=epel7{,-source} --whatrequires python-lockfile
atomicapp-0:0.6.3-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.src
duplicity-0:0.7.19-1.el7.x86_64
pungi-0:3.12-3.el7.1.noarch
python-daemon-0:1.6-4.el7.noarch
python-daemon-0:1.6-4.el7.src
python-fedora-0:0.10.0-1.el7.src
python2-fedora-0:0.10.0-1.el7.noarch


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Co-Maintainers wanted for python-lockfile EPEL branches

[Miro Hrončok]

On 20. 04. 20 13:45, Fabio Valentini wrote:

and it seems I
can't even figure out how to determine which EPEL packages require
python*-lockfile.


Take the attached repo files.

They are good for repoquery, adapted from epel-release.

They don't have -testing repos, but -testingx, so you don't accidentally enable 
them  with dnf --enablerepo=\*-testing.


Usage:

$ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
pungi-legacy-0:4.1.38-1.el8.2.noarch
python2-pungi-0:4.1.38-1.el8.2.noarch



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
[epel7]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

[epel7-testingx]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

[epel7-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

[epel7-testingx-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel8]
name=Extra Packages for Enterprise Linux 8 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-8&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8

[epel8-testingx]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel8&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8

[epel8-source]
name=Extra Packages for Enterprise Linux 8 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-8&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1

[epel8-testingx-source]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel8&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Co-Maintainers wanted for python-lockfile EPEL branches

[Neal Gompa]

On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok  wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-release.
>
> They don't have -testing repos, but -testingx, so you don't accidentally 
> enable
> them  with dnf --enablerepo=\*-testing.
>
> Usage:
>
> $ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
> pungi-legacy-0:4.1.38-1.el8.2.noarch
> python2-pungi-0:4.1.38-1.el8.2.noarch
>

I also have a simple little tool I use for querying distributions and
repos with DNF: https://pagure.io/rpmdistro-repoquery

It comes with collections of repo definitions for Fedora, CentOS +
EPEL, Mageia, and openSUSE, and might be useful for things like
this...



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity Survey

[Kevin Kofler]

John M. Harris Jr wrote:
> Let's be honest, this doesn't even really make sense for RHEL.

I agree that the current design of Modularity is inherently flawed (because 
it allows version conflicts to happen that cannot be resolved by the user), 
but in the context of RHEL, I can see where the demand comes from, whereas 
in Fedora, the problem Modularity is trying to solve did not exist to begin 
with.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

fedpkg broken (pycurl issue?)

[Neal Becker]

Maybe the problem is that my local pycurl is not compatible with fedpkg?

fedpkg 
fedpkg 
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 11, in 
load_entry_point('fedpkg==1.38', 'console_scripts', 'fedpkg')()
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 490, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2859, in load_entry_point
return ep.load()
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2450, in load
return self.resolve()
  File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2456, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3.7/site-packages/fedpkg/__init__.py", line 12, in 

import pyrpkg
  File "/home/nbecker/.local/lib/python3.7/site-packages/pyrpkg/__init__.py", 
line 47, in 
from pyrpkg.lookaside import CGILookasideCache
  File "/home/nbecker/.local/lib/python3.7/site-packages/pyrpkg/lookaside.py", 
line 26, in 
import pycurl
ImportError: pycurl: libcurl link-time ssl backend (openssl) is different from 
compile-time ssl backend (none/other)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Cannot retire epel7 package

[Orion Poplawski]

On 4/20/20 4:25 AM, Miro Hrončok wrote:

On 20. 04. 20 12:13, Miro Hrončok wrote:

On 20. 04. 20 6:09, Orion Poplawski wrote:
zabbix22 (epel7)]$ fedpkg retire 'Zabbix 2.2 is no longer maintained 
upstream'
Fedora release (epel7) is in state 'current' - retire operation is 
not allowed.


Sounds like fedpkg bug. See https://pagure.io/fedpkg/issue/337


As a workaround, git rm everything, git add dead.package and commit/push 
manually.




Thanks.  Done.

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-de...@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 20, 2020 at 02:40:36PM +0300, Panu Matilainen wrote:
> On 4/20/20 1:07 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Apr 20, 2020 at 10:38:18AM +0300, Panu Matilainen wrote:
> >>On 4/17/20 5:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>>[Service]
> >>>Type=oneshot
> >>>ExecStart=rpmdb --rebuilddb
> >>>ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
> >>>
> >>>[Install]
> >>>WantedBy=basic.target
> >>>
> >>>(Service units have default dependency on basic.target, so if this
> >>>is to be ordered before basic.target, it needs DefaultDependencies=no.)
> >>
> >>I guess the question is rather, is running before basic.target
> >>actually reasonable or even desireable? At the very least, we'd need
> >>to also add
> >>
> >>RequiresMountsFor=/var /var/tmp
> >>
> >>...because obviously /var needs to be there for this. And that makes
> >>me wonder what else is missing that we'd need.
> >
> >/var and /var/tmp would be ordered before local-fs.target, so the
> >dependency on sysinit.target should be enough to handle this.
> 
> For local /var yes, but basic.target has this:
> 
> # We support /var, /tmp, /var/tmp, being on NFS, but we don't pull in
> # remote-fs.target by default, hence pull them in explicitly here.
> Note that we
> # require /var and /var/tmp, but only add a Wants= type dependency
> on /tmp, as
> # we support that unit being masked, and this should not be
> considered an error.
> RequiresMountsFor=/var /var/tmp
> Wants=tmp.mount
> 
> Not that BDB rpmdb on NFS is supported, except for read-only mounts maybe...

Indeed, I stand corrected.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg broken (pycurl issue?)

[Kamil Dudka]

On Monday, April 20, 2020 3:59:59 PM CEST Neal Becker wrote:
> Maybe the problem is that my local pycurl is not compatible with fedpkg?

The more important problem is that your local pycurl is not compatible with
libcurl, which is exactly what the error message is telling you, isn't it?

I would suggest to rather use the system-provided pycurl, which has
a downstream patch to disable this (IMO not so useful) run-time check:

https://src.fedoraproject.org/rpms/python-pycurl/blob/c0aa6c5c/f/0002-python-pycurl-7.43.0-tls-backend.patch

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg broken (pycurl issue?)

[Miro Hrončok]

On 20. 04. 20 15:59, Neal Becker wrote:

Maybe the problem is that my local pycurl is not compatible with fedpkg?

fedpkg
fedpkg
Traceback (most recent call last):
   File "/usr/bin/fedpkg", line 11, in 
 load_entry_point('fedpkg==1.38', 'console_scripts', 'fedpkg')()
   File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 490, in load_entry_point
 return get_distribution(dist).load_entry_point(group, name)
   File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2859, in load_entry_point
 return ep.load()
   File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2450, in load
 return self.resolve()
   File 
"/home/nbecker/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", 
line 2456, in resolve
 module = __import__(self.module_name, fromlist=['__name__'], level=0)
   File "/usr/lib/python3.7/site-packages/fedpkg/__init__.py", line 12, in 

 import pyrpkg
   File "/home/nbecker/.local/lib/python3.7/site-packages/pyrpkg/__init__.py", line 
47, in 
 from pyrpkg.lookaside import CGILookasideCache
   File "/home/nbecker/.local/lib/python3.7/site-packages/pyrpkg/lookaside.py", line 
26, in 
 import pycurl
ImportError: pycurl: libcurl link-time ssl backend (openssl) is different from 
compile-time ssl backend (none/other)


Try:

  python3 -s /usr/bin/fedpkg

Does it solve your problem? If so, the -s flag should be added to the shebang.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2020-04-20)

[Miro Hrončok]

=
#fedora-meeting-1: FESCO (2020-04-20)
=


Meeting started by mhroncok at 15:00:03 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-20/fesco.2020-04-20-15.00.log.html
.



Meeting summary
---
* init process  (mhroncok, 15:00:12)

* #2370 Fedora 33 System-Wide Change: java-11-openjdk as system JDK in
  F33  (mhroncok, 15:01:37)
  * AGREED: APPROVED (+8, 1, -0)  (mhroncok, 15:05:08)
  * LINK: https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy
(mhroncok, 15:07:02)

* Next week's chair  (mhroncok, 15:09:37)
  * ACTION: bookwar will chair next meeting  (mhroncok, 15:10:05)

* Open Floor  (mhroncok, 15:10:18)
  * AGREED: FESCo does not feel that https://bugzilla.redhat.com/1825046
justifies being declared a FESCo-blocker. (+9, 0, -0)  (mhroncok,
15:22:53)

Meeting ended at 15:28:55 UTC.




Action Items

* bookwar will chair next meeting




Action Items, by person
---
* bookwar
  * bookwar will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mhroncok (55)
* sgallagh (31)
* zodbot (21)
* zbyszek (20)
* dcantrell (13)
* nirik (11)
* bookwar (4)
* bcotton (4)
* contyk (4)
* decathorpe (4)
* ignatenkobrain (3)
* cyberpear (1)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 compose report: 20200420.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200419.n.0
NEW: Fedora-32-20200420.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Previous awesome background images

[Máirín Duffy]

> On 17. 04. 20 16:07, Kamil Paral wrote:
> https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/
> 
> I am sad we haven't followed the pattern. (However I don't know the reasoning 
> for stopping that.)

That's not true, we didn't stop the pattern. F32 is G for Goffman. F was 
Fresnel. E was Elion. So on. If you dig through the tickets you'll fimd the 
inspiration.

~m
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Previous awesome background images

[James Cassell]

On Mon, Apr 20, 2020, at 12:46 PM, Máirín Duffy wrote:
> > On 17. 04. 20 16:07, Kamil Paral wrote:
> > https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/
> > 
> > I am sad we haven't followed the pattern. (However I don't know the 
> > reasoning 
> > for stopping that.)
> 
> That's not true, we didn't stop the pattern. F32 is G for Goffman. F 
> was Fresnel. E was Elion. So on. If you dig through the tickets you'll 
> fimd the inspiration.
> 

OMG, Secret Fedora Release Names!

Did not realize it was a thing. Very cool!

V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Previous awesome background images

[Miro Hrončok]

On 20. 04. 20 18:46, Máirín Duffy wrote:

On 17. 04. 20 16:07, Kamil Paral wrote:
https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/

I am sad we haven't followed the pattern. (However I don't know the reasoning
for stopping that.)


That's not true, we didn't stop the pattern. F32 is G for Goffman. F was 
Fresnel. E was Elion. So on. If you dig through the tickets you'll fimd the 
inspiration.


Cool! Sorry for the misunderstanding.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Previous awesome background images

[Brandon Nielsen]

On 4/20/20 11:54 AM, James Cassell wrote:


On Mon, Apr 20, 2020, at 12:46 PM, Máirín Duffy wrote:

On 17. 04. 20 16:07, Kamil Paral wrote:
https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/

I am sad we haven't followed the pattern. (However I don't know the reasoning
for stopping that.)


That's not true, we didn't stop the pattern. F32 is G for Goffman. F
was Fresnel. E was Elion. So on. If you dig through the tickets you'll
fimd the inspiration.



OMG, Secret Fedora Release Names!

Did not realize it was a thing. Very cool!

V/r,
James Cassell


Huh, I didn't realize that either.

As for the original intent of this thread, I always loved the wallpaper 
from F15. I still have the SVG in my regular wallpaper rotation.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: f32-backgrounds look like crap

[Dan Book]

On Fri, Apr 17, 2020 at 9:10 AM Benson Muite 
wrote:

>
> On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote:
> > > Hi Leigh,
> > >
> > >
> > > Do you think you could please use nicer language? There's no need to
> > > use words like that to describe other people's work in the community.
> >
> > That was the nicest term I could use to describe it!
> >
> > >
> > > I personally quite like the 90s retro look.
> > >
>
> Hi Leigh,
>
> Elections for alternative wallpapers are currently open:
> https://apps.fedoraproject.org/nuancier/elections/
> Please vote for ones that you like.
>
> The submission phase for Fedora 32 has unfortunately already closed.
> Please do make wallpaper submissions for Fedora 33 as well to ensure
> there is a wide choice of excellent candidates.
>

I think it's important to point out here that while the available
alternatives are great options, it does not change the desktop experience
presented to users who first install Fedora of whatever flavor. The only
thing that affects that is the choice of default for that spin, whether it
can be improved by a user who wants to customize their experience is
orthogonal.

-Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Previous awesome background images

[Neal Gompa]

On Mon, Apr 20, 2020 at 12:46 PM Máirín Duffy  wrote:
>
> > On 17. 04. 20 16:07, Kamil Paral wrote:
> > https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/
> >
> > I am sad we haven't followed the pattern. (However I don't know the 
> > reasoning
> > for stopping that.)
>
> That's not true, we didn't stop the pattern. F32 is G for Goffman. F was 
> Fresnel. E was Elion. So on. If you dig through the tickets you'll fimd the 
> inspiration.
>

Why don't we just use these for codenames?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Previous awesome background images

[Chris Murphy]

On Mon, Apr 20, 2020 at 10:46 AM Máirín Duffy  wrote:
>
> > On 17. 04. 20 16:07, Kamil Paral wrote:
> > https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/
> >
> > I am sad we haven't followed the pattern. (However I don't know the 
> > reasoning
> > for stopping that.)
>
> That's not true, we didn't stop the pattern. F32 is G for Goffman. F was 
> Fresnel. E was Elion. So on. If you dig through the tickets you'll fimd the 
> inspiration.

Everyone's an art critic.

I spent some effort building a technical mindset, dispensing with
aesthetic, in my line of work in color management and color science.
"There is no such thing as bad colors" and "art isn't my thing, all I
care about is accuracy" and so on. And then I taught a masters level
class in photography at the School of Visual Arts - where I had to
become a critic, at a technical level. The class was 'color management
and printing'. I learned at least as much as I taught. One of the
early assignments, which I actually didn't figure out for the first
year, was to go look at art. Why are the successes considered
successful? Yeah you can read about that to some degree, but you
really have to look at it, and mimic it. You only really understand by
trying to replicate those successes. And you pretty much have to do
what others have done before you, because they're that successful and
basic, and then you can innovate and incorporate your own style.

I'm no art history amateur let alone expert, so I don't know all the
reasons why it's familiar. But I see the intentional use of different
kinds of dithering as art. These techniques have a long history in
both analog and digital image reproduction. I see the traditional AM
halftoning from various print forms, found in newspapers, magazines,
comic books, packaging, and it exists for its tolerance to the
mechanical limitations of those processes. The apparent stochastic (FM
screening) also leverages noise as the dithering approach, resulting
in the "crushed glass" kind of look, especially in the dark to light
gradients. I think it's a successful blending of these class dithering
techniques that you don't find on pixel displays. But to good effect,
in particular on crap low bit depth panels where smooth gradients of
short distance readily will show posterization where none exists in
the digital file. The noise masks the limitations of the panel. That's
the whole point of dithering. I think it's fantastic.

I have the benefit of looking at the background on a crap laptop
display as well as a rather nice NEC self-calibrating display suitable
for medical imaging. And this background looks good to me on both
displays. That's non-trivial to achieve, there are always compromises.
It's not really possible to make smooth gradients of short distances
on low end panels, of course some noise is necessary.

The negatives come from people used to a particular aesthetic, and
just don't realize what they're looking at. And 20 years ago I'd put
myself into that category. Maybe the F32 background art is too
sophisticated. But then I immediately have to refuse that premise
because I think Fedora deserves the sophisticated, and that it's
better to just consider the negative comments innocently ignorant.
Folks just don't know what they're looking at.

Anyway, I'm totally guessing. I have no actual insight to the
development process of the F32 default background. It'd be interesting
to read about the inspiration, process, and iterations involved in
combining the aesthetic and the technical. I think people would be
surprised to discover the things they don't like about it are perhaps
more tied to technical decisions that were then taken advantage of by
the chosen aesthetic.

Also, classic art: evoking an emotional response in the viewer. :-D In
this sense, the art is perhaps one of Fedora's most successful!


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200420.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200419.n.0
NEW: Fedora-Rawhide-20200420.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  1
Dropped packages:2
Upgraded packages:   56
Downgraded packages: 0

Size of added packages:  122.61 KiB
Size of dropped packages:149.36 MiB
Size of upgraded packages:   4.68 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -7.67 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200419.n.0.ppc64le.qcow2
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200419.n.0.ppc64le.raw.xz
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200419.n.0.ppc64le.vmdk

= ADDED PACKAGES =
Package: ansible-collection-netbox-netbox-0.1.10-1.fc33
Summary: Netbox modules for Ansible
RPMs:ansible-collection-netbox-netbox
Size:122.61 KiB


= DROPPED PACKAGES =
Package: OCE-0.18.3-8.fc32
Summary: OpenCASCADE Community Edition
RPMs:OCE-devel OCE-draw OCE-foundation OCE-modeling OCE-ocaf 
OCE-visualization
Size:149.17 MiB

Package: python-flask-cache-0.13.1-19.fc32
Summary: Adds cache support to your Flask application
RPMs:python3-flask-cache python3-flask-cache-doc
Size:195.20 KiB


= UPGRADED PACKAGES =
Package:  SuperLU-5.2.1-10.fc33
Old package:  SuperLU-5.2.1-9.fc33
Summary:  Subroutines to solve sparse linear systems
RPMs: SuperLU SuperLU-devel SuperLU-doc
Size: 1.98 MiB
Size change:  4.68 KiB
Changelog:
  * Sun Apr 19 2020 Antonio Trande  - 5.2.1-10
  - Doc sub-package provides its own license file


Package:  ansible-2.9.7-3.fc33
Old package:  ansible-2.9.7-1.fc33
Summary:  SSH-based configuration management, deployment, and task 
execution system
RPMs: ansible ansible-doc
Size: 25.64 MiB
Size change:  1.36 KiB
Changelog:
  * Sun Apr 19 2020 Igor Raits  - 2.9.7-2
  - Add macros for packaging Ansible collections

  * Sun Apr 19 2020 Igor Raits  - 2.9.7-3
  - Own /usr/share/ansible/collections/ansible_collections


Package:  awscli-1.18.41-1.fc33
Old package:  awscli-1.18.40-1.fc33
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.71 MiB
Size change:  -293 B
Changelog:
  * Sun Apr 19 2020 Gwyn Ciesla  - 1.18.41-1
  - 1.18.41


Package:  colordiff-1.0.19-1.fc33
Old package:  colordiff-1.0.18-7.fc32
Summary:  Color terminal highlighter for diff files
RPMs: colordiff
Size: 28.98 KiB
Size change:  385 B
Changelog:
  * Sun Apr 19 2020 Richard Fearn  - 1.0.19-1
  - Update to 1.0.19


Package:  cproto-4.7o-4.fc33
Old package:  cproto-4.7o-4.fc32
Summary:  Generates function prototypes and variable declarations from C 
code
RPMs: cproto
Size: 306.79 KiB
Size change:  -312 B

Package:  crawl-0.24.0-3.fc33
Old package:  crawl-0.24.0-2.fc32
Summary:  Roguelike dungeon exploration game
RPMs: crawl crawl-common-data crawl-tiles crawl-tiles-data
Size: 48.83 MiB
Size change:  93.54 KiB
Changelog:
  * Sun Apr 19 2020 Antonio Trande  - 0.24.0-3
  - Fix rhbz#1825629


Package:  drumkv1-0.9.13-1.fc33
Old package:  drumkv1-0.9.10-2.fc32
Summary:  An old-school drum-kit sampler
RPMs: drumkv1 lv2-drumkv1
Size: 3.09 MiB
Size change:  -171.85 KiB
Changelog:
  * Sun Apr 19 2020 Guido Aulisi  - 0.9.13-1
  - Update to 0.9.13
  - Enable OSC support
  - Some spec cleanup


Package:  dummy-test-package-crested-0-241.fc33
Old package:  dummy-test-package-crested-0-229.fc33
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 23.97 KiB
Size change:  721 B
Changelog:
  * Sun Apr 19 2020 packagerbot  - 0-230
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-231
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-232
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-233
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-234
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-235
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-236
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-237
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-238
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-239
  - rebuilt

  * Mon Apr 20 2020 packagerbot  - 0-240
  - rebuilt

  * Mon Apr 20 2020 packagerbot  - 0-241
  - rebuilt


Package:  dummy-test-package-gloster-0-259.fc33
Old package:  dummy-test-package-gloster-0-248.fc33
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 24.98 KiB
Size change:  660 B
Changelog:
  * Sun Apr 19 2020 packagerbot  - 0-249
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-250
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-251
  - rebuilt

  * Sun Apr 19 2020 packagerbot  - 0-252
  - rebuilt

  * Sun Apr 19 2020

Re: fedpkg clone fails with Permission denied (publickey).

[Kevin Fenzi]

On Mon, Apr 20, 2020 at 11:11:39AM +0200, Pavel Zhukov wrote:
> Hi,
> 
> I've changed my FAS ssh key and it's not updated for a few hours
> (fedorapeople and pkgs both have an old one). Should I report the
> issue somewhere?

Yes, you should report it to infrastructure: 

https://pagure.io/fedora-infrastructure/issues/

But it should be fixed now. I've changed things so
pkgs/src.fedoraproject.org and fedorapeople.org update ssh keys every
15min now. 

kevin

PS: I'm subscribed to the list, there's no need to cc me on posts. :) 

kevin
--
> 
> Thank you
> 
> On Sun, Mar 29, 2020 at 8:35 PM Kevin Fenzi  wrote:
> >
> > On Sun, Mar 29, 2020 at 12:32:33PM -0500, Richard Shaw wrote:
> > > Long story short I lost my home directory where I do all of my packager
> > > activities (separate from my main user) so I'm setting things up from
> > > scratch.
> > >
> > > I created new ssh keys and uploaded the public key to
> > > admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
> > > and I'm still getting:
> >
> > Yeah, please try again now.
> >
> > Currently the sync time is really long due to various reasons.
> > I'll try and impove this next week...
> >
> > In the mean time I have done a manual sync.
> >
> > kevin
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> 
> -- 
> Pavel Zhukov
> Software Engineer
> IRC: landgraf


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for testers for rpmautospec in staging

[Kevin Fenzi]

Note: I'm subscribed to the list, there's no need to CC me. :) 

On Mon, Apr 20, 2020 at 11:45:17AM +0200, Nicolas Mailhot wrote:
> Hi,
> 
> Another solution would be to just save the state from which autobump is
> computed in the srpm, and bump from this state at the rpmbuild level.

How would that look? an untracked by git file with called 'releasever'
and having the releasever number in it?

> As long as the previous counter value is available computing a new one
> is just a few lines of lua macro code
> 
> That would remove any adherence to
> koji, mock or Fedora git.

Can you provide an example?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-33-20200420.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Passed openQA tests: 8/8 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FedoraRespin-31-updates-20200420.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 4/37 (x86_64)

ID: 581662  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/581662
ID: 581674  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/581674
ID: 581702  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/581702
ID: 581707  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/581707

Soft failed openQA tests: 2/37 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 581678  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/581678
ID: 581685  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/581685

Passed openQA tests: 31/37 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 32 Candidate RC-1.4 Available Now!

[rawhide]

According to the schedule [1], Fedora 32 Candidate RC-1.4 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.4_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-32/f-32-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_32_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] [Fedora Test Week] Kernel 5.6 Test Week Results

[Sumantro Mukherjee]

Aloha Testers!

Thanks a lot for everyone who participated in the Kernel 5.6 Test Week
last week[0].
The Test Week was very successful, and we've got:

259 tests ran who actually submitted results.
54 of those were with the newer 5.6.3 kernel showing the advantage of
this being a test week.
10 of those were non x86_64

Thanks Justin Forbes(jforbes) for building the images and all the
folks who helped!

[0] https://fedoraproject.org/wiki/Test_Day:2020-04-13_Kernel_5.6_Test_Week

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org