Fedora-Cloud-30-20200304.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

Fedora rawhide compose report: 20200303.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200302.n.1
NEW: Fedora-Rawhide-20200303.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  4
Dropped packages:2
Upgraded packages:   146
Downgraded packages: 0

Size of added packages:  4.33 MiB
Size of dropped packages:89.39 MiB
Size of upgraded packages:   2.77 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200302.n.1.iso

= ADDED PACKAGES =
Package: golang-github-viant-toolbox-0.30.0-1.fc33~bootstrap
Summary: Go utility library
RPMs:golang-github-viant-toolbox-devel
Size:142.96 KiB

Package: libgit2_0.28-0.28.4-1.fc33
Summary: C implementation of the Git core methods as a library with a solid API
RPMs:libgit2_0.28 libgit2_0.28-devel
Size:4.07 MiB

Package: rust-humantime1-1.3.0-1.fc33
Summary: Parser and formatter for std::time::{Duration, SystemTime}
RPMs:rust-humantime1+default-devel rust-humantime1-devel
Size:31.37 KiB

Package: topline-0.3-1.fc33
Summary: Per-core/NUMA CPU and disk utilization plain-text grapher
RPMs:topline
Size:99.12 KiB


= DROPPED PACKAGES =
Package: openvswitch-ovn-kubernetes-0.1.0-8.fc32
Summary: Open Virtual Networking Kubernetes Wedge
RPMs:openvswitch-ovn-kubernetes
Size:89.37 MiB

Package: python-bz2file-0.98-9.fc30
Summary: Read and write bzip2-compressed files
RPMs:python3-bz2file
Size:18.54 KiB


= UPGRADED PACKAGES =
Package:  FAudio-20.03-1.fc33
Old package:  FAudio-20.02-1.fc32
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 792.65 KiB
Size change:  6.21 KiB
Changelog:
  * Mon Mar 02 2020 Michael Cronenworth  - 20.03-1
  - Update to 20.03


Package:  Mayavi-4.7.1-2.fc33
Old package:  Mayavi-4.7.1-2.fc32
Summary:  Scientific data 3-dimensional visualizer
RPMs: Mayavi Mayavi-doc python3-mayavi
Size: 87.80 MiB
Size change:  -21.21 KiB

Package:  OpenImageIO-2.1.12.0-1.fc33
Old package:  OpenImageIO-2.1.11.1-1.fc33
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 19.73 MiB
Size change:  -16.73 KiB
Changelog:
  * Tue Mar 03 2020 Richard Shaw  - 2.1.12.0-1
  - Update to 2.1.12.0.


Package:  R-unitizer-1.4.9-1.fc33
Old package:  R-unitizer-1.4.8-4.fc32
Summary:  Interactive R Unit Tests
RPMs: R-unitizer
Size: 1.37 MiB
Size change:  -1.05 KiB
Changelog:
  * Mon Mar 02 2020 Elliott Sales de Andrade  - 
1.4.9-1
  - Update to latest version


Package:  adwaita-icon-theme-3.35.92-1.fc33
Old package:  adwaita-icon-theme-3.35.91-1.fc33
Summary:  Adwaita icon theme
RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel
Size: 11.27 MiB
Size change:  42.72 KiB
Changelog:
  * Mon Mar 02 2020 Kalev Lember  - 3.35.92-1
  - Update to 3.35.92


Package:  at-spi2-atk-2.34.2-1.fc33
Old package:  at-spi2-atk-2.34.1-2.fc32
Summary:  A GTK+ module that bridges ATK to D-Bus at-spi
RPMs: at-spi2-atk at-spi2-atk-devel
Size: 595.84 KiB
Size change:  1.82 KiB
Changelog:
  * Mon Mar 02 2020 Kalev Lember  - 2.34.2-1
  - Update to 2.34.2


Package:  at-spi2-core-2.35.92-1.fc33
Old package:  at-spi2-core-2.35.1-2.fc32
Summary:  Protocol definitions and daemon for D-Bus at-spi
RPMs: at-spi2-core at-spi2-core-devel
Size: 1.79 MiB
Size change:  -699 B
Changelog:
  * Mon Mar 02 2020 Kalev Lember  - 2.35.92-1
  - Update to 2.35.92


Package:  bowtie-1.2.3-1.fc33
Old package:  bowtie-1.0.1-14.fc32
Summary:  An ultrafast, memory-efficient short read aligner
RPMs: bowtie
Size: 33.14 MiB
Size change:  -640.37 KiB
Changelog:
  * Fri Feb 28 2020 Jun Aruga  - 1.2.3-1
  - Update to upstream release 1.2.3


Package:  clutter-1.26.2-11.fc33
Old package:  clutter-1.26.2-10.fc32
Summary:  Open Source software library for creating rich graphical user 
interfaces
RPMs: clutter clutter-devel clutter-doc clutter-tests
Size: 12.63 MiB
Size change:  -2.52 KiB
Changelog:
  * Tue Mar 03 2020 Kalev Lember  - 1.26.2-11
  - Backport fixes for 10-bit color (#1800865)


Package:  cmake-3.17.0-0.3.rc2.fc33
Old package:  cmake-3.17.0-0.2.rc1.fc33
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 52.74 MiB
Size change:  103.03 KiB
Changelog:
  * Tue Mar 03 2020 Bj??rn Esser  - 3.17.0-0.3.rc2
  - Update to 3.17.0-rc2


Package:  conserver-8.2.2-6.fc33
Old package:  conserver-8.2.2-3.fc30
Summary:  Serial console server daemon/client
RPMs: conserver

Re: Automatic close of bugs for retired packages?

[Kevin Fenzi]

On Wed, Feb 26, 2020 at 07:47:24PM +0100, Miro Hrončok wrote:
> On 26. 02. 20 19:38, Ben Cotton wrote:
> > Components can be marked inactive in Bugzilla, which I believe will
> > prevent users from filing new bugs without losing any historical data.
> 
> Correct. We have done this with the "python" component.

We actually automatically do this now on package retirement. 

However, we haven't (yet) gone back and set all the old retired packages
this way. 

https://pagure.io/fedora-infrastructure/issue/8707 

tracks that work. 

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

Re: Non-responsive maintainer: pocock

[Daniel Pocock]

On 03/03/2020 18:50, Kevin Fenzi wrote:
> On Tue, Mar 03, 2020 at 05:52:10PM +0100, Daniel Pocock wrote:
>>
>> Thanks for doing that
>>
>> Here are some observations:
>>
>> - the original email was sent to my pocock.com.au address and so my mail
>> client replied to all mails using that address, I didn't notice until
>> now.  That address is not subscribed.
>>
>> - my other address, pocock.pro, is subscribed
>>
>> - the list didn't give me any bounces or alerts that messages were held.
>>  At least some lists give warnings when a mail is sent from an address
>> that is not subscribed
> 
> Odd. I see the list replying back with a bounce: 
> 
> Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/smtp[5786]: 
> 5C39C5D35D048: to=, relay=bast
> ion.phx2.fedoraproject.org[10.5.126.12]:25, delay=0.15, 
> delays=0.01/0/0.03/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: qu
> eued as 655CF601EA0C)
> Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/qmgr[7288]: 
> 5C39C5D35D048: removed
> Mar  3 09:10:34 bastion01.phx2.fedoraproject.org postfix/smtp[13250]: 
> 655CF601EA0C: to=, relay=mail
> .trendhosting.net[195.8.117.5]:25, delay=2.4, delays=0.1/0/1.3/0.95, 
> dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 0E2A
> 0150D5)
> 

Thanks for clarifying that - I found those bounces, but here is what I
notice:

- they are not being threaded, so I didn't see them in the folder until
I looked for them

- their subject line isn't changed to look like a bounce, so they didn't
catch my eye

On a more quiet list these probably would have been noticed earlier but
I think that for a busy list, they need to be more visible, e.g. by
putting them in the thread AND putting some prefix on the subject.  Here
is what I see:

From:  devel-ow...@lists.fedoraproject.org
Subject:   Re: Non-responsive maintainer: pocock

>>
>> - the last message sent from the pocock.pro address was on 19 August, it
>> was delivered to the list but only with a delay of 9 minutes
>>
>> - the message prior to that was delayed by 20 hours inside Fedora:
>>
>> Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
>>  by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
>> CCE3858968E1E;
>>  Fri,  2 Aug 2019 14:43:36 + (UTC)
>> Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
>>  id DCFA658968E12; Thu,  1 Aug 2019 18:25:21 + (UTC)
> 
> From my notes, that was a time when gmail was blocking several folks who
> were asking for 'all fedmsgs as emails please'. ie, I see in irc at the
> time I said: 
> Aug 02 08:50:38  cool... 183,000 emails in bastion01's mail queue. 
> wh. 
> 
> So, it took a while for them to process, your email wasn't blocked by
> any moderator. 
> 
>> Combined with the blog censorship and other things going on in various
>> places, this type of observation is not very motivating but I do
>> understand things sometimes go wrong for technical reasons.
> 
> Do note that censorship means a gov entity blocking your right to free
> speach. The Fedora Project is not a government. We reserve the right to

This particular point has been argued about elsewhere.  While I don't
agree with your perspective, I don't feel the distinction is relevant
anyway because...

> tell people they shouldn't use our platform for their speach. In
> particular when it's not related to our mission.
> 
> That said, if you have questions about that, feel free to file a council
> ticket/mail the council for clarification. 
> 

... the bigger problem is simply confusion and confidence.  Whether
Fedora is a Government or not, and Fedora is certainly more influential
than some micro-nations[1], disappearing messages and disappearing blogs
can create confusion.  I finished my email with the disclaimer that
things can go wrong for technical reasons but some people aren't so open
minded.  Problems have been spilling over between communities in the
last couple of years and I've been shown emails demonstrating that the
leaders of two independent organizations decided to share information
about who to moderate/censor.  The experience I had with Planet Fedora
also contributed to a greater sense of suspicion, in other words, more
confusion, less effort made to hunt for the bounces.  That is time
wasted for both of us.

As a developer, I started writing a script (it is not public yet) to
scan Received headers and let me know when other developers or my own
messages experience trouble.  Think of it like the canary in the coal
mine.  The canary has already been BBQed[2] several times over in FSF.

Think about the feeling you get when you write a detailed bug report and
somebody closes it too quickly or you submit a patch and it is rejected
without any discussion.  Many developers simply lose confidence if they
feel their work is not even being looked at and they walk away without
saying anything.  This is not about being a Government or not, it is
simply about ensuring people feel that writing an email, b

Re: Non-responsive maintainer: pocock

[Dakota Williams via devel]

On 3/3/20 4:10 AM, Daniel Pocock wrote:



On 28/02/2020 10:00, Ankur Sinha wrote:

On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote:

On 2/26/20 6:59 PM, Daniel Pocock wrote:



Would you like help? I'd be willing to be a co-maintainer to make the
branch.


Yes, I would welcome help with these packages

But there is also an increasing problem of making decisions about trust

In the case of developers who I haven't met or worked with, I don't
really know how to proceed

I've seen several extraordinary examples of developers doing things that
undermine my confidence in them over the last couple of years.  The
fighting within GNU and FSF right now is the latest iteration of that.

Now, whenever I receive a request from somebody I don't know, there is
an extra effort for me to decide how to proceed.

Maybe I can simply resign from maintaining the asio package and then opt
out of the process of choosing a new maintainer.

Please don't take this personally: it is a reflection of the overall
state of free software communities today.


I don't know about the situation with the GNU project and the FSF, but if
there's something you'd like me to do to prove trust, I could do it.


I'd like to add that by default we trust each other, in the spirit of
being excellent to each other. In this particular case,


Why, then, have my replies to this thread never appeared in the mailing
list then, only to the people on CC?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/

My own statement wasn't directed at any particular maintainer and
doesn't imply that I am ungrateful for any offers of help.  I am very
grateful for those people, including Dakota, who reached out in a
positive way.

Trust is not a constant thing, it can change over time.  The wider
atmosphere and the disappearance of messages from mailing lists
contributes to lower confidence.

Unfortunately, I now see several emails every week (not necessarily from
the Fedora mailing lists) that cause suspicion and concern.  I then feel
a need to look at every other interaction more carefully.

When I mentioned the death of my father in a blog recently, my blog was
removed from Planet Fedora.  Now it seems my emails go to a moderator
who doesn't have the time to keep up with all those censorship duties.
I find this behaviour incredibly insulting and degrading, I suspect
anybody in my position would feel the same way.


co-maintainership shares responsibility but does not hand it over
completely (the handing-over bit can be done at a later stage, if
necessary). Every change/commit/message is public, so there are plenty
of opportunities to catch any errors.

Given that we do not often meet our Fedora colleagues in person, it is
not viable to expect members of the community to prove trustworthiness
through personal relationships. We assume the best in each other, and if
things do get hairy, we have open community channels, processes, and
overseeing bodies through which changes can be emended.


My email was not a request for Dakota or anybody else to prove
trustworthiness, it was only a reflection of my own perception of things
going on in the wider free software community.

But based on what you say, I'm happy to give access to Dakota and I'd
also like to know if anybody else can help with the reSIProcate
packages.  There is a new release in the pipeline and if somebody wants
to get involved, now is the time.  We already made all the upstream
fixes required for it to work with the latest dependencies on Fedora.


Great, my FAS id is "raineforest". Where would you like me to start?
___
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: updates-testing and koji

[Scott Talbert]

On Tue, 3 Mar 2020, Iñaki Ucar wrote:


Quick question: if a new package A is in updates-testing, is it
available for koji to build another new package B that requires A? Or
do I need to wait until A reaches stable?


No, it is not available in the buildroot until it reaches stable. 
However, you can submit a buildroot override to temporarily make it 
available in the buildroot for other builds.  See:


https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides___
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

updates-testing and koji

[Iñaki Ucar]

Hi all,

Quick question: if a new package A is in updates-testing, is it
available for koji to build another new package B that requires A? Or
do I need to wait until A reaches stable?

Regards,
Iñaki
___
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

Filtering devel list e-mail

[Miro Hrončok]

On 28. 02. 20 11:21, Radka Janekova wrote:
> Please excuse me going completely offtopic here - for some reason I'm getting
> this thread addressed directly to me. If someone's adding me as bcc please
> don't, I have nothing to do with this.

Hey Radka.

Do you filter devel list via the "List-Id:" or "To:" header? Is it possible that 
you get this to your inbox because the devel list was cc'ed, not you?


--
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: __pycache__ in /usr/share

[Miro Hrončok]

On 03. 03. 20 17:07, Steve Grubb wrote:

According to the Linux FHS standard, /usr/share is supposed to only contain
data. Executables have other places to live. If we can assume that there is
only data in /usr/share, then we can remove about 330k of the items from our
trust database.


The files are architecture-independent. We've even been told in the past that 
noarch Python modules should live in /usr/share. I don't claim to be an expert 
on FHS, but apparently this is not that simple.


https://bugzilla.redhat.com/show_bug.cgi?id=543756

--
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: Plan to retire mapserver

[Julien Enselme]

Le mardi 3 mars 2020, 11:19:31 CET Sandro Mani a écrit :
> On 02.03.20 15:06, Julien Enselme wrote:
> > Hi all,
> > 
> > I intend to retire the mapserver package
> > (https://src.fedoraproject.org/rpms/mapserver). I don't use it any more
> > and it fails to build for F32. If you want to maintain it, please step
> > up!
> I can maintain it, my FAS is smani
> 
> Thanks
> Sandro

It looks I am only a committer on this package. I completely forgot that ^^. I 
guess the other maintainers where very active for it lately. You should 
contact them directly. Sorry about the inconvenience.

Regards,
Julien

___
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: Non-responsive maintainer: pocock

[Radka Janekova]

On Fri, Feb 28, 2020 at 1:39 PM Daniel Pocock  wrote:

>
> On 28/02/2020 11:21, Radka Janekova wrote:
> > Please excuse me going completely offtopic here - for some reason I'm
> > getting this thread addressed directly to me. If someone's adding me as
> > bcc please don't, I have nothing to do with this.
>
>
> A lot of people are using CC or BCC, as described in the Fellowship
> blog[1], due to censorship problems and culture wars.  For example, some
> messages in this thread don't appear at all in the list archives[2].  Why?
>

Honestly I do not care what so ever. Nobody should bother people with their
emails - especially since most of us take a lot of care to not miss very
important work emails among the hundreds, if not even thousands of emails
that we receive every day (I personally received 250 emails only today, and
it's just the beginning of the NA timezone. By the time I wake up tomorrow
it sure will be 400 or more.) Within this amount of emails even with
complex filters in place, a responsible engineer will read through the
subject lines of every email at least in the relevant mailing lists. Email
like this one, with some sneaky bcc being added every 4th email so that the
thread keeps reappearing even after it's dismissed, gets ignored by that
complex system of filters, because the filter doesn't actually see why did
I receive this email. As such it lands in my HIGH PRIORITY inbox. This
freaks me out. Please stop.

If you have issues with sending emails to anything, contact administrators.
This is not a solution. If anything you will get your own email flagged as
spam by large number of people, which will lead exactly to what you're
trying to prevent/circumvent, just worse.


> If you see something like that, please share the full headers so we can
> all see how the message reached you, otherwise it is ambiguous.
>
> Regards,
>
> Daniel
>
>
> 1. https://fsfellowship.eu/freedom-and-censorship-on-mailing-lists/
> 2.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/
>
>
___
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: GNOME 3.35.92 megaupdate

[Igor Gnatenko]

It is basically the same. The only difference is that name of the tag.

On Mon, Mar 2, 2020 at 3:18 PM Kalev Lember  wrote:
>
>
> On 3/2/20 15:04, Richard Shaw wrote:
> > On Mon, Mar 2, 2020 at 7:57 AM Kalev Lember  > > wrote:
> >
> >
> > Hi all,
> >
> > I am putting together a megaupdate for GNOME 3.35.92. If you are
> > helping
> > with builds, please wait until we have the f32-gnome side tag
> > (requested
> > in https://pagure.io/releng/issue/9292) and then do the F32 builds with
> > 'fedpkg build --target f32-gnome'. I'll collect all the builds tagged
> > with f32-gnome for the megaupdate and submit them to Bodhi all together.
> >
> >
> > I thought you could just use 'fedpkg request-side-tag [...]" at this point?
>
> Yes, but this is meant for short lived side tags, not for something that
> we keep around for months to coordinate updates between a number of people.
>
> --
> Kalev
> ___
> 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: __pycache__ in /usr/share

[Steve Grubb]

On Tuesday, March 3, 2020 12:45:08 PM EST Robbie Harwood wrote:
> Steve Grubb  writes:
> > Hello,
> > 
> > We are working on Application Whitelisting. For this to work, we need
> > to have a list of things that we trust. At the moment, that list is
> > well over 400k on a desktop install. But we really need to get that
> > smaller.
> 
> Not that I disagree, but... to what end?  What's the goal?

The goal is to reduce memory consumption and search time. Right now it takes 
about 165 MB of virtual memory to hold the database. Binary trees are very 
efficient in searching, but why search 400k when the items that need to be 
trusted is really more like 50k. I'm trying to think of time efficient ways of 
pruning the list.

I suppose I can call fnmatch 400k times to keep these python byte code 
caches, but I suspect they don't really belong there.

-Steve

___
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: Non-responsive maintainer: pocock

[Kevin Fenzi]

On Tue, Mar 03, 2020 at 05:52:10PM +0100, Daniel Pocock wrote:
> 
> Thanks for doing that
> 
> Here are some observations:
> 
> - the original email was sent to my pocock.com.au address and so my mail
> client replied to all mails using that address, I didn't notice until
> now.  That address is not subscribed.
> 
> - my other address, pocock.pro, is subscribed
> 
> - the list didn't give me any bounces or alerts that messages were held.
>  At least some lists give warnings when a mail is sent from an address
> that is not subscribed

Odd. I see the list replying back with a bounce: 

Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/smtp[5786]: 
5C39C5D35D048: to=, relay=bast
ion.phx2.fedoraproject.org[10.5.126.12]:25, delay=0.15, 
delays=0.01/0/0.03/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: qu
eued as 655CF601EA0C)
Mar  3 09:10:32 mailman01.phx2.fedoraproject.org postfix/qmgr[7288]: 
5C39C5D35D048: removed
Mar  3 09:10:34 bastion01.phx2.fedoraproject.org postfix/smtp[13250]: 
655CF601EA0C: to=, relay=mail
.trendhosting.net[195.8.117.5]:25, delay=2.4, delays=0.1/0/1.3/0.95, dsn=2.0.0, 
status=sent (250 2.0.0 Ok: queued as 0E2A
0150D5)

> 
> - the last message sent from the pocock.pro address was on 19 August, it
> was delivered to the list but only with a delay of 9 minutes
> 
> - the message prior to that was delayed by 20 hours inside Fedora:
> 
> Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
>   by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
> CCE3858968E1E;
>   Fri,  2 Aug 2019 14:43:36 + (UTC)
> Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
>   id DCFA658968E12; Thu,  1 Aug 2019 18:25:21 + (UTC)

From my notes, that was a time when gmail was blocking several folks who
were asking for 'all fedmsgs as emails please'. ie, I see in irc at the
time I said: 
Aug 02 08:50:38  cool... 183,000 emails in bastion01's mail queue. 
wh. 

So, it took a while for them to process, your email wasn't blocked by
any moderator. 

> Combined with the blog censorship and other things going on in various
> places, this type of observation is not very motivating but I do
> understand things sometimes go wrong for technical reasons.

Do note that censorship means a gov entity blocking your right to free
speach. The Fedora Project is not a government. We reserve the right to
tell people they shouldn't use our platform for their speach. In
particular when it's not related to our mission.

That said, if you have questions about that, feel free to file a council
ticket/mail the council for clarification. 

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

Re: __pycache__ in /usr/share

[Robbie Harwood]

Steve Grubb  writes:

> Hello,
>
> We are working on Application Whitelisting. For this to work, we need
> to have a list of things that we trust. At the moment, that list is
> well over 400k on a desktop install. But we really need to get that
> smaller.

Not that I disagree, but... to what end?  What's the goal?

Thanks,
--Robbie


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: GNOME 3.35.92 megaupdate

[Kalev Lember]

On 3/2/20 17:52, Kalev Lember wrote:

On 3/2/20 14:55, Kalev Lember wrote:


Hi all,

I am putting together a megaupdate for GNOME 3.35.92. If you are 
helping with builds, please wait until we have the f32-gnome side tag 
(requested in https://pagure.io/releng/issue/9292) and then do the F32 
builds with 'fedpkg build --target f32-gnome'. I'll collect all the 
builds tagged with f32-gnome for the megaupdate and submit them to 
Bodhi all together.


OK, the side tag should be in place now.



The 3.35.92 megaupdate is now in updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-405622043a

We split out gjs 1.63.92 as that fixes a blocker issue:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-49097e4ddc

--
Kalev
___
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-20200303.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 24/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200302.n.0):

ID: 531292  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/531292
ID: 531317  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/531317

Old failures (same test failed in Fedora-32-20200302.n.0):

ID: 531249  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/531249
ID: 531251  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/531251
ID: 531275  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/531275
ID: 531282  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/531282
ID: 531299  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/531299
ID: 531306  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/531306
ID: 531315  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/531315
ID: 531329  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/531329
ID: 531332  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/531332
ID: 531334  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/531334
ID: 531335  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/531335
ID: 531344  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/531344
ID: 531345  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/531345
ID: 531352  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/531352
ID: 531355  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/531355
ID: 531357  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/531357
ID: 531360  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/531360
ID: 531373  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/531373
ID: 531385  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/531385
ID: 531392  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/531392
ID: 531393  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/531393
ID: 531398  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/531398
ID: 531399  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/531399

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

New soft failures (same test not soft failed in Fedora-32-20200302.n.0):

ID: 531302  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/531302

Old soft failures (same test soft failed in Fedora-32-20200302.n.0):

ID: 531227  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/531227
ID: 531228  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/531228
ID: 531232  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/531232
ID: 531235  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/531235
ID: 531236  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/531236
ID: 531256  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/531256
ID: 531285  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/531285
ID: 531287  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/531287
ID: 531319  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/531319
ID: 531328  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/531328
ID: 531346  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/531346
ID: 531381  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/531381
ID: 531384  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/53138

Fedora-IoT-32-20200303.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 1/8 (x86_64)

New failures (same test not failed in Fedora-IoT-32-20200302.0):

ID: 531573  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/531573

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

Old soft failures (same test soft failed in Fedora-IoT-32-20200302.0):

ID: 531571  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/531571
ID: 531572  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/531572

Passed openQA tests: 5/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) added since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-6c6db589\x2d3f17\x2d4146\x2da34e\x2d1eea51f36774.service
1 services(s) removed since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-0f0bc31b\x2dc624\x2d443c\x2da704\x2da7070ebedc92.service
Previous test data: https://openqa.fedoraproject.org/tests/530758#downloads
Current test data: https://openqa.fedoraproject.org/tests/531571#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
2 services(s) added since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-3704b4ef\x2d2bd6\x2d4c8e\x2d922e\x2d1008637a42ff.service,
   systemd-fsck@dev-disk-by\x2duuid-80F4\x2dDD4F.service
2 services(s) removed since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-36C6\x2d9573.service,   
systemd-fsck@dev-disk-by\x2duuid-7961054d\x2dbf51\x2d413c\x2d9492\x2d100e7ffcbb95.service
Previous test data: https://openqa.fedoraproject.org/tests/530759#downloads
Current test data: https://openqa.fedoraproject.org/tests/531572#downloads
-- 
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: Non-responsive maintainer: pocock

[Daniel Pocock]

On 03/03/2020 17:35, Neal Gompa wrote:
> On Tue, Mar 3, 2020 at 4:10 AM Daniel Pocock  wrote:
>>
>>
>>
>> On 28/02/2020 10:00, Ankur Sinha wrote:
>>> On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote:
 On 2/26/20 6:59 PM, Daniel Pocock wrote:
 
>>
>> Would you like help? I'd be willing to be a co-maintainer to make the
>> branch.
>
> Yes, I would welcome help with these packages
>
> But there is also an increasing problem of making decisions about trust
>
> In the case of developers who I haven't met or worked with, I don't
> really know how to proceed
>
> I've seen several extraordinary examples of developers doing things that
> undermine my confidence in them over the last couple of years.  The
> fighting within GNU and FSF right now is the latest iteration of that.
>
> Now, whenever I receive a request from somebody I don't know, there is
> an extra effort for me to decide how to proceed.
>
> Maybe I can simply resign from maintaining the asio package and then opt
> out of the process of choosing a new maintainer.
>
> Please don't take this personally: it is a reflection of the overall
> state of free software communities today.
>
 I don't know about the situation with the GNU project and the FSF, but if
 there's something you'd like me to do to prove trust, I could do it.
>>>
>>> I'd like to add that by default we trust each other, in the spirit of
>>> being excellent to each other. In this particular case,
>>
>> Why, then, have my replies to this thread never appeared in the mailing
>> list then, only to the people on CC?
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/
>>
> 
> I do not know why. I have filed an issue with infrastructure to find
> out: https://pagure.io/fedora-infrastructure/issue/8713


Thanks for doing that

Here are some observations:

- the original email was sent to my pocock.com.au address and so my mail
client replied to all mails using that address, I didn't notice until
now.  That address is not subscribed.

- my other address, pocock.pro, is subscribed

- the list didn't give me any bounces or alerts that messages were held.
 At least some lists give warnings when a mail is sent from an address
that is not subscribed

- the last message sent from the pocock.pro address was on 19 August, it
was delivered to the list but only with a delay of 9 minutes

- the message prior to that was delayed by 20 hours inside Fedora:

Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
CCE3858968E1E;
Fri,  2 Aug 2019 14:43:36 + (UTC)
Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
id DCFA658968E12; Thu,  1 Aug 2019 18:25:21 + (UTC)

Combined with the blog censorship and other things going on in various
places, this type of observation is not very motivating but I do
understand things sometimes go wrong for technical reasons.


>> My own statement wasn't directed at any particular maintainer and
>> doesn't imply that I am ungrateful for any offers of help.  I am very
>> grateful for those people, including Dakota, who reached out in a
>> positive way.
>>
>> Trust is not a constant thing, it can change over time.  The wider
>> atmosphere and the disappearance of messages from mailing lists
>> contributes to lower confidence.
>>
>> Unfortunately, I now see several emails every week (not necessarily from
>> the Fedora mailing lists) that cause suspicion and concern.  I then feel
>> a need to look at every other interaction more carefully.
>>
>> When I mentioned the death of my father in a blog recently, my blog was
>> removed from Planet Fedora.  Now it seems my emails go to a moderator
>> who doesn't have the time to keep up with all those censorship duties.
>> I find this behaviour incredibly insulting and degrading, I suspect
>> anybody in my position would feel the same way.
>>
> 
> I'm sorry about that. I don't know what happened there either.
> 
>>> co-maintainership shares responsibility but does not hand it over
>>> completely (the handing-over bit can be done at a later stage, if
>>> necessary). Every change/commit/message is public, so there are plenty
>>> of opportunities to catch any errors.
>>>
>>> Given that we do not often meet our Fedora colleagues in person, it is
>>> not viable to expect members of the community to prove trustworthiness
>>> through personal relationships. We assume the best in each other, and if
>>> things do get hairy, we have open community channels, processes, and
>>> overseeing bodies through which changes can be emended.
>>
>> My email was not a request for Dakota or anybody else to prove
>> trustworthiness, it was only a reflection of my own perception of things
>> going on in the wider free software community.
>>
>> B

Re: __pycache__ in /usr/share

[Steve Grubb]

On Tuesday, March 3, 2020 11:35:07 AM EST Miroslav Suchý wrote:
> Dne 03. 03. 20 v 17:07 Steve Grubb napsal(a):
> > However, I'm finding that on a typical system, there are about 20
> > packages  that place python byte code in /usr/share.
> 
> Can you elaborate? Which packages? What files?

Sure. Files:
# find /usr/share/ -type d -name __pycache__ | cut -d'/' -f1-4 | sort | uniq
/usr/share/authconfig
/usr/share/cinnamon-screensaver
/usr/share/crypto-policies
/usr/share/doc
/usr/share/gcc-9
/usr/share/gdb
/usr/share/gedit
/usr/share/glib-2.0
/usr/share/gtk-doc
/usr/share/ibus
/usr/share/ibus-hangul
/usr/share/ibus-libpinyin
/usr/share/ibus-libzhuyin
/usr/share/ibus-typing-booster
/usr/share/lorax
/usr/share/rpmlint
/usr/share/setroubleshoot
/usr/share/system-config-printer
/usr/share/system-config-selinux
/usr/share/virt-manager

Packages:
$ find /usr/share/ -type d -name __pycache__ | cut -d'/' -f1-4 | sort | uniq | 
xargs rpm -qf
file /usr/share/authconfig is not owned by any package
cinnamon-screensaver-4.4.1-1.fc31.x86_64
crypto-policies-20191128-2.gitcd267a5.fc31.noarch
filesystem-3.12-2.fc31.x86_64
libstdc++-9.2.1-1.fc31.x86_64
libstdc++-9.2.1-1.fc31.x86_64
gdb-headless-8.3.50.20190824-30.fc31.x86_64
glib2-devel-2.62.5-1.fc31.x86_64
gedit-3.34.1-1.fc31.x86_64
glib2-2.62.5-1.fc31.x86_64
polkit-docs-0.116-4.fc31.1.noarch
harfbuzz-devel-2.6.1-2.fc31.x86_64
gtk-doc-1.29-4.fc31.x86_64
p11-kit-devel-0.23.20-1.fc31.x86_64
libxml2-devel-2.9.10-3.fc31.x86_64
ibus-1.5.21-9.fc31.x86_64
ibus-hangul-1.5.3-1.fc31.x86_64
ibus-libpinyin-1.11.1-2.fc31.x86_64
ibus-libzhuyin-1.9.1-2.fc31.x86_64
ibus-typing-booster-2.8.0-1.fc31.noarch
file /usr/share/lorax is not owned by any package
rpmlint-1.11-3.fc31.noarch
setroubleshoot-server-3.3.20-3.fc31.x86_64
system-config-printer-libs-1.5.12-3.fc31.noarch
policycoreutils-gui-2.9-5.fc31.noarch
virt-manager-common-2.2.1-2.fc31.noarch

I guess the authconfig one is a leftover from previous version of Fedora.

-Steve

> -- 
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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/de...@lists.fedoraproject.or
> g



___
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: Non-responsive maintainer: pocock

[Neal Gompa]

On Tue, Mar 3, 2020 at 4:10 AM Daniel Pocock  wrote:
>
>
>
> On 28/02/2020 10:00, Ankur Sinha wrote:
> > On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote:
> >> On 2/26/20 6:59 PM, Daniel Pocock wrote:
> >> 
> 
>  Would you like help? I'd be willing to be a co-maintainer to make the
>  branch.
> >>>
> >>> Yes, I would welcome help with these packages
> >>>
> >>> But there is also an increasing problem of making decisions about trust
> >>>
> >>> In the case of developers who I haven't met or worked with, I don't
> >>> really know how to proceed
> >>>
> >>> I've seen several extraordinary examples of developers doing things that
> >>> undermine my confidence in them over the last couple of years.  The
> >>> fighting within GNU and FSF right now is the latest iteration of that.
> >>>
> >>> Now, whenever I receive a request from somebody I don't know, there is
> >>> an extra effort for me to decide how to proceed.
> >>>
> >>> Maybe I can simply resign from maintaining the asio package and then opt
> >>> out of the process of choosing a new maintainer.
> >>>
> >>> Please don't take this personally: it is a reflection of the overall
> >>> state of free software communities today.
> >>>
> >> I don't know about the situation with the GNU project and the FSF, but if
> >> there's something you'd like me to do to prove trust, I could do it.
> >
> > I'd like to add that by default we trust each other, in the spirit of
> > being excellent to each other. In this particular case,
>
> Why, then, have my replies to this thread never appeared in the mailing
> list then, only to the people on CC?
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JGCY5GM42SR2BEXGNUP6C335IFEV66KD/
>

I do not know why. I have filed an issue with infrastructure to find
out: https://pagure.io/fedora-infrastructure/issue/8713

> My own statement wasn't directed at any particular maintainer and
> doesn't imply that I am ungrateful for any offers of help.  I am very
> grateful for those people, including Dakota, who reached out in a
> positive way.
>
> Trust is not a constant thing, it can change over time.  The wider
> atmosphere and the disappearance of messages from mailing lists
> contributes to lower confidence.
>
> Unfortunately, I now see several emails every week (not necessarily from
> the Fedora mailing lists) that cause suspicion and concern.  I then feel
> a need to look at every other interaction more carefully.
>
> When I mentioned the death of my father in a blog recently, my blog was
> removed from Planet Fedora.  Now it seems my emails go to a moderator
> who doesn't have the time to keep up with all those censorship duties.
> I find this behaviour incredibly insulting and degrading, I suspect
> anybody in my position would feel the same way.
>

I'm sorry about that. I don't know what happened there either.

> > co-maintainership shares responsibility but does not hand it over
> > completely (the handing-over bit can be done at a later stage, if
> > necessary). Every change/commit/message is public, so there are plenty
> > of opportunities to catch any errors.
> >
> > Given that we do not often meet our Fedora colleagues in person, it is
> > not viable to expect members of the community to prove trustworthiness
> > through personal relationships. We assume the best in each other, and if
> > things do get hairy, we have open community channels, processes, and
> > overseeing bodies through which changes can be emended.
>
> My email was not a request for Dakota or anybody else to prove
> trustworthiness, it was only a reflection of my own perception of things
> going on in the wider free software community.
>
> But based on what you say, I'm happy to give access to Dakota and I'd
> also like to know if anybody else can help with the reSIProcate
> packages.  There is a new release in the pipeline and if somebody wants
> to get involved, now is the time.  We already made all the upstream
> fixes required for it to work with the latest dependencies on Fedora.
>

Thanks for granting Dakota maintainer privileges for asio! :)

I may be able to spare some cycles to help with reSIProcate (after I
get out of my mountain of FTBFS issues...). I'm sure other folks here
could help as well. :)


-- 
真実はいつも一つ！/ 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: __pycache__ in /usr/share

[Miroslav Suchý]

Dne 03. 03. 20 v 17:07 Steve Grubb napsal(a):
> However, I'm finding that on a typical system, there are about 20 packages 
> that place python byte code in /usr/share.

Can you elaborate? Which packages? What files?

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

__pycache__ in /usr/share

[Steve Grubb]

Hello,

We are working on Application Whitelisting. For this to work, we need to have 
a list of things that we trust. At the moment, that list is well over 400k on 
a desktop install. But we really need to get that smaller.

According to the Linux FHS standard, /usr/share is supposed to only contain 
data. Executables have other places to live. If we can assume that there is 
only data in /usr/share, then we can remove about 330k of the items from our 
trust database.

However, I'm finding that on a typical system, there are about 20 packages 
that place python byte code in /usr/share. Is it possible to move those 
python modules to another location? The packaging guidelines imply, but not 
require, that they belong over in /usr/lib64/ somewhere.

Reducing the trust database is important to the application whitelisting 
project. Does making /usr/share/ data only sound feasible?

Thanks,
-Steve

___
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

Review Swap

[clime]

Hello!

I would like to swap reviews with somebody.

Here is my bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1809644

The package is called preproc and it is a very simple text
preprocessor written in python.

More info:
Simple text preprocessor implementing a very basic templating
language. You can use bash code enclosed in triple braces in a text
file and then pipe content of that file to preproc. preproc will
replace each of the tags with stdout of the executed code and print
the final rendered result to its own stdout.

Has anyone got a package for review too?
Thank you
clime
___
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: 20200303.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200302.n.0
NEW: Fedora-32-20200303.n.0

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

Size of added packages:  0 B
Size of dropped packages:46.50 KiB
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 =
Package: python-bz2file-0.98-9.fc30
Summary: Read and write bzip2-compressed files
RPMs:python3-bz2file
Size:18.54 KiB

Package: sugar-xomail-0-0.20.20090128.fc31
Summary: Xomail for Sugar
RPMs:sugar-xomail
Size:27.96 KiB


= 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: [Fedora-packaging] Re: Ideas and proposal for removing changelog and release fields from spec file

[Nicolas Mailhot via devel]

Le 2020-03-03 15:14, clime a écrit :

On Tue, 3 Mar 2020 at 09:22, Nicolas Mailhot
 wrote:


Le 2020-03-02 14:45, clime a écrit :
> On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
>  wrote:
>>
>> Le 2020-03-01 02:31, clime a écrit :
>> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
>> >  wrote:
>> >>
>> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>>
>> >> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
>> >> detached file state means that fedpkg local (or checking out git state
>> >> and building in mock or copr or OBS or via plain rpmbuild -bs) will
>> >> give you the same result as launching fedpkg build.
>> >
>> > Well, I believe it doesn't. You run:
>> >
>> > 1) fedpkg local -> produces -1.0-1.fc32 (1 in release because
>> > you haven't built that package before)
>> > 2) fedpkg build
>>
>> At that point state is undefined till the build succeeds or not. If
>> the
>> build succeeds, the buildsystem will write back a new state. Let’s
>> assume it succeeds.
>
> It's undefined if you add more elements to the equation than necessary
> (i.e. build system), otherwise it would be well-defined in this case.
>
>>
>> > 3) vim .spec and do some change in %description
>> > 4) fedpkg commit -m "description improvement"
>> > 5) fedpkg local -> produces -1.0-1.fc32
>> > 6) fedpkg push -> error because build system pushed meanwhile
>>
>> Yes, here the packager notices something else has been going on, and
>> he
>> needs to merge or rebase. He’d have the same effect if another
>> packager
>> had been doing stuff on the package, or a mass rebuild had been going
>> on. That’s the distributed decentralized aspect of git, except here
>> the
>> packager collided with himself by starting two work threads in
>> parallel
>> (one buildsys-side, one local).
>
> The problem is that you launched some process and you need to wait
> until it finishes, normally you don't need to anything like that when
> working with git.

But fedpkg build is a release to production process. It’s not a dev
staging process. In release processes, actually doing the release is 
not

an inconvenient optional check.


Well, you could have a situation when somebody wants to immediately
continue working after making a release. Probably rare but could
happen and if build time of a package is long (libreOffice/firefox),
this could hit you as an inconvenience. Or do you want to push-back
immediately after srpm build when you don't yet know whether the build
will succeed? That wasn't clear to me before.


Either you lock the centralized branch while the build is ongoing or you 
fail the build if someone pushes to the centralized branch before the 
end of the build.


That does not stop packagers from preparing the next stage in a local 
branch, only changing the state of the centralized branch at the same 
time the build process is changing it (two conflicting release state 
changes, option 1: buildsystem wins, option 2, packager wins, can’t have 
an heisenstate where things are both released and not released).



I am not suggesting to use raw git commit messages for the changelog
but instead content of annotated tags which can be initially
prepopulated by commit messages but can be then edited to any extent
and even the way the edit window for annotated tag is prepopulated
might be configurable (to .e.g. load content from a file in which case
you would probably skip the editing part). And I see the annotated
tags as the actual releases.


The only actual release is the package built in koji. So, no matter what 
mechanism you use git side:
– you must represent the real state of package builds and not a git-only 
fiction
  → that means a form of buildsys write-back because builds can and will 
fail
– you must produce something packagers can also build in mock or copr or 
OBS or whatever
  → that means checkout-ing changelog data in a form that can be read by 
rpmbuild -bs

  → ie a file not git metadata
  → with the associated conflict risk if multiple changes occur between 
checkouts



You can not avoid a buildsys merge-back when doing production builds.


Merge backs by build system can be avoided, however. Why do you think
they can't be avoided?


Because they’re the real state rpm changelogs records. Because that’s 
what people use rpm changelogs for. Something broke, what is the 
affected packaged, what where the released package states since last 
time it worked.



There is the case of mass rebuilds but this is pretty much a one-shot
event


Mass rebuilds are not an exception, they’re becoming the norm. Every SIG 
that deals with modern software released as a huge number of interlinked 
components needs to perform SIG-level mass rebuilds all the time 
(directly in rawhide, in a side tag, whatever). koshei can now autobuild 
all dependent packages when one of their requirements changed. That’s 
where the project is going and has been going for several years.


All the modularity efforts in the past years

Review Swap

[Breno Brand Fernandes]

Hi,

Would you want to swap reviews?
This was generated with go2rpm.
It should be easy to review.

https://bugzilla.redhat.com/show_bug.cgi?id=1806219

Thanks
___
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-packaging] Re: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Tue, 3 Mar 2020 at 09:38, Nicolas Mailhot
 wrote:
>
> Le 2020-03-03 07:03, clime a écrit :
>
> > Actually, that wouldn't work because prefix needs to be static, not
> > dependent on rpm macros
>
> For myself, I would oppose any rpm release process that would not take
> core rpm mecanisms like macros into account.

Being independent of rpm has one huge potential advantage. You can
apply the same approach that you apply for rpm spec files to other
kinds of spec files.
For example the fedora & containers mailing list contains a thread,
when person needs to parametrize FROM clause by branch name to
correctly reference base image:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/65GHZM4PODSO36C66ONZCYXVIN7JIXMK/

The approach I am suggesting would help there and it could help on
other places too.

>
> Recording builds in changelogs without checking they actually happened
> is bad engineering.

It's not about recording builds but instead about recording releases
which I see as something that takes place already in Git.

>
> Simulating rpm behaviour without performing actual spec evaluation in
> rpm, is also bad engineering. Especially when you know your simulation
> is horribly simplistic and approximative.

I am not trying to simulate rpm behavior. I am just trying to
introduce macros that are rendered verbatim into the spec file inside
srpm so those srpms can be rebuilt at any time when needed. rpm does
not have this feature atm. If we should put it into rpm, it would be
already third kind of rpm macro but even if it should go into rpm at
some point, it is better to have the approach heavily tested by
production use first because here it doesn't really add much
complexity. And as I mentioned, independence of rpm means you can use
it for non-rpm projects too.

It's also not simplistic: what you see in {{{ }}} tags is interpreted
by bash, it can be multi-line and you can hence do anything there you
can do with rpm macros. The only problem is, people already have some
automation in rpm macros that doesn't require the git context, instead
just e.g. the tarball content and this functionality would need to be
rewritten by using {{{ }}} if it should play together with the
git-based release generation. This cannot be avoided as much as I
would like to. If we try to avoid it, we will get a weird hybrid that
doesn't work.

It's also not approximative. You can define your own logic for
generating release. There should be some pre-made recommended macros
but in the end you are not limited by them.

>
> “Who cares if results match most of the time” is terrible workload
> optimization. You’ll make packagers waste far more time fixing the cases
> where automation guessed wrong, than you will win when it guesses right.
> Basic 80/20 rule, the 20% hard cases cost more than the 80% easy cases.
> Taking care of the 80% easy cases while making the 20% hard cases harder
> (due to automation mistakes) is not a good deal at all.
>
> Please work on approaches which are reliable by default. Reliability is
> hard even when you aim for it. When you don’t, it’s not attainable at
> all.

I think the approach I am suggesting is very reliable.

As much as I enjoy this conversation, I will need to actually try to
make something happen. Forgive me if I don't go into long disputes
hereafter. If you, however, make a detailed document summarizing the
infra changes needed for your approach I will try to comment on the
individual aspects of it and also respond with the document with the
changes needed for what I am suggesting.

Best regards!
clime

>
> Reagrds,
>
> --
> Nicolas Mailhot
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-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/packag...@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: Anaconda RFE: change in default behaviour when adding users.

[Lukas Ruzicka]

Hello again,

this was my mistake, I overlooked the fact, that I cannot start the
installation when either root or user admin are set up. This behaviour
seems pretty logical to me, so I am taking the previous message back.
Please ignore it and sorry for the inconvenience.

Lukas

On Tue, Mar 3, 2020 at 3:15 PM Lukas Ruzicka  wrote:

> Hello,
> today I have been doing some Anaconda testing and realized that there was
> a change in default
> behaviour of Anaconda when adding users to the system.
>
> Previously:
>
>1. The root account was not locked by default.
>2. The user account was not an admin account.
>
> Currently:
>
>1. The root account is locked by default.
>2. The user account is not an admin account.
>
> I think that this default setting could mean a risk of people forgetting
> to tick the "Make user admin" checkbox and end up with an unusable system.
>
> I would like to propose that by default:
>
>1. The root account is locked.
>2. The user account "Make user admin" is checked.
>
> Nice to have:
>
>1. The user account "Make user admin" could behave according to the
>setting of the root account.
>2. With root unlocked, the user should be NOT admin by default.
>3. With root locked, the user should be admin by default.
>
> What do you think?
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> 
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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

Anaconda RFE: change in default behaviour when adding users.

[Lukas Ruzicka]

Hello,
today I have been doing some Anaconda testing and realized that there was a
change in default
behaviour of Anaconda when adding users to the system.

Previously:

   1. The root account was not locked by default.
   2. The user account was not an admin account.

Currently:

   1. The root account is locked by default.
   2. The user account is not an admin account.

I think that this default setting could mean a risk of people forgetting to
tick the "Make user admin" checkbox and end up with an unusable system.

I would like to propose that by default:

   1. The root account is locked.
   2. The user account "Make user admin" is checked.

Nice to have:

   1. The user account "Make user admin" could behave according to the
   setting of the root account.
   2. With root unlocked, the user should be NOT admin by default.
   3. With root locked, the user should be admin by default.

What do you think?

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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-packaging] Re: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Tue, 3 Mar 2020 at 09:22, Nicolas Mailhot
 wrote:
>
> Le 2020-03-02 14:45, clime a écrit :
> > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> >  wrote:
> >>
> >> Le 2020-03-01 02:31, clime a écrit :
> >> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
> >> >  wrote:
> >> >>
> >> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
> >>
> >> >> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
> >> >> detached file state means that fedpkg local (or checking out git state
> >> >> and building in mock or copr or OBS or via plain rpmbuild -bs) will
> >> >> give you the same result as launching fedpkg build.
> >> >
> >> > Well, I believe it doesn't. You run:
> >> >
> >> > 1) fedpkg local -> produces -1.0-1.fc32 (1 in release because
> >> > you haven't built that package before)
> >> > 2) fedpkg build
> >>
> >> At that point state is undefined till the build succeeds or not. If
> >> the
> >> build succeeds, the buildsystem will write back a new state. Let’s
> >> assume it succeeds.
> >
> > It's undefined if you add more elements to the equation than necessary
> > (i.e. build system), otherwise it would be well-defined in this case.
> >
> >>
> >> > 3) vim .spec and do some change in %description
> >> > 4) fedpkg commit -m "description improvement"
> >> > 5) fedpkg local -> produces -1.0-1.fc32
> >> > 6) fedpkg push -> error because build system pushed meanwhile
> >>
> >> Yes, here the packager notices something else has been going on, and
> >> he
> >> needs to merge or rebase. He’d have the same effect if another
> >> packager
> >> had been doing stuff on the package, or a mass rebuild had been going
> >> on. That’s the distributed decentralized aspect of git, except here
> >> the
> >> packager collided with himself by starting two work threads in
> >> parallel
> >> (one buildsys-side, one local).
> >
> > The problem is that you launched some process and you need to wait
> > until it finishes, normally you don't need to anything like that when
> > working with git.
>
> But fedpkg build is a release to production process. It’s not a dev
> staging process. In release processes, actually doing the release is not
> an inconvenient optional check.

Well, you could have a situation when somebody wants to immediately
continue working after making a release. Probably rare but could
happen and if build time of a package is long (libreOffice/firefox),
this could hit you as an inconvenience. Or do you want to push-back
immediately after srpm build when you don't yet know whether the build
will succeed? That wasn't clear to me before.

>
> You're asked to autobump a “Release” field. You’re asked to automate a
> changelog which is effectively a release changelog, not dev changelog
> (the dev changelog lives in git, people want a good changelog in rpm
> proper to track release not git history).

I am not suggesting to use raw git commit messages for the changelog
but instead content of annotated tags which can be initially
prepopulated by commit messages but can be then edited to any extent
and even the way the edit window for annotated tag is prepopulated
might be configurable (to .e.g. load content from a file in which case
you would probably skip the editing part). And I see the annotated
tags as the actual releases.

From https://git-scm.com/docs/git-tag:
Annotated tags are meant for release while lightweight tags are meant
for private or temporary object labels.

They were designed to represent releases and because we are using git
I don't see why we should avoid using annotated tags for releases.

On src.fp.o, there is also already support for this: e.g.
https://src.fedoraproject.org/rpms/2ping/releases

The release needs building (koji), and distribution (bodhi + mirrors)
but that's stuff that needs to be done with the release. Scratch
builds can be used to make sure that the package builds and in the
worst case, a new release needs to be done that accounts for changed
build environment. But I don't think we need to throw the whole
concept of annotated tags = releases because of it.

Of course, everything here can be made opt-in. As an approach somebody
likes and somebody doesn't.

I think this is where our approaches really differ, you see release as
something that happens somewhere else than in git, but I see the
release as something that happens in git. And afterwards we need to
get that released content to users.

I think we will never be able to reconciliate our views because they
are different from the very base. In the end, what matters is
implementation complexity and ease of use. I can present to you the
things that need to be done for this to work in a detailed way
(although it would take a bit of time to put into a document) but I
also know it is a doable and it is actually fairly simple when not
accounting for time spending on pull requests and getting them
accepted. Your approach seems to be intuitively difficult to
implement, either locking implementation (i am 

HEADS UP: gdal update in rawhide and F32

[Sandro Mani]

Hi

I'll be building gdal-3.0.4 in rawhide and will take care of rebuilding 
all dependencies. If all goes well, I'll do the same for F32.


Affected packages are:

bes
cloudcompare
dans-gdal-scripts
gazebo
GMT
grass
gtatool
liblas
mapnik
mapserver
merkaartor
ncl
nodejs-gdal
opencv
OpenSceneGraph
osgearth
postgis
python-fiona
python-rasterio
qgis
qlandkartegt
qmapshack
R-rgdal
saga
vfrnav
xastir

Thanks
Sandro
___
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

HEADS UP: libgit2 0.99.x is coming to Rawhide

[Igor Gnatenko]

Hello,

The libgit2 finally gets closer to 1.0 release, so this is one of
"pre-releases". Of course, this involves soname bump :)

The API should not be broken compared to 0.28.x, so I'm going to
rebuild everything in side tag and then submit update for all the
affected packages at once.

Stay tuned.
___
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: Plan to retire mapserver

[Sandro Mani]

On 02.03.20 15:06, Julien Enselme wrote:

Hi all,

I intend to retire the mapserver package
(https://src.fedoraproject.org/rpms/mapserver). I don't use it any more and it 
fails to build for F32. If you want to maintain it, please step up!


I can maintain it, my FAS is smani

Thanks
Sandro
___
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-20200303.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 2/8 (x86_64)

Old failures (same test failed in Fedora-IoT-33-20200227.0):

ID: 531109  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/531109
ID: 531110  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/531110

Skipped non-gating openQA tests: 6 of 8
-- 
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

Fedora-Cloud-31-20200303.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: Ideas and proposal for removing changelog and release fields from spec file

[Nicolas Mailhot via devel]

Le 2020-03-03 07:03, clime a écrit :


Actually, that wouldn't work because prefix needs to be static, not
dependent on rpm macros


For myself, I would oppose any rpm release process that would not take 
core rpm mecanisms like macros into account.


Recording builds in changelogs without checking they actually happened 
is bad engineering.


Simulating rpm behaviour without performing actual spec evaluation in 
rpm, is also bad engineering. Especially when you know your simulation 
is horribly simplistic and approximative.


“Who cares if results match most of the time” is terrible workload 
optimization. You’ll make packagers waste far more time fixing the cases 
where automation guessed wrong, than you will win when it guesses right. 
Basic 80/20 rule, the 20% hard cases cost more than the 80% easy cases. 
Taking care of the 80% easy cases while making the 20% hard cases harder 
(due to automation mistakes) is not a good deal at all.


Please work on approaches which are reliable by default. Reliability is 
hard even when you aim for it. When you don’t, it’s not attainable at 
all.


Reagrds,

--
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: Ideas and proposal for removing changelog and release fields from spec file

[Nicolas Mailhot via devel]

Le 2020-03-02 14:45, clime a écrit :

On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
 wrote:


Le 2020-03-01 02:31, clime a écrit :
> On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
>  wrote:
>>
>> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :

>> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
>> detached file state means that fedpkg local (or checking out git state
>> and building in mock or copr or OBS or via plain rpmbuild -bs) will
>> give you the same result as launching fedpkg build.
>
> Well, I believe it doesn't. You run:
>
> 1) fedpkg local -> produces -1.0-1.fc32 (1 in release because
> you haven't built that package before)
> 2) fedpkg build

At that point state is undefined till the build succeeds or not. If 
the

build succeeds, the buildsystem will write back a new state. Let’s
assume it succeeds.


It's undefined if you add more elements to the equation than necessary
(i.e. build system), otherwise it would be well-defined in this case.



> 3) vim .spec and do some change in %description
> 4) fedpkg commit -m "description improvement"
> 5) fedpkg local -> produces -1.0-1.fc32
> 6) fedpkg push -> error because build system pushed meanwhile

Yes, here the packager notices something else has been going on, and 
he
needs to merge or rebase. He’d have the same effect if another 
packager

had been doing stuff on the package, or a mass rebuild had been going
on. That’s the distributed decentralized aspect of git, except here 
the
packager collided with himself by starting two work threads in 
parallel

(one buildsys-side, one local).


The problem is that you launched some process and you need to wait
until it finishes, normally you don't need to anything like that when
working with git.


But fedpkg build is a release to production process. It’s not a dev 
staging process. In release processes, actually doing the release is not 
an inconvenient optional check.


You're asked to autobump a “Release” field. You’re asked to automate a 
changelog which is effectively a release changelog, not dev changelog 
(the dev changelog lives in git, people want a good changelog in rpm 
proper to track release not git history).


The *single* *only* reason good release numbers and good changelog 
matter is because the result will be released to third parties. koshei, 
or scratch builds, or whatever, do not care about those.


A normal git flow would lock the branch at release time to let the 
release manager do his releasing (merge window closed in Linus’s terms). 
That’s option 1 I gave you.


Alternatively, you can use option 2, the “I feel lucky” approach, let 
everything open, and abort the release if merge-back failed. A packager 
that changes his package before the production build is finished will 
probably want it canceled anyway (what is the point of risking breaking 
builds of other packages by pushing an unfinished package to the shared 
koji buildroot)?


Either option does not stop the packager to do anything he wants in his 
local branches. They just require him to merge/rebase when syncing with 
the centralized master Fedora state. That’s a core element of git 
architecture, be it in Fedora or elsewhere.


You can not avoid a buildsys merge-back when doing production builds. 
The merge-back can be explicit and automatic (as I proposed), or you can 
rely on informal meatware for it, but it will exist. Since the whole 
point of the request is to lower dependence on meatware, why on hell 
would you want to keep meatware as part of the whole process?


The only “cost” for the packager is to wait for his build to finish 
before continuing to change the package (or merge/rebase). That’s not an 
horrific cost. No one forced the packager to start a build before he was 
ready. No one forced the packager to perform a production build instead 
of a scratch build if he just wanted to check partial changes. If shit 
happens, and he realizes before the build end something is not ok, 
aborting the build on failed merge back is helping the packager.


Or am I missing something? “normally you don't need to anything like 
that when working with git” is not a clear technical point.


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: Non-Responsive Maintainer: bsjones

[Felix Schwarz]

Hi Erich,

Am 02.03.20 um 21:24 schrieb Erich Eickmeyer:
> As these attempts were over a week ago, I guess my next step is to submit a 
> FESCo issue with the bug links. However, since this is my first post 
> specifically looking for bsjones unlike my previous post, perhaps I should 
> give it another week? Or, does my previous post looking to adopt fedora-jam-
> backgrounds and fedora-jam-kde-theme count for that?

I'd just go ahead and file a FESCo issue. Filing such an issue should not be
treated as a "hostile act" or so but just as a genuine attempt to contribute.

Unfortunately sometimes maintainers "disappear" but the FESCo process is a
good one to ensure new maintainers can help out.

In general I feel as long as you are working in good faith no one will blame
you even if there was a premature "non-responsive maintainer" bug.

Thanks again for your work in Fedora.
Felix
___
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