Re: xz backdoor

[Alex Thomas]

Just to be clear, as I was getting ready to put 40 Beta on a test
machine, this has been fixed. I do the install and run updates and the
compromised version of xz is never installed?
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alex Perez]

Jonathan,

Your perspective on costs seems extremely developed-country-centric, and
I'd like to suggest you check your (financial) privilege. I don't know
where you're from; I'm from the US, but I am well aware of the reality
of many open source contributors from countries where the exchange rate
against the US dollar is awful.

You may not see this sort of cost as a barrier to contribution, but I
can assure you that other casual contributors may, and likely would. You
have to realize that the cost of the token isn't necessarily the only
factor that contributes to the overall cost of obtaining such a device.
International shipping costs can easily triple this dollar amount, to
say nothing of other associated costs such as import duties, etc. There
are plenty of countries where such tokens are not domestically
available, and must be shipped from abroad.

This just isn't as simple or straightforward as you seem to want it to
be. Erecting financial barriers to contribution is dangerous, and has
unintended consequences.

Respectfully,
Alex Perez

Jonathan Wright via devel wrote on 9/6/22 2:14 PM:
>
>
> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel
> mailto:devel@lists.fedoraproject.org>>
> wrote:
>
> On 06/09/2022 19:49, Michael Catanzaro wrote:
> > Of course, hardware authenticators would be even more secure,
> and it
> > sure seems pretty reasonable to expect that people with commit
> access to
> > Fedora packages are able to purchase a $25 or 30€ security key
> [1][2].
>
> Having to pay even $25 for a hobby project is not acceptable, IMO. If
> you want to enforce such a policy, find sponsors and buy devices
> for all
> Fedora contributors.
>
> Fedora must be looked at as more than just a "hobby project" even
> though it is a hobby for some.
>
> It's an OS that many rely on and $25 is a somewhat trivial cost for
> improved security.
>
> With your suggestion of sponsors to cover such devices - how does that
> work for new packagers?  It seems pretty impossible to do such a thing
> and tons of money would simply be wasted on packagers that did very
> little to nothing after becoming a packager.
>
>
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org
> <mailto:vit...@easycoding.org>)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto: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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
>
>
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Alex]

On Thu, 10 Mar 2022 14:10:17 +0100
Vitaly Zaitsev via devel  wrote:

> On 10/03/2022 13:47, Alex wrote:
> > Here a example test. I know that this could be also done with https but
> > it's a understandable example, IMHO.
> 
> Better example:
> openssl s_client -connect example.org:443
> 

Agree when openssl is installed.
Is openssl s_client installed by default in F37?

I understand your position, it was just a question if this small but useful
protocol could stay in curl-minimal package.

As I don't maintain the code of course I'm fine with the decision of the
community and the code maintain Person(s).

Regards
Alex
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Alex]

On Thu, 10 Mar 2022 11:41:15 +
Paul Howarth  wrote:

> On Thu, 10 Mar 2022 12:26:54 +0100
> Vitaly Zaitsev via devel  wrote:
> 
> > On 10/03/2022 11:55, Alex wrote:
> > > May I suggest to leave at least the telnet protocol in curl-minimal
> > > for debugging purposes.  
> > 
> > Telnet is an extremely vulnerable protocol. It must be disable.
> > 
> > If you need it, you can always install libcurl-full.
> 
> I wonder, do you have the "telnet" program installed on your machine(s)?
> 
> I'd be surprised if anyone using curl's telnet *client* support wasn't
> aware that it was sending plain text over the network, possibly
> including any credentials that were being used. A telnet client is,
> however, a very useful debugging tool for various other network
> protocols, not just the telnet protocol itself. That is, I believe,
> what Alex was advocating for, since the curl tool's presence is
> well-nigh universal and hence always available for debugging some
> network issues.

Thanks Paul, that's exactly my point.
I agree that Telnet should not be offered as a service to the outside world,
but for debugging is it very helpfully.

Let me try to explain what the "telnet://" means for me.

```
With the telnet protocol in curl is a TCP Socket connection created and
therefore can be tested if a TCP connection to a remote destination can be
successful created.
```

Here a example test. I know that this could be also done with https but it's a
understandable example, IMHO.

```
echo -e 'GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n'|curl --ipv4 \
-vso /dev/null --ssl --tlsv1.3 telnet://www.google.com:443
*   Trying 172.217.19.132:443...
* TCP_NODELAY set
* Connected to www.google.com (172.217.19.132) port 443 (#0)
* Closing connection 0
```

> Paul.
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Alex]

Hi.

I have seen in https://lwn.net/Articles/887313/ that you plan to remove the
"telnet" protocol from curl-minimal.

I use `curl -v telnet://` almost every day for debugging purpose just
because curl is in the most systems by default installed.
I know that there are some other tools like socat, normal telnet, nmap and so
on but this tools need to be installed which is not always possible when
fedora is used as docker image.

there was also a short presentation about how to use curl telnet for debugging
on a curl up meeting.
https://curl.se/video/curlup-2017/2017-03-18_02_Aleksandar_Lazic_curl_for_network_debugging.mp4

May I suggest to leave at least the telnet protocol in curl-minimal for
debugging purposes.

Best regards
Alex
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Intent to orphan JDK Mission Control

[Alex Macdonald]

Hi everyone,

I am writing to let everyone know that JDK Mission Control (JMC) and
it’s dependencies will be orphaned in Fedora by the end of tomorrow
(June 18th). This encompasses packages owned by both myself (almac)
and jkang, and includes the jmc and jmc-core packages along with the
dependencies we currently maintain.

This includes packages owned by:

almac, 4:
- jakarta-activation
- jakarta-mail
- mvel
- lz4-java

jkang, 8:
- felix-scr
- directory-maven-plugin
- HdrHistogram
- jaf
- jmc
- modules/jmc
- jmc-core
- owasp-java-encoder

I’ll be co-ordinating the orphaning of these packages by the end of
tomorrow. In their place, I have created a couple of copr repositories
containing rpm wrappers for AdoptOpenJDK’s JMC builds, which can be
used to install and use their JMC builds in Fedora. I currently have a
repo for the JMC 8.0.0 release
(https://copr.fedorainfracloud.org/coprs/almac/jmc8/) and a repo for
snapshot builds
(https://copr.fedorainfracloud.org/coprs/almac/jmc-snapshot/).

Regards,

Alex
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self introduction

[Alex Fails]

Hello everyone,My name is Alexey Gorgurov, and I would like to participate in the community life.I'm experienced mainly in C++, Qt, .net, python, etc., interested in Linux and have some experience in open source contributing.I like to help people with programming issues and like to spend some time in the community and hope to be helpful for Fedora Project. Thanks. Kind regards,Alexey  ___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)

[Alex Perez]

Daniel Pocock wrote on 2/22/21 10:41 AM:
> I feel that you underestimate the impact of the GPU driver issue
>
> If the GPU driver doesn't work, people can't even log in and get started
>
> If the GPU vendors don't test their code on ppc64le (and aarch64) then
> those platforms will always lag behind x86.  Users will experience
> issues that have been fixed in the development phase for x86.
>
> Personally, I'm not opposed to the 64k page size in principle: my
> concerns are about the practical issues.
>
> If both 4k and 64k can be supported, if users can choose between
> installers for either page size, then the severity of the issue is reduced

How practical/impractical would it be to simply compile the ppc64le
kernel for both page sizes, and then add a boot entry to GRUB for 4k
page sizes, which is not the default.

Another option could be an official ppc64le-4K Fedora Spin.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Non-responsive maintainer callkalpa - FESCO issue #2580 - request for exception

[Alex Perez]

Hi there, I've filed https://pagure.io/fesco/issue/2580 due to 
non-responsive maintainer who owns a number of sugar activity packages 
within Fedora, which are important to us at Sugar Labs.


Eleven days ago, I e-mailed Kalpa Welivitigoda, whose fas username is 
'callkalpa' and have had no response from him. I've just tried again. 
E-mails to him are not bouncing.


fedora-active-user shows he's not logged in in to FAS in over 10 months. 
Given this, and the fact that a number of other packages he's owned have 
been retired due to FTBFS, it's clear this person no longer has the time 
to dedicate to making sure these packages are usable.


Kalpa is listed as a Fedora Ambassador for Sri Lanka, according to 
https://fedoraproject.org/wiki/User:Callkalpa.


Thank you for your consideration.

Alex Perez
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)

[Alex Perez]

Kevin,

On 2/13/2021 9:51:48 AM, Stephen John Smoogen  wrote:


On Sat, 13 Feb 2021 at 05:15, Daniel Pocock mailto:dan...@pocock.pro]> wrote:



On 13/02/2021 09:11, Tomasz Torcz wrote:
> Dnia Fri, Feb 12, 2021 at 10:16:26PM +0100, Daniel Pocock napisał(a):
>>
>>
>> On 12/02/2021 21:19, Justin Forbes wrote:
>>> On Fri, Feb 12, 2021 at 10:21 AM Ben Cotton >> [mailto:bcot...@redhat.com]> wrote:
>>>>
>>>> https://fedoraproject.org/wiki/Changes/Power4kPageSize 
>>>> [https://fedoraproject.org/wiki/Changes/Power4kPageSize]
>>>>
>>>> == Summary ==
>>>>
>>>> On ppc64le, the kernel is currently compiled for 64k page size.
>>>>
>>>> This change proposes using the more common 4k page size.
>>>>
>>>> Some things, like the AMD Radeon GPU drivers, firmware or related
>>>> code, appear to be completely non-functional on the 64k page size.
>>>> Insufficient upstream developers are testing such issues on this
>>>> architecture.
>>>
>>> Just as there are many things that expect the 64K page size.  I am not
>>> doing this.
>>>
>>> Justin
>>
>> Can you please identify some of the things that expect 64k?
>>
>> If the GPU drivers don't work that makes it a complete non-starter for
>> many workstation users, or they have to compile their own kernels or
>> obtain custom kernels from another user.
>
>   Or just fix the GPU drivers. They're open source, after all.

The GPUs also have firmware blobs



OK I think we need to back up a whole bunch here and talk directly about what 
is wanted and going on. I am going to try an outline what I have picked up from 
months of this back and forth:

1. There is some sort of PowerPC workstation which is going 'to market' 
somewhere soon.
Alex Perez:
We, it's actually been on the market for a few years. There are several 
variants. I've had my Talos II Lite board since January of 2019.

2. It will have high powered video cards of a PC style so will be using the 
same 'firmware' that would be in x86_64.
Alex Perez: 
Not will, does. Right now.



3. Those drivers expect x86_64 4k buffer sizes.
Alex Perez: 
Some do, some don't.



4. Daniel would like to have Fedora Linux as an option or the operating system 
on it.
5. They have been trying to work out through various tickets how to make this 
happen.

Please correct the items above if needed. The questions that I don't see having 
been asked is:
1. Is Fedora interested in being offered on this hardware?
Alex Perez: 
Err, people are already running Fedora on this exact hardware. You seem to 
think this is not something that's happening. You're mistaken.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Request for exception to non-responsive maintainer policy for Sugar packages

[Alex Perez]

Hi folks,
 
I've opened https://pagure.io/fesco/issue/2574 
[https://pagure.io/fesco/issue/2574] to facilitate assumption ownership of the 
Sugar packages in Fedora, most of which are de-facto abandoned by the previous 
maintainer, erikos, who has not authenticated with his FAS account since March 
of 2017, nearly three years ago. I can't find a working e-mail address for him, 
and @chimosky and I are trying to get the remaining core Sugar packages updated 
to the current version, before the F34 freeze happens. Therefore, time is of 
the essence. The only two e-mail addresses I could find for Simon were both 
aliases, si...@laptop.org [mailto:si...@laptop.org] and si...@sugarlabs.org 
[mailto:si...@sugarlabs.org]. Both are no longer functional, nor have they been 
for a couple of years. 
 
As an aside, I'd like to propose that FESCO consider revising the requirements 
to simplify/expedite assumption of packages which have clearly been abandoned 
by their previous maintainers. Perhaps "has not authenticated to FAS in 2+ 
years" could be considered a form of abandonment? This subject seems worthy of 
discussion at the next FESCO meeting. 
 $ ./fedora_active_user.py --user erikos
FAS username: aperezbios FAS password for aperezbios: Last login in FAS: erikos 
2017-03-10 Last action on koji: Sun, 06 Dec 2020 tag_package_owners entry 
revoked by oscar Last package update on bodhi: No activity found on bodhi___
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: Retiring ntp

[Alex Thomas]

Question : I know that FreeIPA at one point did not work well with
chrony and required the installation of ntp. This might cause an
issue.

On Mon, Nov 2, 2020 at 3:54 PM Gary Buhrmaster
 wrote:
>
> On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia  wrote:
>
> > So, use "chrony" instead?
>
> For some use cases, there is also the option of
> systemd-timesyncd as a ntp client.
>
> > Is the functionality sufficient
>
> As always, given the different use cases, the answer
> is maybe.
>
> Here is a quick comparison: https://chrony.tuxfamily.org/comparison.html
>
> > and can the ntp.conf files be ported gracefully to a
> > compatible chrony.conf setting?
>
> Again, it would depend on how you are using ntpd.
> For the cases where the system is just a client of
> the protocol trying keep the right time, it should be
> easy to migrate to either chrony (or systemd-timesyncd).
> If you are using hardware to discipline your server
> using one/more of the hardware specific drivers
> things get more complicated.
> ___
> 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 33 Beta Secure boot issue

[Alex Thomas]

Thought I would try the beta out on my laptop again (had tried it on
test week, but had to revert due to platform.io not working) Getting
error of : " Secure Boot  Image failed to verify with * ACCESS DENIED*
"

It worked on the btrfs test week, so I am unsure what went wrong.

Laptop is Lenovo T440p.

I filed a bug, but the best component I could find was Grub2.

https://bugzilla.redhat.com/show_bug.cgi?id=1883609
___
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: RFC7919 Diffie-Hellman parameters in Fedora

[Alex Scheel]

- Original Message -
> From: "Simo Sorce" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, August 24, 2020 2:06:19 PM
> Subject: Re: RFC7919 Diffie-Hellman parameters in Fedora
> 
> On Mon, 2020-08-24 at 19:29 +0200, Christopher Engelhard wrote:
> > On 24.08.20 18:43, Simo Sorce wrote:
> > > On Fri, 2020-08-21 at 16:13 +0200, Christopher Engelhard wrote:
> > > We already are making it easier in some ways, but feel free to open a
> > > bug if there are specific components you are worried about.
> > 
> > What ways are that?
> 
> Some of the crypto libraries use only named DH moduli in FIPS mode
> (more relevant for RHEL) for example, regardless of configuration.
> So we have already some experience with this problem, but we haven't
> pursued this to force everything to just use the RFC parameters.
> 
> > I'm not worried about any specific component, I'm just looking for
> > opinions wrt Fedora defaulting to these parameters generally, where
> > possible.
> > 
> > (I was thinking along the lines of a package containing those parameters
> > & letting other packages link to those files instead of of asking the
> > user to get/create the files themselves - so dovecot, instead of having
> > /etc/dovecot/dh.pem in it's default conf files, could Require: that
> > package and have /etc/pki/dhparam/something.pem or whatever.)
> 
> This has been proposed (somewhere, I forgot where) before, and it is a
> definite possibility.
> Unclear what package would distribute them, potentially the crypto-
> policies package.

I at least mentioned this in a conversation with you IRC or perhaps email.

As a maintainer, this would've made the late FIPS changes much more
palatable. 

I've opened the following BZ for this:

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


- Alex

> 
> Simo.
> 
> > Christopher
> > 
> > > Simo.
> > > 
> > > > For a long time, the general recommendation for Finite-Field
> > > > Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
> > > > non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
> > > > to specify) used in TLS was to generate your own. However, RFC7919
> > > > specifies fixed, auditable parameters with lengths of 2048-8102 bits
> > > > [1], Mozilla has switched their recommendation from 'generate your own'
> > > > to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
> > > > 
> > > > Main advantage in using them is a) since they're fixed & well-defined,
> > > > they can be and are audited, b) clients don't have to check whether
> > > > parameters they're given by a server are legit or meddled with
> > > > (something that usually any client program would have to but few
> > > > actually do).
> > > > 
> > > > So, questions:
> > > > 1) do we already ship these groups somewhere, e.g. via a package that I
> > > > don't know about? If not, should we maybe add one?
> > > > 2) Many programs either ship their own dhparam files (on my systems at
> > > > least proftpd, certbot & openssh, via the moduli file) or expect the
> > > > user to point them to one (like webservers, dovecot, postfix etc.) +
> > > > some for sure hardcode some defaults if the user does not specify
> > > > parameters. Would it make sense to change their defaults - if possible
> > > > -
> > > > to use (one of the) RFC7919 groups? One could even integrate this with
> > > > crypto-policies, if at some point one wants to e.g. change the desired
> > > > group size.
> > > > 
> > > > Best,
> > > > Christopher
> > > > 
> > > > [1] https://tools.ietf.org/html/rfc7919
> > > > [2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
> > > > ___
> > > > 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

Re: Respinning rawhide images every filesystem update?

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, August 6, 2020 10:55:51 AM
> Subject: Re: Respinning rawhide images every filesystem update?
> 
> On Thu, 6 Aug 2020 at 10:05, Alex Scheel  wrote:
> >
> > - Original Message -
> > > From: "Stephen John Smoogen" 
> > > To: "Development discussions related to Fedora"
> > > , asch...@redhat.com
> > > Sent: Thursday, August 6, 2020 9:55:17 AM
> > > Subject: Re: Respinning rawhide images every filesystem update?
> > >
> > > On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> > > >
> > > > I'm bumping this thread. This is still broken.
> > > >
> > >
> > > Please open a ticket at
> > > https://pagure.io/fedora-infrastructure/new_issue and open new issue
> > > with an explanation of what is broken and where you are pulling from.
> > > If it is a fedora registry then infrastructure can work on a fix. If
> > > it is from docker.io or quay or elsewhere we can try to find the
> > > people who fix it and let them know.
> >
> > Opened:
> >
> > https://pagure.io/fedora-infrastructure/issue/9208
> >
> > This was also posted to devel to hopefully get the attention of the
> > filesystem maintainer.
> >
> >
> > They seem to have ignored 1548403 since 2018. :-)
> >
> >
> 
> OK so this ticket clarifies the problem because I thought this was a
> problem with the filesystem in the container image with how it is spun
> or delivered. It is instead with the package filesystem. Here is the
> ticket contents (since most people don't follow links in emails).

There's three ways to solve this:

 1) Make the filesystem upgrade nicely in a container, or
 2) Have the container runtime/user namespace system/... support the
type of change that upgrading the filesystem package makes, or
 3) Just respin the container image quickly whenever this happens; this
hides the problem from users without solving the problem.

1 isn't happening because the maintainer isn't involved.
2 isn't happening because the container runtime maintainers punted on it.
3 is the easiest left to accomplish.


If I had a choice, I'd be really happy with 3. I don't know what
all is involved to respin container images with a new package. I'm 
sure it takes time, but I'd imagine it'd be mostly automated. The
problem gets fixed eventually anyways.

- Alex

(Arguably there is 4, quit rebuilding the filesystem package needlessly,
 but we seem to like mass-rebuilds of all packages, and it might set a
 weird precedence if we special case things). 

> filesystem package breaks Fedora containers because dnf cannot
> successfully update the package. See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> 
> Every time filesystem updates, it causes this problem. The solution is
> to rebuild Fedora containers with the new filesystem package upgrade,
> so dnf upgrade will already have the updated filesystem package.
> 
> Alternatively, the filesystem maintainer could make their package
> container friendly.
> 
> This is from the main Fedora registry:
> 
> [ascheel@ascheel-p50 ~]$ podman run -ti
> registry.fedoraproject.org/fedora:rawhide /bin/bash
> [root@5808bc88f6ab /]# dnf update --refresh -y
> Fedora 33 openh264 (From Cisco) - x86_64  6.9 kB/s | 5.1 kB 00:00
> Fedora - Modular Rawhide - Developmental pack 2.6 MB/s | 3.1 MB 00:01
> Fedora - Rawhide - Developmental packages for  17 MB/s |  73 MB 00:04
> Dependencies resolved.
> ==
>  Package Arch   Version Repo Size
> ==
> Upgrading:
> 
> 
> 
>  filesystem  x86_64 3.14-3.fc33 rawhide 1.1 M
> 
> 
> 
>   Upgrading: filesystem-3.14-3.fc33.x86_64  3/341
> Error unpacking rpm package filesystem-3.14-3.fc33.x86_64
> 
> 
> 
> Failed:
>   filesystem-3.14-2.fc32.x86_64 filesystem-3.14-3.fc33.x86_64
> 
> Error: Transaction failed
> 
> 
> --
> Stephen J Smoogen.
> ___
> 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 Guidel

Re: Respinning rawhide images every filesystem update?

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> , asch...@redhat.com
> Sent: Thursday, August 6, 2020 9:55:17 AM
> Subject: Re: Respinning rawhide images every filesystem update?
> 
> On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> >
> > I'm bumping this thread. This is still broken.
> >
> 
> Please open a ticket at
> https://pagure.io/fedora-infrastructure/new_issue and open new issue
> with an explanation of what is broken and where you are pulling from.
> If it is a fedora registry then infrastructure can work on a fix. If
> it is from docker.io or quay or elsewhere we can try to find the
> people who fix it and let them know.

Opened:

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

This was also posted to devel to hopefully get the attention of the
filesystem maintainer.


They seem to have ignored 1548403 since 2018. :-)


- Alex

> 
> Without that information, it is very likely it will stay broken unless
> fixed by accident because no one knows what is meant by 'still broken'
> 
> > - Original Message -
> > > From: "Alex Scheel" 
> > > To: "Development discussions related to Fedora"
> > > 
> > > Sent: Monday, August 3, 2020 2:36:40 PM
> > > Subject: Respinning rawhide images every filesystem update?
> > >
> > > Hey list,
> > >
> > >
> > > How do Fedora rawhide images get respun? Every time filesystem updates,
> > > it causes `dnf update` to fail in a podman container because filesystem
> > > can't be updated in a container. We either need to make sure filesystem
> > > updates  cause rawhide containers to be rebuilt, or figure out how to
> > > ship a container-friendly filesystem package.
> > >
> > >
> > > See:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> > >
> > >
> > > And I'm sure many other discussions.
> > >
> > > - Alex
> > ___
> > 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
> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> 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: Respinning rawhide images every filesystem update?

[Alex Scheel]

I'm bumping this thread. This is still broken.

- Original Message -
> From: "Alex Scheel" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, August 3, 2020 2:36:40 PM
> Subject: Respinning rawhide images every filesystem update?
> 
> Hey list,
> 
> 
> How do Fedora rawhide images get respun? Every time filesystem updates,
> it causes `dnf update` to fail in a podman container because filesystem
> can't be updated in a container. We either need to make sure filesystem
> updates  cause rawhide containers to be rebuilt, or figure out how to
> ship a container-friendly filesystem package.
> 
> 
> See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> 
> 
> And I'm sure many other discussions.
> 
> - Alex
___
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

Respinning rawhide images every filesystem update?

[Alex Scheel]

Hey list,


How do Fedora rawhide images get respun? Every time filesystem updates,
it causes `dnf update` to fail in a podman container because filesystem
can't be updated in a container. We either need to make sure filesystem
updates  cause rawhide containers to be rebuilt, or figure out how to
ship a container-friendly filesystem package.


See:

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


And I'm sure many other discussions.

- Alex
___
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: [pam_radius] aarch64 GCC failures during ./configure's working compiler step?

[Alex Scheel]

- Original Message -
> From: "Dan Čermák" 
> To: "Alex Scheel" , "Development discussions related to 
> Fedora" 
> Sent: Monday, July 27, 2020 8:25:27 AM
> Subject: Re: [pam_radius] aarch64 GCC failures during ./configure's working 
> compiler step?
> 
> Hi Alex,
> 
> 
> This is most likely due to annobin being broken in rawhide on aarch64
> (see Neal's email to devel from Saturday).

Ah, thanks Dan and Peter! I must've missed it for another thread. I'll
be patient. :D

- A

> 
> 
> Cheers,
> 
> 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
> 
___
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

[pam_radius] aarch64 GCC failures during ./configure's working compiler step?

[Alex Scheel]

Not to pile on to what seems like a common topic... :-)

Koschei notified me that one of my co-owned packages, pam_radius failed
to build on aarch64 with the recent gcc update (10.1.1 -> 10.2.1). ppc and
x86 built just fine.

Looking at the build log, I'm almost inclined to kick off a new build
on aarch64 to see if it is still there, or just issued at the wrong
time:

https://kojipkgs.fedoraproject.org/work/tasks/8159/47858159/build.log

> + ./configure --build=aarch64-redhat-linux-gnu 
> --host=aarch64-redhat-linux-gnu --program-prefix= 
> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr 
> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
> --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec 
> --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man 
> --infodir=/usr/share/info --enable-werror
> configure: WARNING: unrecognized options: --disable-dependency-tracking
> checking build system type... aarch64-redhat-linux-gnu
> checking host system type... aarch64-redhat-linux-gnu
> checking target system type... aarch64-redhat-linux-gnu
> checking for aarch64-redhat-linux-gnu-gcc... gcc
> checking whether the C compiler works... no
> configure: error: in `/builddir/build/BUILD/pam_radius-1.4.0':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> error: Bad exit status from /var/tmp/rpm-tmp.McMZL0 (%build)
> Bad exit status from /var/tmp/rpm-tmp.McMZL0 (%build)
> RPM build errors:
> Child return code was: 1

The spec file was well before my time but seems fairly straight
forward:

https://src.fedoraproject.org/rpms/pam_radius/blob/master/f/pam_radius.spec#_43


The configure script is admittedly from 7 years ago, perhaps I should
just nuke it and rebuild it from configure.ac with a newer version of
autotools?

https://github.com/FreeRADIUS/pam_radius/blob/release_1_4_0/configure


Any thoughts? Should I try and grab the config.log from a scratch build? 


Thanks!

- Alex
___
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: The future of legacy BIOS support in Fedora.

[Alex Thomas]

Ok thought I had read somewhere that is was in the pipeline but had
not merged. Must be old data.

On Thu, Jul 2, 2020 at 5:34 PM Neal Gompa  wrote:
>
> On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas  wrote:
> >
> > Question about systemd-boot vs GRUB2.
> > One of the current stumbling blocks is the lack of LUKS2 support in
> > GRUB2. Does sytemd-boot support LUKS2?
>
> GRUB2 supports LUKS2 in v2.06. sd-boot does not support it.
>
>
>
> --
> 真実はいつも一つ！/ 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
___
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: The future of legacy BIOS support in Fedora.

[Alex Thomas]

Question about systemd-boot vs GRUB2.
One of the current stumbling blocks is the lack of LUKS2 support in
GRUB2. Does sytemd-boot support LUKS2?
___
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: rawhide - glibc/pthreads/... - broken pending mass rebuild?

[Alex Scheel]

Just to revisit this, my issue turned out to be a bug in a p11-kit
component, opencryptoki, that failed to lock, causing its
deinitialization routine to trample some stuff. That's been fixed
now. Sorry for blaming glibc, Florian! :)


- Alex

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 2, 2020 4:35:27 AM
> Subject: Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?
> 
> I just met something which might be of similar nature. Recent FF
> 78.0-1.fc33.x86_64 fails to start with older glibc:
> 
> 
> ~~~
> 
> $ firefox
> XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
> /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
> version GLIBC_2.32
> Couldn't load XPCOM.
> 
> ~~~
> 
> 
> Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to
> glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless
> issues like this are unexpected. There should be something, what would
> force glibc update if FF requires more recent one.
> 
> 
> Vít
> 
> 
> Dne 01. 07. 20 v 6:57 Florian Weimer napsal(a):
> > * Alex Scheel:
> >
> >> Is Fedora Rawhide unstable at the moment, pending a mass rebuild?
> >>
> >> I've seen a lot of random problems related to pthreads at the
> >> moment, such as:
> >>
> >> 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child
> >> aborted***Exception:   0.99 sec
> >> FINE: CryptoManager: loading JSS library
> >> FINE: CryptoManager: loaded JSS library from java.library.path
> >> java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion
> >> `mutex->__data.__owner == 0' failed.
> >>
> >>
> >> Another, different stack trace here (pthreads fails to lock,
> >> triggering a bug in opencryptoki):
> >>
> >> https://pagure.io/dogtagpki/issue/3181#comment-661911
> > I don't see why this would be fixed by a mass rebuild.
> >
> > This is probably some sort of memory corruption: something has
> > overwritten the mutex data structure, and glibc happens to detect that.
> >
> > Thanks,
> > Florian
> > ___
> > 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
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-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, July 1, 2020 9:21:31 AM
> Subject: Re: [fedora-java] Re: java stack is dead, long live the javastack 
> (was "500 packages FTBFS in rawhide with
> java-11-openjdk as system JDK")
> 
> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov 
> wrote:
> >
> > Fabio, does it mean that the Java SIG agrees with progressing with the
> > Change to Java 11 as a default?
> 
> Speaking for myself, yes.
> 
> I can't speak for all other SIG members (we haven't formally voted on
> this or something like that), but from conversations we've had I
> gather that all active package maintainers are looking forward to
> finally getting Java 11 by default.

Speaking on behalf of the Dogtag team, we too are fine with Java 11 change.

(Technically we're the next most active members of the Stewardship SIG,
 and I guess we're part of Java Maint SIG but we've not yet contributed
 in that capacity).

We're mostly there, but still need upstream CI in place to prevent
regressions and ensure we fix problems before they get started.

Plus, Debian has already made this change so we're going to need this
eventually. RHEL will get there too.


My personal preference is to get the Stewardship SIG's top-level packages
building (iirc, Eclipse, Dogtag, and Libreoffice) on Java 11 and then we'll
let the rest drop. IIRC most of the 200 packages not building in our COPR
aren't pulled in by Dogtag so we're mostly fine once we fix our top-level
Dogtag package.



- Alex



> 
> 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

rawhide - glibc/pthreads/... - broken pending mass rebuild?

[Alex Scheel]

Is Fedora Rawhide unstable at the moment, pending a mass rebuild?

I've seen a lot of random problems related to pthreads at the
moment, such as:

16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child 
aborted***Exception:   0.99 sec
FINE: CryptoManager: loading JSS library
FINE: CryptoManager: loaded JSS library from java.library.path
java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion 
`mutex->__data.__owner == 0' failed.


Another, different stack trace here (pthreads fails to lock,
triggering a bug in opencryptoki):

https://pagure.io/dogtagpki/issue/3181#comment-661911


And others. They don't reproduce consistently though.

Should I go ahead and file a bug or just wait and be patient? :)



This is blocking some rebuilds on rawhide at the moment for us.

- Alex
___
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: Make btrfs the default file system for desktop variants

[Alex Scheel]

- Original Message -
> From: "James Cassell" 
> To: "Fedora Development List" 
> Sent: Tuesday, June 30, 2020 6:08:30 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default 
> file system for desktop variants
> 
> On Tue, Jun 30, 2020, at 10:18 AM, Steven Whitehouse wrote:
> > I know it has been rather confined to Red Hat internally, however that
> > was not the intention, and in fact I would like to strongly encourage
> > community involvement. There is an upstream mailing list, which
> > currently has almost no traffic: springfi...@sourceware.org so please
> > do join and ask questions, if anybody is interested in finding out more.
> > 
> 
> Indeed, this is the first I've heard of "Project Springfield" -- it looks
> like the list only had a couple of messages at its start in 2018 and nothing
> since.
> 
> https://springfield-project.github.io/
> 
> The "subscribe" link is broken... it should probably point to
> https://sourceware.org/mailman/listinfo/springfield
> 
> I'd send a pull request, but I couldn't find the github repo associated with
> the page.

https://github.com/springfield-project/springfield-project.github.io/blob/master/index.md#so-youd-like-to-contribute


https://.github.io/ -- you'll almost always find it at
https://github.com//github.io, unless it is a
repo-specific GH pages.

Then it'd be:

https://.github.io// -- which you'll find somewhere
in the https://github.com// repo (either docs/
folder in the default branch or gh-pages branch). 


https://help.github.com/en/github/working-with-github-pages/about-github-pages

- Alex

> 
> 
> 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
> 
___
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: Make btrfs the default file system for desktop variants

[Alex Thomas]

On Fri, Jun 26, 2020 at 5:31 PM Tomasz Kłoczko  wrote:
>
> On Fri, 26 Jun 2020 at 23:21, Alex Thomas  wrote:
>>
>> Once question, are we looking at using a layout like openSUSE is
>> doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
>> are we looking at something like
>>
>> /boot/efi > EFI (FAT32)
>> / > btrfs
>
>
> BTW that layout.
> Anaconda still does not allow installing something like that because it does 
> not allow /boot on btrfs (technically there is no any reasons to demand that 
> and /boot can be just subvolume on the root btrfs pool).
>
> kloczek
> --
> Tomasz Kłoczko |  LinkedIn: http://lnkd.in/FXPWxH
> ___
> 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

Something to think about when trying to set up for snapshot/rollbacks, then.
___
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: Make btrfs the default file system for desktop variants

[Alex Thomas]

Ok, I thought I saw a proposal by you to change the default btrfs
layout to something like openSUSE's using subvolumes, but now, of
course, I cannot find it.

On Fri, Jun 26, 2020 at 5:25 PM Neal Gompa  wrote:
>
> On Fri, Jun 26, 2020 at 6:11 PM Alex Thomas  wrote:
> >
> > Once question, are we looking at using a layout like openSUSE is
> > doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
> > are we looking at something like
> >
> > /boot/efi > EFI (FAT32)
> > / > btrfs
> >
>
> We are planning on using Fedora's current default layout, which has a
> subvolume for / and a subvolume for /home.
>

Ok, I thought I saw a proposal by you to change the default btrfs
layout to something like openSUSE's using subvolumes, but now, of
course, I cannot find it.
>
>
> --
> 真実はいつも一つ！/ 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
___
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: Make btrfs the default file system for desktop variants

[Alex Thomas]

Once question, are we looking at using a layout like openSUSE is
doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
are we looking at something like

/boot/efi > EFI (FAT32)
/ > btrfs



On Fri, Jun 26, 2020 at 4:45 PM Matthew Miller  wrote:
>
> On Fri, Jun 26, 2020 at 03:22:07PM -0400, Josef Bacik wrote:
> > I described this case to the working group last week, because it hit
> > us in production this winter.  Somebody screwed up and suddenly
> > pushed 2 extra copies of the whole website to everybody's VM.  The
> > website is mostly metadata, because of the inline extents, so it
> > exhausted everybody's metadata space.  Tens of thousands of machines
> > affected.  Of those machines I had to hand boot and run balance on
> > ~20 of them to get them back.  The rest could run balance from the
> > automation and recover cleanly.
>
> Is there a way to mitigate this by reserving space or setting quotas? Users
> running out of space on their laptops because:
>
> * they downloaded a lot of media
> * they created huge vms
> * some sort of horrible log thing gone awry
>
> are pretty common in both a) my anecdotal experience helping people
> professionally and personally and b) um, me.
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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: RHEL 9 and modularity

[Alex Scheel]

- Original Message -
> From: "Daniel P. Berrangé" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, June 19, 2020 5:58:28 AM
> Subject: Re: RHEL 9 and modularity
> 
> On Fri, Jun 19, 2020 at 11:28:58AM +0200, Vít Ondruch wrote:
> > 
> > Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a):
> > > On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr 
> > > wrote:
> > >> The issues I've seen so far affect both Fedora and RHEL, but have gotten
> > >> a bit
> > >> better in Fedora. For example, a major concern that has been much worse
> > >> in
> > >> Fedora than RHEL, for obvious reasons:
> > >>
> > >> One month you can do a fresh install, install a package that, as it
> > >> turns out,
> > >> is a module for some reason.
> > >>
> > >> Then you install a fresh system the next month, install the same
> > >> package.
> > >> Perform a dnf update on the previous system, and you'll find that you
> > >> have a
> > >> different version of the package installed, because you're tracking a
> > >> different version of a default stream.
> > >>
> > > Can you give an example of where you've seen this? Because our
> > > policies in Fedora forbid changing a default stream in a released
> > > Fedora. There were a couple exceptions around Java/Maven and libgit2
> > > in the past due to their default streams being broken
> > 
> > 
> > Sorry, but I don't remember this as "their default streams being
> > broken". AFAIR, there were multiple applications trying to use different
> > version of libgit2 at the same time which is not possible. That is
> > problem of modules design, not problem of the specific default stream as
> > you put it.
> 
> That clashing libraries problem is the fatal design flaw in modularity
> as it exists today.
> 
> We've made it possible for each module to ship arbitrarily different
> versions of the same libraries, while all wanting to install into
> the same directory prefix. Thus two separately maintained modules can
> easily become mutually exclusive, which is a big pain for users who
> need to use both concurrently. This is essentially the "DLL Hell"
> problem.
> 
> The single shared /usr hierarchy only works (in the general case) when
> you have a single stream where everyone agrees on using the same version
> of each package.
> 
> I can only see this being solvable if non-default modules streams are
> required to be built into a unique /opt prefix instead of /usr.

Or better, if all the work that has gone into maintaining separately
packaged libraries went into maintaining one version and fixing
associated dependent packages as necessary... Especially for Java and
libgit2.

> 
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange
> |:|
> |: https://libvirt.org -o-https://fstop138.berrange.com
> |:|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange
> |:|
> ___
> 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

glassfish-hk2 - orphaning event notification

[Alex Scheel]

After much trimming, pruning, and hair-pulling by our fearless leader,
glassfish-hk2 was determined to be a spurious dependency which Fabio
replaced with one line of `sed` magic.

Please see: https://pagure.io/stewardship-sig/issue/91

If anyone is interested in taking this package back for whatever reason,
feel free to adopt it and claim ownership. However, the Stewardship SIG
no longer has use for this package and thus orphaned it.


Thanks,

Alex
___
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: Re-Launching the Java SIG

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 9:44:33 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 3:34 PM Alex Scheel  wrote:
> >
> > Obviously count us in, Fabio :-)
> 
> *Us* means the three guys from the Dogtag PKI team? :)

Yeah, but mostly expect Dinesh and I :)

> 
> > Do we need a two-step bootstrap process? A first (offline) step where we
> > run
> > gradle-wrapper and fetch all the resources, put all online dependencies
> > into a
> > SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
> > bootstrapped version which works) and then replacing _all_ assets with
> > versions
> > built using the bootstrapped gradle and finally rebuilding gradle?
> >
> > It'd be hell to set up the first time (two .specs?) and hell to make sure
> > we
> > get every package at the right version. But theoretically possible? :-)
> >
> >
> > But it might allow us to skip incremental bootstrap from a really old
> > gradle
> > version and might even get us a process which works for future bootstraps.
> 
> That's an innocent thought :) I'm afraid it won't work though.
> Do you think gradle is downloading source code for its dependencies?
> Nope, it only downloads prebuilt JARs.

Right -- I wasn't suggesting that it'd download source code. Merely that a
binary-JAR-bootstrapped Gradle could be used to (re)-build all of the
libraries it needed (from source this time!) and then re-build itself
(using those source-built libraries and building a new gradle from
source).

The internet-downloaded JARs could be put into lookaside and the SRPM
could pull them, put them in the right location, and finish the initial
Gradle build. Koji would finish the build and the resulting gradle would
be available for us to use.

IIRC the restriction on source code builds of packages can be waived for
bootstrap-only builds. So for initial build of gradle, we're fine using
the binary wrapper as long as we fully replace it with source-only builds.

Someone with a more recent understanding of packaging policy can weigh
in here though.

> 
> So the build script loads a prebuilt gradle-wraper.jar (that's shipped
> with the gradle sources) that then in turn downloads more prebuilt
> JARs from the gradle repository to satisfy gradle's build dependencies
> which are then used to actually build full gradle ...

Right :) So we'd take all of those new downloads and put them into
lookaside and ship a SPRM that finishes the build based off of those
internet-downloaded JARs. This satisifies Koji's no-internet policy
while giving us a (hopefully) useful Gradle build system as output.

> ___
> 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: Re-Launching the Java SIG

[Alex Scheel]

Obviously count us in, Fabio :-)

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 6:39:04 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:
> > Right, I figured it was some Fedora policy and not up to you. I suppose
> > I should have been more clear there. Sorry for any confusion, it was
> > aimed at the Fedora project as a whole as this is a Fedora issue.
> 
> I am aware that Arch is just packaging up the binary release artifacts
> published by the gradle project.
> But that's just never going to fly for fedora.
> 
> Arch is also the only distro I looked at that does this, everybody
> else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
> version, if gradle is available at all.
> 
> > FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
> > code via:
> >
> >
> > ./gradlew allZip
> 
> Now try doing that offline and without using the pre-built
> gradle/wrapper/gradle-wrapper.jar :)
> You'll be surprised how much junk the build process still needs to download.

Do we need a two-step bootstrap process? A first (offline) step where we run
gradle-wrapper and fetch all the resources, put all online dependencies into a
SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
bootstrapped version which works) and then replacing _all_ assets with versions
built using the bootstrapped gradle and finally rebuilding gradle?

It'd be hell to set up the first time (two .specs?) and hell to make sure we
get every package at the right version. But theoretically possible? :-)


But it might allow us to skip incremental bootstrap from a really old gradle
version and might even get us a process which works for future bootstraps.



- Alex

> 
> Fabio
> 
> > >
> > > 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
> > ___
> > 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
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: Proposal: Revise FESCo voting policy

[Alex Scheel]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, May 11, 2020 11:52:24 AM
> Subject: Proposal: Revise FESCo voting policy
> 
> During today's FESCo meeting, we encountered an unusual voting
> situation for the first time: Four FESCo members voted in favor (+1)
> of a measure and five FESCo members opted to abstain (0) for various
> reasons. However, the FESCo voting policy currently reads: "A majority
> of the committee (that is, five out of nine) is required to pass a
> proposal in a meeting." As a result, we were actually at an impasse
> until two of the FESCo members opted to change their votes to +1 to
> resolve the confusion.

Obviously FESCo members changing their votes is within their prerogative,
but what if nobody wanted to change their votes? I think the original policy
is correct: if you don't have a majority explicitly voting yes, you don't
have enough support and the resolution shouldn't pass. Abstaining is in two
categories:

 - I abstain because I don't care about this topic,
 - I abstain because I object to this line item, but not strongly enough to
   explicitly vote no, e.g., when the idea is generally correct but I don't
   explicitly back it or disagree with minor items in it.

I don't think a revision should be made, and counting the latter bucket of
votes into the former category isn't correct in the general case.

> It was subsequently suggested that we revise the policy to avoid this
> pitfall in the future. I volunteered to put together a proposal for
> how this could work and send it to the Fedora Development list for
> discussion. I propose the following changes to the FESCo voting
> policy:
> 
> * To pass any measure, a majority — defined as the greater of half the
> eligible votes (rounded up) — must vote in favor of the measure. The
> standard set of eligible votes is one vote per FESCo member. No
> measure may pass without at least one vote in favor.
> 
> * Abstaining from a vote (aka "voting 0") is considered to have
> removed that FESCo member's vote from the set of eligible votes. This
> must be done explicitly and is never to be assumed from lack of
> communication.
> 
> A practical effect of the new abstention rule is that if two FESCo
> members abstain, the measure would then require only a +4 vote to
> pass. (A single abstention would still require a +5 vote).

I'm confused how this holds. There are 9 seats on the council. If one
abstains, there's now an effective seat count of 8. Half of 8 is exactly
4, so wouldn't this mean a +4 vote is sufficient? What happens if the
vote is (+4, 1, -4)? Shouldn't this fail / end in a tie?

One way to implement your examples is to always add 0.5 before rounding:

 9 -> ceil(4.5 + 0.5) -> 5
 8 -> ceil(4 + 0.5) -> 5
 7 -> ceil(3.5 + 0.5) -> 4
 6 -> ceil(3 + 0.5) -> 4
 ...
 2 -> ceil(1 + 0.5) -> 2
 1 -> ceil(0.5 + 0.5) -> 1

> 
> 
> I'd also like to propose an additional policy modification that
> occurred to me while writing this message:
> 
> * A FESCo member may grant their proxy vote to another member of the
> Fedora community if they cannot be in attendance for a vote. If they
> do so, that vote is counted equivalently to any other. Proxy votes
> MUST be limited to predetermined topics and time period. (e.g. I can
> say "bookwar has my proxy vote on any topic directly related to ELN"
> while I am on vacation from MMDD until MMDD, but I cannot give my
> FESCo seat to a person of my choosing.)
> ___
> 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: Backports of fixes from F32 -> F31?

[Alex Scheel]

Just wanted to follow up and say thanks for this! Much appreciated;
I've given it karma. :)

- Alex

- Original Message -
> From: "Florian Müllner" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Florian Muellner" 
> Sent: Thursday, April 30, 2020 11:54:21 AM
> Subject: Re: Backports of fixes from F32 -> F31?
> 
> 
> 
> Hey,
> 
> On Thu, Apr 30, 2020 at 09:30, Alex Scheel  wrote:
> > 
> > And yeah, agreed. Backports are time consuming. But this is F31, not
> > F30.
> > There's at least another 6 months of support on this distro
> > (technically...)
> > and as referenced on that ticket, I'm not the only one that has hit
> > it;
> > there's about 10 people CC'd or replying saying they're affected.
> > 
> > Plus -- all I'm looking for is a yes/no. Is that too much to ask a
> > maintainer? :-)
> 
> 
> I'm afraid F31 does usually lose out to upstream/rawhide, RHEL 7, RHEL
> 8 and F32, sorry :-(
> 
> But regarding this particular issue, Olivier was kind enough to
> backport his fix upstream and I rolled another old-stable release.
> 
> The update is now available at
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d29c22c817, testing
> and karma are appreciated.
> 
> Regards,
> Florian
> 
> ___
> 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: F33 system wide change, java-11-openjdk as system jdk

[Alex Scheel]

Ah cool, so my guess was correct. :-) We're working on fixing this upstream
and then we'll get it pulled into Fedora. Mind if we ping you for a rebuild
when we're ready?


- Alex

- Original Message -
> From: judov...@email.cz
> To: devel@lists.fedoraproject.org
> Sent: Friday, May 1, 2020 2:19:17 PM
> Subject: Re: F33 system wide change, java-11-openjdk as system jdk
> 
> Hi Alex, both your packages
> "BuildRequires:java-1.8.0-openjdk-devel"
> So I could not pull it. According to the packaging guidelines   you should
> require only  "java-devel" (exactly for this case:)). Thus I could not found
> your packages by using build-requires queries. Even If I found, It would be
> useless, because java-1.8.0-openjdk-devel  will still be providing  itself.
> Please adapt your packages to java-devel only.  And when in int, bump them to
> build n that copr of mine.
> I will happily include them to the copr once you fix the BR. Crossing
> fingers! TYVM!
> 
> Jiri (sorry for different email, only github login worked for me today)
> ___
> 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: F33 system wide change, java-11-openjdk as system jdk

[Alex Scheel]

\o Hey Jiri,

I don't see two of our packages in the copr:

https://src.fedoraproject.org/rpms/pki-core/
https://src.fedoraproject.org/rpms/dogtag-pki/

Is there a way to know why they were excluded?

Thanks!


- Alex

- Original Message -
> From: "Jiri Vanek" 
> To: "Development discussions related to Fedora" 
> , "Fedora Java Development List"
> 
> Sent: Thursday, April 30, 2020 12:31:43 PM
> Subject: F33 system wide change, java-11-openjdk as system jdk
> 
> 
> 
> Hello fellow java package maintainers!
> 
> We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk
> for F33. Please see
> https://fedoraproject.org/wiki/Changes/Java11
> 
> Short Story:
>  * if you have some java package, be aware that we are bumping JDK in rawhide
>  * Ensure your package builds and runs fine with JDK11 (see the
> https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/)
>  * there is special tooling ready for this, before mass rebuild is launched
>  ** See
>  https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild
>  * If you do not want Fedora rotten with JDK8 for ever, continue reading
> 
> Long Story:
> We ran a preliminary mass rebuild of javastack in copr repo
> https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all"
> instead of "25" at the
> bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy
> & comp for build. You
> can see, the result was quite dramatic:
> 1225  total; attempted to rebuild
> 483   failed; from those 191 are trivial failures (but if you fix it, there
> is no guarantee real
> troubles are not hidden behind that)
> 186   succeeded
> 556   orphans or dead or otherwise tragic so the build did not even start
> 
> I would kindly ask you to search yourself in this list:
> https://jvanek.fedorapeople.org/java11/people
> If you are here, please check status of your package in
> https://jvanek.fedorapeople.org/java11/init
> (pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds).
>  * If your package is "succeeded",  congratulations nothing to do, and just
>  keep en eye on JDK bump
>  * If there is "failed" but contains "-   -" then it is probably orphan. 
> If
>  you wish to resurrect it,
> please ensure it runs against JDK11 (see lower)
>  * If there is "failed" but failed in "seconds", then those packages failed
>  so quickly, that the
> build was in initial phases. That usually mean that you build with
> source/target lower then 1.6
> JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to
> allow existence of
> compact 1.8 packages alongside main javastack. See
> https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version.
> Don't forget to
> upstream the patch, or maybe it is enough to update to more fresh upstream
> release which supports
> JDK11? it may happen, that after the fix, your build will fail in more
> terrible way (see below)
>  * If there is "failed", and its none of above, then your package simply
>  failed. Very often the
> scary error may be fixed by bump to latest upstream version. JDK 11 is out
> for several years.
> Please, try to fix the package. Don't hesitate to ask on
> de...@fedoraproject.org or
> java-de...@fedoraproject.org or directly to me jva...@redhat.com. If you fix
> the fail, feel free to
> share your fix, it may help others.
> We are trying to gather the most common issues at
> https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions
> .
>  Feel free to enhance the page, or write us your case (possibly both with
>  solution and without) so
> we can add it here.
> 
> Debugging Your failures.
> The copr repo we maintain, contains builds of java-11-openjdk as system JDK,
> javapackages-tools
> honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains
> successfully rebuilt
> packages. You can directly use this copr repo in several ways.
>  * first glance on error. On
>  https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your
> build  (select "all" instead of "25" at the bottom),
>  ** Click its number, select chroot (currently  fedora-32-x86_64 ) and check
>  the logs. Main log is
> build.log.gz.
>  * anything you push to rawhide, will automatically rebuild here in f32
>  chroot (we have a JDK in
> rawhide broken a bit currently)
>  ** It is the best approach. If you can fix your package in rawhide directly,
>  without breaking the
> rawhide too much, go for it
>  ** If yo need to experiment, I have a mock c

Re: Backports of fixes from F32 -> F31?

[Alex Scheel]

- Original Message -
> From: "Josh Boyer" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Florian Muellner" 
> Sent: Wednesday, April 29, 2020 9:04:12 PM
> Subject: Re: Backports of fixes from F32 -> F31?

> > > Just a curious observation/question.  Backports can often be time
> > > consuming and expensive.  Is there something preventing you from
> > > upgrading to Fedora 32?
> >
> > I don't know about Alex, but in general, upgrading can also be time
> 
> That's why I was asking Alex :)

Sure :-) 

I have four systems in my house running Fedora. Two I've updated to F32
because I don't care if I lose personal time to messing around with F32
the day of the release. That's how I've been able to confirm it fixes
this bug.

A third is my router-desktop. Rarely used with a display and affects other
people if I slow reboot it for upgrade + relabel. Bug isn't a problem there.

But my work laptop on F31 is where I spend 80% of my time. Its the most...
temperamental of the machines. F31 has been more stable than 29 or 30 before
it. Until I know F32 is stable on the others, I'm not going to update it.
I'll probably wait for the next company holiday or a weekend.

---

And yeah, agreed. Backports are time consuming. But this is F31, not F30.
There's at least another 6 months of support on this distro (technically...)
and as referenced on that ticket, I'm not the only one that has hit it;
there's about 10 people CC'd or replying saying they're affected.

Plus -- all I'm looking for is a yes/no. Is that too much to ask a 
maintainer? :-)


-- Alex
___
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: Backports of fixes from F32 -> F31?

[Alex Scheel]

Let's try this with the right Florian...


Sorry!

- Original Message -
> From: "Alex Scheel" 
> To: "Florian Weimer" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 29, 2020 4:02:48 PM
> Subject: Backports of fixes from F32 -> F31?
> 
> Hi Florian,
> 
> I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> such as this one against mutter:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1770296
> 
> 
> Could we get some of these fixes backported? I've not heard from you on
> this bug at all, despite a needinfo request since March.
> 
> 
> Thanks,
> 
> - Alex
> ___
> 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

Backports of fixes from F32 -> F31?

[Alex Scheel]

Hi Florian,

I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
such as this one against mutter:

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


Could we get some of these fixes backported? I've not heard from you on
this bug at all, despite a needinfo request since March.


Thanks,

- Alex
___
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

[Alex Scheel]

Hey Daniel, do you mind updating the GDPR compliance tag to include
Google?

Thanks!

- Original Message -
> From: "Adam Williamson" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 8, 2020 1:22:27 PM
> Subject: Re: Modularity Survey
> 
> On Wed, 2020-04-08 at 08:41 -0400, Alex Scheel wrote:
> > 
> > There's a marketing piece from 2017 that alleges that none of gsuite
> > (including their gmail for gsuite!) gets scanned for ads:
> > 
> > https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/
> > 
> > 
> > I think we can agree that--at one point in time (2014-2017)--Google's
> > position was that they aren't scanning gsuite content.
> 
> But that's not what a GDPR declaration is about at all. It doesn't have
> anything to do with what the entity who gets the data claims they are
> or are not doing with it. Only with whether or not they get the data.
> 
> I don't know or care whether Google is automatically scanning the
> content for the purpose of showing advertising or not, really. But
> that's not the question here at all.

I'm going to quit responding sometime as this really has gotten out of
hand, but please look at the context for my original mail in this
subthread.


Please, read the context in which I was responding!

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RGNGPXMXW4E6W4X6DUTLYWI4ZYQS3CHF/
and 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BBA25DUX4HZMYLGEDS7ZDLN2SQX5IYFU/

> > Indeed. Once again, Fedora is depending on third-party, proprietary, 
> > privacy-invading SaaS.
> Meets exactly my thoughts...
> This is yet again another disappointing choice of tool.
> 
> I'm not going to give anything to Google, hence I can _not_ answer the 
> survey.
> Too bad, there is much to be said about modularity, as the lengthy 
> threads have already shown.
> 
> Unfortunately, Fedora is drifting more and more away from the Libre 
> Software philosophy that over time made me a Linux-only user and a 
> Fedora packager. At some point, I will have to put my money where my 
> mouth is and find another ship.
> Yes, I'm bitter...

The replies I was responding to weren't expressly GDPR comments!

They're attacks on people!

IMO, that should've been called out. So I did. I agree, from a GDPR
compliance perspective, someone with access to the survey could add
a disclaimer.

But insinuations that Google is using the data submitted by this form,
on their own, is IMO, wrong. And should be called out. That's why I did.

> > I'll make the assumption that, were this to have changed, a number
> > of large businesses would've been upset and there would've been
> > media reports and potentially legal proceedings. I haven't found
> > any. :-)
> 
> Again I don't know why you're all making assumptions like this? Don't
> you read the news? Google (and Facebook et al) have been "caught" doing
> all sorts of stuff with user data all the time. It does make the news.
> Frequently.

I do read the news.

Google and Facebook have been caught abusing **individual** data. I agree
with you on that. I think it is wrong and they should stop.

But we're not talking about that.

We're talking about an enterprise gsuite account with a contract between
Google and Red Hat. Where are the news articles about Google doing data
mining on other companies data? Perhaps I've missed all the relevant news
articles though. I'd imagine, with all the data companies store in Google
drive, this would've been an easy case.

To not use GMail is one thing. To attack those who created an optional
survey--based on an unproven premise--is IMO, out of line. It isn't being
excellent to others. And to be clear, the two posters I replied to weren't
being excellent; you were ok.


- Alex
___
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

[Alex Scheel]

(I had several replies to Adam, but I ultimately got stuck finding
 supporting URLs until I revisited it this morning.)

IANAL.

- Original Message -
> From: "Kamil Paral" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 8, 2020 4:25:55 AM
> Subject: Re: Modularity Survey
> 
> On Tue, Apr 7, 2020 at 7:22 PM Adam Williamson 
> wrote:
> 
> > On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote:
> > > I'm sure we can trust that Red Hat did its
> > >
> > > due diligence and Google isn't using responses to a customer's form to
> > >
> > > track those taking the survey.
> >
> > I don't really know why you'd think anyone can trust that. Google
> > tracks everyone everywhere as hard as it can. It's what Google *does*.
> >
> > But I didn't actually suggest it's Terribly Awful to run this survey
> > through Google. I just said the privacy declaration seems to be wrong.
> >
> 
> I personally considered it quite clear that the intended meaning was that
> they are not giving the data away to anyone external deliberately. Your
> responses will be read and understood by a very small group of people and
> not published in raw form. Yes there are servers and software providers
> along the way. But this way you could also include the ISPs who also are
> not prevented from snooping in your packets (and it's trivial at least for
> plain text emails). And even if they provided a "direct" way to send your
> responses to their email, and we ignored the ISPs, still, Google is the
> email provider for most RedHatters. So there's no improvement at all.
> 
> I'm not saying we shouldn't talk about it, but the points mentioned are
> common for most data submissions anywhere. I don't think it was the core of
> the message.

:-) It is tricky trying to pin down what Google does, on the outside,
without any knowledge of what contracts actually got negotiated.

There is an undated white paper which directly discusses it:

https://gsuite.google.com/learn-more/security/security-whitepaper/page-6.html#no-advertising

The only date mentioned there is 2014. 


Coincidentally, the 2014 Google Apps privacy policy also explicitly called
it out:

https://gsuite.google.com/intl/en_us/terms/2014/2/premier_terms_ie.html


I tried looking at the new terms link on gsuite's page:

https://www.google.com/intl/en/policies/terms/

But that just redirects to the generic, Google-wide page:

https://policies.google.com/terms?hl=en

Which is geared more towards consumers than enterprises. Neither "enterprise"
nor "premier" appear. On the list of apps page:

https://policies.google.com/terms/service-specific?hl=en

There's a link here:

https://www.google.com/drive/terms-of-service/?hl=en


You can control who sees ads even, in a gsuite account, so maybe that's
sufficient:

https://support.google.com/a/answer/6304811?hl=en


There's a marketing piece from 2017 that alleges that none of gsuite
(including their gmail for gsuite!) gets scanned for ads:

https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/


I think we can agree that--at one point in time (2014-2017)--Google's
position was that they aren't scanning gsuite content. 

I'll make the assumption that, were this to have changed, a number
of large businesses would've been upset and there would've been
media reports and potentially legal proceedings. I haven't found
any. :-)


My 2c.

- Alex


Not delivered by GMail ;-)

> 
> ___
> 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: Modularity Survey

[Alex Scheel]

- Original Message -
> From: "Xavier Bachelot" 
> To: "Development discussions related to Fedora" 
> , "Kevin Kofler"
> 
> Sent: Tuesday, April 7, 2020 12:15:37 PM
> Subject: Re: Modularity Survey
> 
> Le 07/04/2020 à 12:29, Kevin Kofler a écrit :
> > Adam Williamson wrote:
> >> Well. Uh. Clearly it's being provided to *Google*.
> > 
> > Indeed. Once again, Fedora is depending on third-party, proprietary,
> > privacy-invading SaaS.
> > 
> 
> Meets exactly my thoughts...
> This is yet again another disappointing choice of tool.
> 
> I'm not going to give anything to Google, hence I can _not_ answer the
> survey.
> Too bad, there is much to be said about modularity, as the lengthy
> threads have already shown.
> 
> Unfortunately, Fedora is drifting more and more away from the Libre
> Software philosophy that over time made me a Linux-only user and a
> Fedora packager. At some point, I will have to put my money where my
> mouth is and find another ship.
> Yes, I'm bitter...

(I'm not on the modularity team).

Look folks. This isn't a Fedora-only survey. It is a survey run by Red Hat
members who are looking to engage with a community that includes Fedora,
Red Hat, CentOS and a bunch of other stakeholders as well. I think we can
all recognize that Google Apps usage is high among businesses. 

Yeah, if this were a Fedora-only survey, we all would've hoped they'd go
for an open source tool. But it isn't Fedora-only. And pretending like it
matters for this IMO, isn't a legitimate complaint. This is a business
backed Google Apps account. I'm sure we can trust that Red Hat did its
due diligence and Google isn't using responses to a customer's form to
track those taking the survey. But by definition, they need to hold a copy
of that data. Someone, somewhere would. That's how the internet works.  


I sit on the new Modularity meetings now. I'll be the first to admit I'm not
a strong supporter of Modularity. I've been very vocal against it in the
past. But I do think that this new team is honestly trying to do the right
thing and engage with the community. They aren't trying to push features 
top-down and they're trying to understand what is wrong and are trying
their best to fix it.

Part of that is collecting data and stories from people.

If we, as a community, push them away now, we'll never see any much-needed
improvements to modularity. And tbh, I'm not even sure we're in a place now
where we could remove it if we truly needed to, without a lot of pain in the
upgrade path.


Let's try and be reasonable here.


I'm willing to pass along any comments people have individually.



Thanks,

- Alex


> Regards,
> Xavier
> ___
> 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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Till Maas" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, April 6, 2020 1:39:49 PM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
> > - Original Message -
> > > From: "Miro Hrončok" 
> > > To: devel@lists.fedoraproject.org
> > > Sent: Monday, April 6, 2020 8:28:15 AM
> > > Subject: Re: CPE Weekly: 2020-04-04
> > > 
> > > On 06. 04. 20 14:19, Alex Scheel wrote:
> > > > That part isn't actually clear to me. There's certainly a vocal portion
> > > > against using GitLab
> > > 
> > > I think it's hard to see who's vocal against GitLab and who just wants a
> > > truly
> > > open decision process for this.
> > > 
> > > I've heard people who would love to get GitLab, but who are genuinely sad
> > > about how CPE management handled this.
> > 
> > Sure, can we have two positions in this voting system?
> > 
> >  1. I want GitLab,
> >  2. I want Pagure,
> >  3. I want something not listed here,
> >  4. I don't particularly care.
> 
> What do you want to do with this information? 

I'm not in CPE.

I'm curious what the _community's_ position is. There's a small portion of
people responding to this thread. We can make assumptions about what the
Fedora community thinks (and certainly we know what individuals of it think),
but until we have data, do we really know what the majority opinion is?

I value data over a few loud voices. :)

> Also I do not think it is
> a good idea to micro-manager CPE into a specific solution. IMHO it is
> more important to get the dist-git features that Fedora requested and
> probably also issue trackers for Fedora groups (for example Council,
> FESCo, ...) currently implemented in
> pagure.io), GIT repos with a git forge for Fedora (for example for docs,
> infra, releng). And it would be great to also ensure that Fedora
> contributors/Fedora Infra/CPE can contribute to these solutions to
> ensure that Fedora specific requirements can be met.

As I said elsewhere, I don't want to use this for a decision. I just
want to see what more than the ~60 people responding here and in the
other thread actually think about this issue.

I do agree, if this were a vote, it would boxes CPE in. But before the
Fedora community can engage with CPE, shouldn't the leadership (and those
of us arguing on the thread) understand what the rest of the Fedora
community thinks, such that we all can represent something cohesively to
CPE?

IMO, that was the step lacking from this process on the Fedora side.

> If it is easier to customize Gitlab to meet Fedora's dist-git
> requirements than to customize pagure, then it would be good for CPE
> to do this even if more people would like to prefer pagure. If it is the
> other way, then it could still make sense to use Gitlab for tasks used
> by pagure.io to benefit from better Gitforge features, there, but keep
> pagure for dist-git.
>
> Also, I do not have any idea how easy it is to get changes into Gitlab,
> so this is also something that needs to be taken into consideration.
> I find it somewhat troublesome that these questions are not answered,
> especially since the migration from pkgdb to pagure was very painful and
> is not yet completed.

Thanks for your opinion, your response has been recorded in this informal
poll. :)
 
> Kind regards
> Till
> ___
> 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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Daniel P. Berrangé" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 11:02:52 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 

> Watching the discussion in the other big thread, I feel it has become
> rather too toxic & negative, going over & over the same points, verging
> into personal insults, and repeatly beating people over the previous
> communication or process failures. I struggle to see anything positive
> coming from further contributors joining in that discussion thread,
> which I expect is why so many choose to remain silent.

Agreed on the toxicity and negativity, but I still think it is important
to get a sense of everyone's thoughts, not just those of us who participate
in this thread.

> Going for a formal vote on this topic would not be a good step at this
> point in time, as the issue is far too emotive & raw. A vote will serve
> to crystalize division instead of healing it & we need to consider what
> is viable, as voting for something that can't then be delivered is even
> worse.

I wasn't suggesting a formal vote. I was suggesting a survey, using an
existing mechanism. We could also use Google forms (like Modularity did),
but that'd make the results less visible and some people don't like
Google. Also, the voting mechanism ties into FAS ID's and has restrictions
on who can participate (users with two different groups right?). It'd be
hard to enforce something similar with Google forms.

> IMHO there needs to be a general cooling off period, followed by a fresh
> look at what the realistic options available to Fedora are, given the
> current decisions that have been made & the resources available to the
> project[1]. We need to be positive & constructive if we're to make any
> progress, and get out of the negative blame game we're in right now.

I think we need to involve everyone who CPE works with in one forum,
otherwise we'll likely arrive at maintaining two separate projects,
one just for Fedora and one for CentOS and Red Hat. Perhaps that is
what is best though, who knows.

> Regards,
> Daniel
> 
> [1] I'm not saying that we must go ahead with the decision to replace
> Pagure with GitLab. Just that we need to carefully consider where
> to go from here, as any decision needs to be sustainable for the
> project in the long term.
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange
> |:|
> |: https://libvirt.org -o-https://fstop138.berrange.com
> |:|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange
> |:|
> ___
> 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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 10:57:40 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> Le lundi 06 avril 2020 à 10:09 -0400, Alex Scheel a écrit :
> > 
> > In the last FESCo election, 273 ballots were cast [0]. According to
> > the
> > graph maintained by Matthew Miller [1], we have between 225 and 375
> > active maintainers in Fedora, depending on how you count.
> 
> That’s *weekly* activity. As in, the packager finished something, and
> was active a specific week landing the result in Fedora. It does not
> count all what happens outside Fedora infra before the result lands.

I'm not sure why what happens outside Fedora infra has anything to do
with the dist-git discussion. Are you suggesting that all contributors
to all Fedora upstream should weigh in on this discussion as well? I
mean, that'd be nice I suppose, but mostly this a discussion for people
who interact with dist-git frequently. 

I do recognize that perhaps a monthly contributor list might have higher
magnitude than 300. But there's still old bugs, new bugs, and random other
contributions that could count as activity besides pushing a Bodhi update.


My 2c.

- Alex

> 
> --
> 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
> 
___
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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Ben Rosser" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, April 6, 2020 9:49:13 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 

Thanks for sharing your thoughts. :-)

> Not saying you're wrong that it would be nice to have the ability to
> poll a broader selection of packagers. But I'm not sure using the
> FESCo voting system would really accomplish that either. How many
> people actually vote in FESCo elections relative to the number of
> active packagers? I'm sure you could argue that, depending on the
> turnout, the results wouldn't be necessarily representative either.

In the last FESCo election, 273 ballots were cast [0]. According to the
graph maintained by Matthew Miller [1], we have between 225 and 375
active maintainers in Fedora, depending on how you count.

That says that FESCo elections are ~5x more participated in than these
mailing list discussions, and are a much more representative sample of
all our (active?) packagers. I'm not sure if FESCo votes count as
packager activity in the above graphs; I'm guessing not.


My 2c.

- Alex

[0]: subj: "FESCo election results", sent 6/Dec/'19 by bcot...@redhat.com,
 to this mailing list.
[1]: 
https://mattdm.org/fedora/fedora-contributor-trends/active-contributors-by-week.svg

> 
> Ben Rosser
> ___
> 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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 9:10:56 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
> > 
> > It'd be interesting to see if the FESCo election system could be
> > repurposed to get a sense of all packagers' opinions, rather than
> > make assumptions on how the community as a whole feels based on a few
> > vocal members and their participation in the mailing lists.
> 
> 
> Fedora guidelines ask Fedora packagers to subscribe to the devel list,
> so it’s the official place to reach Fedora packagers.

That's not the point I was making.

Not everyone is inclined to loudly argue their positions on the mailing
list. There have only been 12 unique participants to this thread and 57
to the other thread.

That isn't indicative of the entire Fedora packager ecosystem. A lot of
people are staying silent.


I believe we need a different way to engage the rest of our packager
base.

- Alex

> And practically, ignoring officialdom, yes there is a self selection
> bias, every packager does not follow guidelines and the list. But, it
> is a bias in favor of people who do stuff, and use the list to
> coordinate, ie the portion of the packaging community you least want to
> ignore, because they pull all the others.
> 
> --
> 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
> 
___
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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Miro Hrončok" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, April 6, 2020 8:28:15 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On 06. 04. 20 14:19, Alex Scheel wrote:
> > That part isn't actually clear to me. There's certainly a vocal portion
> > against using GitLab
> 
> I think it's hard to see who's vocal against GitLab and who just wants a
> truly
> open decision process for this.
> 
> I've heard people who would love to get GitLab, but who are genuinely sad
> about how CPE management handled this.

Sure, can we have two positions in this voting system?

 1. I want GitLab,
 2. I want Pagure,
 3. I want something not listed here,
 4. I don't particularly care.

--- 

 a. I am OK with how this was handled,
 b. I would prefer an open process,
 c. I don't care how it was handled.


IIRC, FESCo voting is a ranked voting scheme, so we'd also get a sense of
preference for each of these items.


It'd need some disclaimer that this is meant as a survey and not as an
actual decision mechanism and that the results wouldn't necessarily
influence the outcome. But as a way of reading the temperature of the
entire room and not guessing based on mailing list participation, it
might be better.


My 2c,

- Alex

> 
> --
> 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
> 
___
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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Dominik 'Rathann' Mierzejewski" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, April 6, 2020 7:09:38 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On Monday, 06 April 2020 at 12:41, Leigh Griffin wrote:
> > On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow 
> > wrote:
> > 
> > > On 4/4/20 3:02 PM, Aoife Moloney wrote:
> > > > However we do
> > > > recognize that it was still nonetheless a decision that was not made
> > > > in public, and for that we can only now offer our apologies for this
> > > > mistake and learn a hard lesson from it.
> > >
> > > It's simply not true that this is the only thing that can be done. You
> > > can hold off on making a decision, and follow an open process instead.
> > 
> > We are engaged with the Fedora Council on the next steps here for the
> > adoption of Gitlab / the retirement of Pagure from the CPE remit. That much
> > of the decision has been made, the actual specifics are what we are
> > engaging on to make sure that the Fedora needs are satisfied as we move
> > forward.
> 
> The majority here is telling you to hold off execution of that
> "decision" and revisit it, but you're ignoring those voices entirely and
> offering useless "apologies" instead. You cannot pretend to be part of a
> community if you just ignore its other members and do your own thing.

That part isn't actually clear to me. There's certainly a vocal portion
against using GitLab, but is that sufficient to determine it is the
majority of the Fedora packager community? I at least felt tired of
arguing and decided to mostly quit arguing versus continuing to participate
in this thread.

It'd be interesting to see if the FESCo election system could be
repurposed to get a sense of all packagers' opinions, rather than
make assumptions on how the community as a whole feels based on a few
vocal members and their participation in the mailing lists.


- Alex
___
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: CPE Git Forge Decision

[Alex Scheel]

- Original Message -
> From: "Panu Matilainen" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, April 1, 2020 6:22:39 AM
> Subject: Re: CPE Git Forge Decision
> 

> > I also appreciate that as a community developing our own solutions is
> > something important and something that seems to matter a lot, but we
> > have to realize that the development and maintenance effort cannot be
> > carried out by the CPE team any more. Maybe this is a opportunity to
> > create a SIG or a working group for people that are interested to carry
> > on this effort.
> 
> But this is precisely at the heart of the problem: people feel they were
> not given an opportunity to lend a hand, and that now its too late
> because the messaging is that we go with GitLab, no matter what.

Pagure has huge developer experience bugs filed against it for many
years. Where have all these contributors been? Are those of us who really
dislike Pagure's workflows in the minority? Or are others more prone
to put up with it because it is free, open source software?


IMO, it seems like an ideological argument, not a sound technical
one.

- Alex
___
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: The Git forge decision (was CPE Weekly: 2020-03-28)

[Alex Scheel]

- Original Message -
> From: "Neal Gompa" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Alex Scheel" , "Leigh Griffin" 
> Sent: Monday, March 30, 2020 3:30:20 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
> 

> As for Gitea, we're basically at parity with Gitea now. The major
> difference between Pagure and Gitea is that Pagure is highly
> extensible and Gitea is designed to be a very self-contained
> application. Plugging Pagure into workflows and infrastructure is
> substantially easier than doing the same with Gitea.

The following "just work" with Gitea and have usable defaults:

 - Full Text Search by default
   https://pagure.io/pagure/issue/2505
 - A real search bar
   https://pagure.io/pagure/issue/4543
 - Proper diff line numbers
   https://pagure.io/pagure/issue/2193
   https://pagure.io/pagure/issue/724
 - Proper inline comments
   https://pagure.io/pagure/issue/3488
   https://pagure.io/pagure/issue/4488
   https://pagure.io/pagure/issue/3646
 - ... I could go on

Pagure isn't at parity with Gitea. Please run an instance of Gitea and
compare. The UX with Gitea is _much_ better.

If these issues are old, please close them. 


- Alex
___
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: The Git forge decision (was CPE Weekly: 2020-03-28)

[Alex Scheel]

- Original Message -
> From: "Martin Kolman" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Leigh Griffin" 
> Sent: Monday, March 30, 2020 3:05:54 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)


> > And to be clear: there's a difference between a Fedora-sponsored
> > Development forge and a new git forge for dist-git. A lot of this
> > discussion has conflated these two cases. I mostly care about it
> > releasing the former role (pagure.io) and don't care much about
> > the latter role (s.fp.o).
> I personally see this pretty much the other way - there are many good
> or usable forges for hosting ones project. There is at the moment pretty much
> only one git forge with good (and any at all any) integration with Fedora
> processes
> - Pagure.
> 
> That's why I see Pagure as important mostly in the Fedora family context and
> less
> important in the general git forge are. It would certainly be nice to see
> Pagure
> take over that as well, but I see having a fully open git forge with full
> Fedora integration sitting on top of distgit as more important.

I don't really use dist-git's forge for much. Maybe for hitting "fork" when
I need to open a PR against another repo, and filing the PR. Everything else
happens via fedpkg/git/bodhi/koji... on the command line. 

I don't really care about showing the latest versions of packages on dist-git
(that's what bodhi/koji is for). That's the most recent user-visible feature,
yes? Why that? ~shrugs~

Having a little better admin/group integration would be nice.

But as long as it doesn't take ages to fork a repo (and Pagure does sometimes!),
I don't really care. I'm also not a proven packager or the owner of a huge
package dependency tree (python, java, perl, ...). I really just care about a
few packages, plus whatever is in the Stewardship SIG.

I guess a little nicer orphan/unorphan package procedure would be nice, but
you'd still need a ticket for unretiring dead packages, which is where I've hit
the most problems/delays.

But as long as I can continue to work from the command line, I don't really
care what the WebUI is as long as it works and isn't too slow.



My 2c. but I'm really agnostic about dist-git forges. :-)

- Alex
___
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: The Git forge decision (was CPE Weekly: 2020-03-28)

[Alex Scheel]

- Original Message -
> From: "Bruno Wolff III" 
> To: "Leigh Griffin" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Monday, March 30, 2020 2:08:21 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
> 
> On Mon, Mar 30, 2020 at 17:20:04 +0100,
>   Leigh Griffin  wrote:
> >On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann  wrote:
> >
> >We are trying to reduce the total ownership of the team to allow us to
> >provide value on initiatives that are requested of us by our stakeholders.
> 
> Pagure has value beyond Fedora and RedHat. In some ways it has more value
> than Fedora the OS, because there are less free options in the git forge
> space. (Gitlab isn't usably free as is. It would need a real fork to
> get out from under the sponsor's conflicts of interest.)

Have you tried to use Pagure as a development based git forge? And not
just as a dist-git hosting location? It needs a lot of help! More than the
current resources provide.

The reasons why are well documented in Pagure's issue tracker.

If that's something you value, feel free to contribute to Pagure upstream.
But Pagure can't compete with Gitlab as a development forge in its current
state.

There are other public git forges that behave better than Pagure:

 - SourceHut 
 - Gitea
 - ...

So I don't think this actually has as much value as you think.


And to be clear: there's a difference between a Fedora-sponsored
Development forge and a new git forge for dist-git. A lot of this
discussion has conflated these two cases. I mostly care about it
releasing the former role (pagure.io) and don't care much about
the latter role (s.fp.o).


My 2c. 

- Alex

> 
> I would have expected the council to consider this an important project
> worth pursuing on its own, not just for running part of Fedora's
> infrastructure.
> ___
> 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: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33

[Alex Scheel]

- Original Message -
> From: "Andrew Haley" 
> To: "Development discussions related to Fedora" 
> , "Alex Scheel" 
> Cc: "Omair Majid" 
> Sent: Monday, March 30, 2020 12:36:23 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system 
> JDK in F33
> 
> On 3/30/20 4:47 PM, Alex Scheel wrote:
> > For one example here, take the long-standing Debian ticket against Dogtag:
> > 
> > https://www.pagure.io/dogtagpki/issue/3088
> > 
> > OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA
> > isn't
> > available. This is a requirement for our particular application.
> > 
> > It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works
> > fine
> > on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time
> > to
> > debug and figure out what broke in OpenJDK.
> > 
> > 
> > With the introduction of JSS's SSLEngine, we can work around this problem,
> > but
> > that isn't yet merged.
> > 
> > https://github.com/dogtagpki/jss/pull/150
> 
> Tricky. It's kinda inevitable that some things will break at some time. We
> have to decide whether Dogtag is a blocker for JDK 11 as system JDK.

FWIW, Dogtag is part of IPA, which is already a blocker for GA releases. But,
we're concurrently working on an alternative SSLEngine implementation that will
fix our problems by not using the JDK TLS stack.


- Alex

> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> ___
> 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: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33

[Alex Scheel]

- Original Message -
> From: "Jiri Vanek" 
> To: "Development discussions related to Fedora" 
> , "Miro Hrončok"
> , "Deepak Bhole" , "Severin Gehwolf" 
> , "Omair Majid"
> 
> Sent: Monday, March 30, 2020 11:38:34 AM
> Subject: Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system 
> JDK in F33
> 
> On 3/30/20 5:11 PM, Miro Hrončok wrote:
> > On 30. 03. 20 16:04, Ben Cotton wrote:
> >> === Other ===
> >> * Proposal owners:
> >> ** based on above, adapt jdk8 and jdk11 package provides
> >> ** If necessary tune the build environment
> >>
> >> * Other developers:
> >> ** based on selected approach to tune the main build tools
> >> *** at least jpackage-tools and maven will be very likely affected
> >> ** based on selected approach to tune the rpmbuild/macros
> >> ** many java package maintainers will maybe need to adapt theirs packages
> >> *** After the approach is agreed, mass rebuild must be performed
> >> *** FTBFS bugs connected with this proposal, maybe with jira ticket to
> >> allow discussion.
> 
> Thank you for bringing it up!
> > 
> > I don't understand who does all the hard work. Will the change owners just
> > change the default and go
> > away, or will the change owners handle the rebuilds?
> 
> We will handle the tuning of jdk8 and jdk11 rpms. Also we will do an initial
> testing if it does what
> it should.
> Once it is done, mass rebuild is launched. we will then see. But it will be
> in on individual package
> owners to fix theirs packages.
> We will definitely help where necessary or where needed, and will most likely
> gather the most common
> cases, but to push to not-owned repos... only in critical cases.
> 
> Of course we can reconsider, but it is not on powers of few (5?) individuals
> to fix 2500 packages,
> even if it will be only two or three most common cases.
> 
> As for the runtime part, it is another story. There again we will do
> everything necessary to fix the
> problems both usptream and downstream, but the runtime casaes will flow up
> only in later stages of
> lifecycle  of f33. Possibly even after f33 release.  Note, that if there is
> serious runtime issues,
> then it would be really poorly written usptream application or very outdated
> downstream, not broken
> migration. Still the help will be attempted to be provided.

For one example here, take the long-standing Debian ticket against Dogtag:

https://www.pagure.io/dogtagpki/issue/3088

OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA isn't
available. This is a requirement for our particular application.

It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works fine
on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time to
debug and figure out what broke in OpenJDK.


With the introduction of JSS's SSLEngine, we can work around this problem, but
that isn't yet merged. 

https://github.com/dogtagpki/jss/pull/150



My 2c., but I hope help is given, especially in testing the new packages to
make sure nothing subtle broke.

- Alex

> 
> > 
> > As a side not, please don't mix in Jira tickets, that sounds RH internal to
> > me.
> 
> Sure. If I did, then not intentionally. By jira ticket in the above  I had in
> mind general ticket on
> pagure or similarly. The word jira did not belonged here. fixed the doc.
> > 
> Thanx!
>  thanx a lot,
> J.
> 
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jva...@redhat.comM: +420775390109
> ___
> 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

Java Packaging Guidelines - .so in JARs?

[Alex Scheel]

Per $SUBJ, I was looking for guidance from the Java community about
embedding .so files within JARs.

I found these docs:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_applicability

Which seem to have conflicting commentary on this:

 - A Java package uses JNI if it contains a .so file. Note that this file can
   be embedded within JAR files themselves.
 - JNI shared objects MUST be placed in %{_libdir}/%{name}

As long as the JAR for the application is played in 
%{_libdir}/%{name}/%{name}.jar,
does this mean that the .so can be placed within the JAR?


The benefit to .so-in-JAR is that the JAR always knows where to find the .so,
even if the user installs multiple versions of the same package, or, worse,
copies JARs from different systems around.


Wondering what the community's thoughts are,

Alex
___
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 Check for jsmith

[Alex Scheel]

Thanks! Non-responsive maintainer check canceled from my perspective.

- Original Message -
> From: "Jared Smith" 
> To: "Alex Scheel" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, February 12, 2020 1:14:11 AM
> Subject: Re: Non-Responsive Maintainer Check for jsmith
> 
> On Tue, Feb 11, 2020 at 4:01 PM Alex Scheel  wrote:
> 
> > I'm initiating the non-responsive maintainer policy for jsmith.
> >
> 
> Sorry for the slow reply -- I've been busy lately finishing up graduate
> school, and I was on vacation last week.  I will attempt to respond to your
> bugzilla request as quickly as possible.
> 
> -Jared
> 
> ___
> 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

Non-Responsive Maintainer Check for jsmith

[Alex Scheel]

I'm initiating the non-responsive maintainer policy for jsmith.

Per: 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Week -1:

Mail to jsmith (cc: devel@). Sent 7 February 2020. Subject:
nodejs-babel-runtime - orphan?

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

Week 0: 

Filed BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1801896
Open Bugs (381 count):

https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&email1=jsmith.fedora&emailassigned_to1=1&emailtype1=substring&list_id=10832612&product=Fedora&query_format=advanced


Does anyone know how to contact jsmith? 

I'm specifically looking for a solution to the nodejs-babel-runtime
package not being installable on Fedora: 

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



Thanks,

Alex
___
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

nodejs-babel-runtime - orphan?

[Alex Scheel]

\o Hey Jared,

I recently tried looking for the Babel compiler in Fedora, and
stumbled upon the packaged version, nodejs-babel-runtime. However,
it isn't installable:

Error: 
 Problem: conflicting requests
  - nothing provides (npm(regenerator-runtime) >= 0.10.0 with 
npm(regenerator-runtime) < 0.11) needed by 
nodejs-babel-runtime-6.23.0-6.fc31.noarch


This has been a known issue for quite some time:

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



Do you still have cycles to maintain nodejs-babel-runtime, or
should it be orphaned?



Thanks!

Alex
___
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: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, January 29, 2020 8:47:46 AM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> On Wed, 29 Jan 2020 at 05:14, Andrew Haley  wrote:
> >
> > On 1/27/20 3:13 PM, Alex Scheel wrote:
> > > N.B.: I'd like to thank the Red Hat JVM team for being solid in
> > > their Fedora execution. But they maintain only the JVM, and not
> > > the rest of the Java ecosystem. :-)
> >
> > Thank you.
> >
> > One (perhaps) rather minor point in the middle of this important
> > discussion: there is no "Red Hat JVM team." We're responsible for the
> > entire base Java (SE) platform, that is to say the VM and the
> > surrounding Java libraries.
> >
> > Also, we're not just responsible for RHEL and Fedora: our team and our
> > partners in a few other organizations are responsible for all OpenJDK
> > updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
> > to say, apart from Oracle's proprietary customers, most of the Java in
> > the world.
> >
> 
> The issue is that people (developers, users, maintainers) lump the
> entire ecosystem together.. so yes you maintain that but why don't you
> also maintain all the java packages which sit on that platform so it
> is 'useful' to them. [Yes the question is one of scope, time and
> resources.. but to a lot of people it needs clear explanations in the
> same way that people will take their Ford to a Toyoto autoshop because
> 'its a car, you should be able to fix it']

Right Andrew: Stephen was drawing the distinction I was trying to make.
I lump the Java SE platform into "roughly" what I was calling the JVM
team. You're roughly the group that does what'd be the "core" work in
other languages: maintains the compilers and the stdlib. My terminology
there was incorrect; I suppose "JRE" is more correct.

Is it correct to say that your team and immediate coworkers don't
maintain say, the Apache libraries, the various build systems, IDEs,
and the JBoss libraries? 

My point is that some language SIGs/teams take a more active role in
making sure a decent amount of non-stdlib software runs and is
maintained by them. The "core" Java (JVM + JRE) team doesn't seem to
engage in other places. Which is totally fine, from my PoV, as long
as there is communication between the two parts and between the group
and the wider Fedora community, and the overall experience is inclusive.


Instead, most of the library support falls to Joe's team, including
Mikolaj. That's where most of the shortcomings in Java packaging are
seen, including unfriendly, non-inclusive modularization policies.
They're the ones that have orphaned large segments of packages, which
ultimately lead to starting this mail thread. :-)

Perhaps putting words in Bill's mouth here, but I don't subscribe any
of his issues to the JRE team. They're mostly caused by issues in a
lot of packages disappearing, and Matt Booth trying his best to clean
up after that (with the help of Stewardship SIG). But we're all busy
folks and sometimes we can handle that new package load and sometimes
we can't.


And yes, you do a lot of great work in other places too. I thank you
for that the few times I need to touch Java on non-Linux platforms. :-)


Keep up the good work,

- Alex

> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> 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: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Tom Seewald" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, January 26, 2020 12:35:32 PM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> > On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
> *snip*
> > True. Nobody cares about Java packages in fedora, not even Red Hat
> > employees. If you look at the members of the Java SIG, a lot of them
> > were (or still are) Red Hat employees. For example, even JBoss /
> > WildFly (a pretty big Java project by Red Hat) was unmaintained and
> > broken, and most of it has now been removed from future fedora
> > releases. I wonder what they are going to do with RHEL 9 - maybe
> > somebody notices their stuff isn't available on fedora anymore.
> 
> Do you happen to know what the Red Hat employees who maintain Java-based
> products use as their desktop OS? RHEL? macOS?

As a Hatter, I'm proud to say that I--and most all of my team--use
Fedora for our work machines. I run F31 without modular repos on all
four of my boxes in my home office.

I work on Dogtag PKI (https://www.dogtagpki.org), a private CA, built
on top of a Tomcat/Java stack.


Responding to the JBoss dismissal: JBoss is its own product and doesn't
have the goal of shipping on Fedora before it ships in its own product.
All of the JBoss packages maintained in Fedora are maintained by the
community (including non-JBoss Red Hatters) who need them in other
packages.

Concretely, if you'd like to see more JBoss packages, join us in the
Stewardship SIG and collaborate to revive the ones you care
about. :-)


- Alex


N.B.: I'd like to thank the Red Hat JVM team for being solid in
their Fedora execution. But they maintain only the JVM, and not
the rest of the Java ecosystem. :-)

> ___
> 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: Git Forge Requirements: Please see the Community Blog

[Alex Scheel]

- Original Message -
> From: "Michael Catanzaro" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 21, 2020 4:31:47 PM
> Subject: Re: Git Forge Requirements: Please see the Community Blog
> 
> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  wrote:
> > And any discussion of GitHub isn't going to involve self-hosted, it's
> > going to involve GitHub.com, which means we're talking about losing
> > more of our independence as a project. This is one of those things
> > that I'm not sure is a wise move.
> 
> Well since we have a request for requirements: I propose requirements
> #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
> community would be outraged if we fail to meet either requirement.
> 
> So if we can agree on that much, then we can avoid wasting time by
> including GitHub in the list of options. That would bring us to a
> choice between GitLab CE and Pagure. (Are there any other serious
> options?)

I'd mention sr.ht (sourcehut) and gitea; the latter I run myself.

https://sourcehut.org/ (live: https://git.sr.ht/)
https://github.com/go-gitea/gitea demo: https://try.gitea.io/)

YMMV.

> 
> Michael
> 
> ___
> 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: Git Forge Requirements: Please see the Community Blog

[Alex Scheel]

I had replied to Fabio on IRC but... :-)

- Original Message -
> From: "Guido Aulisi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 21, 2020 3:48:31 PM
> Subject: Re: Git Forge Requirements: Please see the Community Blog
> 
> 
> 
> > Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini
> >  ha scritto:
> > 
> > On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  > <mailto:lgrif...@redhat.com>> wrote:
> >> 
> >> Hey Everyone,
> >> 
> >> On behalf of the CPE team I want to draw the communities attention to a
> >> recent blog post which you may be impacted by:
> >> https://communityblog.fedoraproject.org/git-forge-requirements/
> >> <https://communityblog.fedoraproject.org/git-forge-requirements/>
> >> 
> >> We will be seeking input and requirements in an open and transparent
> >> manner on the future of a git forge solution which will be run by the CPE
> >> team on behalf of the Fedora Community. This mail is being sent to the
> >> devel, mindshare and council-discuss lists for maximum visibility on a
> >> BCC to allow each list have their own views. Please forward it to any
> >> other list you may feel is relevant to maximise the exposure.
> >> 
> >> Thanks in advance,
> >> Leigh
> > 
> > Alright, I have some questions that are not answered by the blog post.
> > 
> > - What is going to happen to the two pagure instances at pagure.io
> > <http://pagure.io/>,
> > and src.fedoraproject.org <http://src.fedoraproject.org/>?
> > 
> > I think pagure.io <http://pagure.io/> is a good home for fedora-related
> > projects (it was
> > the successor to fedorahosted.org <http://fedorahosted.org/>, after all,
> > IIRC). I know that many
> > group efforts are hosting their source code, ticketing system, etc.
> > there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> > shut down pagure.io <http://pagure.io/>, I assume those projects will have
> > to be moved
> > somewhere?
> +1
> 
> > Also, it's very nice to have a PR-based workflow for some
> > shared-maintenance packages on src.fedoraproject.org
> > <http://src.fedoraproject.org/>, and I don't
> > think losing that feature would be a good thing for fedora.
> +1
> 
> > - How is GitHub considered to be an alternative here?
> +1 …and to my knowledge GitHub is closed source.
> 
> > I don't think (public or hosted) GitHub can do what is currently done
> > on src.fedoraproject.org <http://src.fedoraproject.org/>, can it?
> > I'd also not want to see fedora use a closed-source product for such a
> > core service ...
> > 
> > - Which features are missing from pagure, compared to the other forges?
> +1 It’s not clear reading the original POST
> 
> > For my purposes, I don't miss any feature on pagure.io <http://pagure.io/>
> > compared to my
> > repositories on github.com <http://github.com/>, and OTTOMH, I can't come
> > up with any
> > missing features, at all …
> +1

From a _development_ POV, there's a number of things missing for it being
the primary git forge for pagure.io (not arguing about src.fedoraproject.org
or packaging use cases -- but some of those will benefit by these as well):

 - Real full-text search across issues and PRs. No need to RTFM.
(
 For those not having RTFM'd, you use "content:" to do a
 full-text search in current Pagure. I've argued that it should
 behave like other forge's searches:
 https://pagure.io/pagure/issue/2505#comment-582516
)
 - A UI with a UX that makes sense.
   https://pagure.io/pagure/issue/4543
   https://pagure.io/pagure/issue/2193
   https://pagure.io/pagure/issue/42(duped: 343)
   https://pagure.io/pagure/issue/2167
   (and you could keep cherry-picking issues. There's a section of
opened ones with UI tags).
 - The above is a huge category and I think its worth restating
   some items:
- Search, search, search.
- Split diff
- Real line numbers in the diff
- Expanding context around the diff
  (Diff, diff, diff?)
- Workflow on reviewing PRs is sub-optimal compared to most
  other forges.
 - Pagure is often slower than GitLab for me. YMMV.
 - ...

For a period of time, IDM tried using Pagure for FreeIPA development.
They filed a huge number of issues. Now we host issues on Pagure, and
have moved development to GitHub. [*] I think we've mostly quit filing
bugs; the Pagure team has done a good job with the resources they've
been given, but 

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

[Alex Scheel]

> 1. I didn't ask for/want a module.
> 2. They aren't actually needed. After disabling them and reinstalling the
> programs I care about (or could have used distro-sync) they weren't
> actually needed.

This is where I'll drop a plug for the Stewardship SIG. Thanks in large
part to Fabio's great work, 2 has been possible since the ant and maven
modules were introduced.

The only distribution we don't maintain as ursine is eclipse. But we
still maintain many of the dependencies of the Java stack (including 
LibreOffice,
Dogtag, Ant and Maven) as ursine.

For some of us in the SIG, this means that we're able to run without 
modular repos enabled at all, and continue doing or daily jobs requiring
the Java stack. 


If you like the work, consider helping out!


We keep a list of packages that we're looking for updates on:

https://decathorpe.fedorapeople.org/stewardship-sig-stats.html

But check our list of pending PRs first:

https://decathorpe.fedorapeople.org/stewardship-sig-prs.html


Feel free to join #fedora-stewardship on Freenode if you're interested
in helping out but don't know where to start. 

- Alex
___
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-java] What's the State of the Java SIG?

[Alex Scheel]

- Original Message -
> From: "Gerald Henriksen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, November 18, 2019 6:40:54 PM
> Subject: Re: [fedora-java] What's the State of the Java SIG?
> 
> On Mon, 18 Nov 2019 13:37:39 +0100, you wrote:
> 
> >Fabio Valentini wrote:
> >> Or is it time for a "tabula rasa" and restart the SIG?
> >
> >IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the
> >current remains of the Java SIG and create a new Java SIG from scratch that
> >actually cares about packaging Java properly in and for (non-modular)
> >Fedora.
> 
> Great, you eliminate the remaining members of the Java SIG (those who
> didn't go running away because forcing Java stuff into RPMs was too
> painful).
> 
> Now where are you going to get new members to create this new Java
> SIG?
> 
> I mean, the Java SIG isn't forcing Java packagers to use Modularity,
> so that isn't why the Java SIG is dying.

For historical context...

Without Ursa Prime/Major/whatever we're calling it now, that's where
we've been for the last... n > 6 months. If you depended on Ant, Maven,
or any of the minor libraries they've modularized and put in their default
module stream, the Java SIG's (un)official(?) policy was to have you
modularize. Because that was the only way to use these packages! And if
your runtime dependencies are in javapackages-tools? Good luck! You have
to rebuild them inside your own module!

It has entirely been the efforts of the Stewardship SIG to enable ursine
users. We've done that by continuing to packaging many of the libraries
that the Java SIG has either dropped entirely or made modular-only. For
the last n > 6 months, packages such as LibreOffice and Dogtag have
continued building only because we keep maintaining these packages as
ursine. We did this in part to keep our own packages building and in
part because we don't believe modular packages are a real answer to
maintainership problems. 

Purely speculation on my part, but part of what likely caused the Java
SIG to effectively dissolve was because each maintainer was an island,
a hero. They maintained all their packages on their own; there is no
"Java SIG" FAS packaging group. As Mikolaj has said, the meetings stopped,
the mails stopped. People probably just quit working together.

Part of what we've tried to do differently in the Stewardship SIG is
encourage community and peer support. We're a FAS group and all our
packages are owned by the collective group. We maintain public lists of
what's in need of review [0], what we maintain [1], what we're looking
for updates on [2], and what we're in the process of doing [3]. Anyone
is free to contribute to the Stewardship SIG too! Fabio does a lot of
work, and we're deeply thankful for that! But a few of us double check
his work, help out on minimizing package dependencies as we get time,
catch CVE updates, and perform rebases too. We're always looking for
more members, and if you're interested in joining, just shoot a mail!


Now, I do want to point out there are two faces to the Java SIG. There's
the set of maintainers who maintain the soft underbelly of Java libraries.
That's mostly Mikolaj now. People like gil and others, while at one point
large Java package maintainers, have since moved on and their packages
have been orphaned through the unresponsive maintainer process. I think
the Eclipse team is part of that too. But it did seem rather uncoordinated,
from the outside, the whole ant+maven causing Eclipse to modularize dance.

But there's also the quiet maintainers of the JVM itself, who we're all
grateful for their quiet work. They've not tried to modularize as far
as I can tell. For all their hard work, we're thankful!


We, the Stewardship SIG, have said before that if you need packages
maintained that we're about to orphan, tell us! We'd keep them around
and do our best to update them. We try not to orphan everything we have,
we announce on the list and cc dependent package maintainers, and generally
try to be good stewards of the community. We had offered in the past,
on the list, to help Eclipse maintain whatever packages they needed to
stay ursine, but that offer went unanswered. And if your application is
major or critical to Fedora, like LibreOffice, Dogtag, or even Eclipse are,
we'd be consider taking on new packages and maintaining them too, if they
benefit the community.

However, without new members and more time on our hands, I'm not sure how
longer we'll be able to continue. Being brutally honest, Fabio does a LOT
of work. We need a long term solution that doesn't leave all our ursine
packages broken. Regardless of whether they're part of 

Re: What's the State of the Java SIG?

[Alex Scheel]

- Original Message -
> From: "Mikolaj Izdebski" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "java-devel" 
> Sent: Monday, November 18, 2019 5:42:20 AM
> Subject: Re: What's the State of the Java SIG?

~snip~

> Maintenance of obsolete packages is non-goal for Java SIG.

A number of packages -- which the Java SIG has dropped -- are still
under active development. The Apache Commons collection, JBoss packages,
glassfish/jakarata/... packages, plexus, &c. Sure, we have a few dead
packages. We've tried our best to drop many of these. And admittedly we're
still on the JavaEE packages pre-Eclipse donation (and rename to Jakarata).
But calling these large package collections maintained by three large,
active maintainer bases (Apache Foundation, Red Hat JBoss, and the Eclipse
Foundation) unmaintained seems... wrong?

~snip~

> > Or is it time for a "tabula rasa" and restart the SIG?
> >
> > I really hope we can get something off the ground, soon - because I
> > and other members of the Stewardship SIG have been spending a lot of
> > hours each week on keeping this stuff working, but my patience and
> > energy are reaching their limits. I'd really like to slowly start
> > handing over Java packages to someone who's actually using them, and
> > is interested in keeping them maintained.
> 
> IMHO effort spent on maintenance of most of these ursine Java packages
> is mostly wasted effort. As I said before, many times, these packages
> should be retired and replaced by modular packages, which are
> maintained by Java SIG members like me. maven and ant modules are
> already default streams, so users should get them instead of ursine
> packages. The last remaining step is enabling javapackages-tools in
> ursine buildroot so that ursine packages can be built with modular
> maven. Once that happens, there will be no reason to maintain ursine.
> Therefore, instead of putting time on updating ursine Maven et al.
> I recommend to put effort towards enabling modules in ursine buildroots.
> 
> > PS, side note about Modularity: If I understand the current state of
> > things correctly, the plan is to make the "maven:3.5" and "ant:1.10"
> > modular packages be installable alongside non-modular Java packages.
> > They're currently shadowing non-modular packages (since they have
> > default streams), but I understand this is getting fixed. This means
> 
> Shadowing of ursine packages by modular packages is not a defect.
> That is a feature of modularity. Therefore there is nothing to fix there.

I'm sorry Mikolaj, but I'm really confused reading this part of your mail.

A number of these packages exist as ursine packages precisely because
you've made them BUILDROOT-only! We, the Dogtag team, asked you to
reconsider that choice because we needed these as runtime dependencies,
not build-time only. You declined and said our choices were to maintain
our own modular forks or maintain the ursine variety. So, here we are.
And now, you're telling us to switch to modules? But that doesn't help
us access those BUILDROOT-only packages at runtime!


Could you help me understand how we're supposed to move forward?

- Alex
___
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: What are the benefits of default modular streams over non-modular packages?

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, November 15, 2019 10:58:04 AM
> Subject: Re: What are the benefits of default modular streams over 
> non-modular packages?
> 

~snipping long thread~

> Another issue is that the modular Java packages are now getting built
> with OpenJDK 11, while the non-modular default is still OpenJDK 8, and
> nobody is left to drive an OpenJDK 8 → 11 transition in fedora
> forward. We're basically the only holdout on Java 8 still, with even
> debian stable (!) defaulting to OpenJDK 11 now. This will probably
> lead to all kinds of fun incompatiblities between modular (Java 11)
> and non-modular (Java 8) packages. And I've not even mentioned the
> myriad of other, slightly incompatible changes between modular and
> non-modular Java packages ... *SIGH*

I think, assuming the proper -target / -release flags are used in
all modular packages, this will largely be a non-issue. Java does its
best to allow building packages with newer JDK versions while still
allowing older JREs to run the code. That's not the case if -target and
-release flags are missing. It also only really affects the consumers
of Java _libraries_ built with JDK11. Almost nobody will notice if Maven
was built with JDK 11. However this issue has been discussed elsewhere,
and we've determined that we'll be fine (TM):

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

I do agree that we will need to migrate to JDK 11, but that'll take
time. Perhaps we need Miro's fine management skills and strict policy
enforcement to get us there a la python2->python3 migration.

> > Perhaps this stuff is obvious to others already.  In RHEL8 while we have
> > certainly hit various problems with modularity at least I don't recall
> > my teams hitting major issues with default streams being available for
> > non-modular packages.
> 
> Maybe the dogtag-pki team can offer some opinions here? I know that
> they've had to deal with this on both RHEL and fedora.

Most of the RHCS team's perceived shortcomings of Modularity have come from
general issues, not ones stemming particularly from default streams. A
portion has probably been because we did this the wrong way and committed
to shipping it in RHEL before it was stabilized in Fedora. As has been
mentioned before on this list, we have some version of Ursa {Prime,Major}
in RHEL and we don't have large, conflicting efforts to maintain ursine build
trees in parallel to modular ones like Fedora has.

I've aired most of our opinions on this list in other threads. I don't think
it is worth reiterating here. But I will say we have much more leniency
when it comes to packaging there than we do here.

---

My personal opinion is that modules in Fedora are broken because of
politics and a lack of policy that exacerbates the technical problems.
Mostly that's because people are refusing to collaborate and work
together to solve problems, preferring to build their own silos. That'll
drive contributors away and vastly increase technical debt in the long run,
which we do really need to avoid to have a healthy community.


Default modular streams shadowing non-modular packages is one such
problem, especially when they ship libraries.


My 2c.

- Alex
___
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 and all the things

[Alex Scheel]

- Original Message -
> From: "Matthew Miller" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, November 11, 2019 1:16:22 PM
> Subject: Re: Modularity and all the things
> 
> On Tue, Nov 05, 2019 at 10:28:02PM +0100, Fabio Valentini wrote:
> > That's all well and good, but you seem to be forgetting that people
> > are actually getting *paid* to work on modularity for fedora.
> > Any proposal for an alternative, which apparently needs to arrive at
> > least at MVP / proof-of-concept quality before it is even *considered*
> > as an alternative without getting called "trolling", can likely only
> > be worked on in somebody's spare time. I don't think that's a fair
> > requirement, and "exploring and contributing" will stay limited to RH
> > employees if that's the case.
> 
> Well, it really depends on the circumstance. In general, it's just practical
> reality that a proof of concept or MVP will get you a lot further than a
> suggestion -- that's not, like, a Fedora law or something.
> 
> There are certainly many examples of awesome great stuff that's been created
> in Fedora without the investment of Red Hat (or anyone's) full time
> employees. The zchunk metadata feature is a recent example. The Stewardship
> SIG is another one. This is good stuff, and I'm super-happy to support it.
> In both of those cases the people interested in that thing happening put in
> exactly the kind of effort I'm talking about here.

Hi Matthew,


While we certainly aren't numerous, Dinesh (fas: dmoluguw) and myself
(fas: cipherboy) contribute to the Stewardship SIG. Miro (fas: churchyard)
also contributes a lot. And if the load got worse, I'm sure Endi
(fas: edewata) would be willing to help.

From my organization at least, we have PM and management buy-in to
continue contributing so long as we don't have a long-term solution
that somebody else manages for us. So far, ursine packages have been
our solution and we've helped with maintaining the stack as community
members and giving back. That benefits all of Fedora.

I think we've accomplished something useful with the Stewardship SIG.


So sure, we don't work only on the Stewardship SIG... But three paid
Red Hat employees contributing in official capacities (as we have time)
should, IMO, count for something. :-)

- Alex

> 
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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: Will orphan packages with NEW F31FTBFS bugs tomorrow

[Alex Scheel]

- Original Message -
> From: "Vitaly Zaitsev via devel" 
> To: devel@lists.fedoraproject.org
> Cc: "Vitaly Zaitsev" 
> Sent: Friday, November 8, 2019 10:04:57 AM
> Subject: Re: Will orphan packages with NEW F31FTBFS bugs tomorrow
> 
> On 08.11.2019 13:16, Miro Hrončok wrote:
> 

~snip~

> > kf5-kactivities
> > kf5-kactivities-stats
> > kf5-kio
> 
> KF5 is not a FTBFS. Please check your scripts next time.

Just pulling a few random bugs:

- kf5-kactivities: https://bugzilla.redhat.com/show_bug.cgi?id=1735931
  needs to be closed: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=18750

- kf5-kactivities-stats: https://bugzilla.redhat.com/show_bug.cgi?id=1735932
  needs to be closed: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=22330

- kf5-kio: https://bugzilla.redhat.com/show_bug.cgi?id=1735947
  needs to be closed: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=18722

Not going to check the rest of the components, but I think Miro's
scripts work fine. It is the bugs that are out of date... ...and
if they're out of date, not much Miro's scripts can do.


Would you mind closing some of the bugs as fixed, please? :)

- Alex

> 
> --
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.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
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: The Official Complaint Thread

[Alex Scheel]

- Original Message -
> From: "Ralf Corsepius" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, November 6, 2019 3:32:03 AM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> On 11/5/19 9:41 PM, Alex Scheel wrote:
> 
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
> 
> And? Why should Fedora care about RHEL?

Why? Because Modularity was foisted the wrong direction.

In an ideal world, Modularity would've been proposed to Fedora,
it would've been discussed by the community, improved, perfected,
and _then_ brought into the RHEL fold only when stable! Fedora
would've _driven_ the innovation, rather than having to keep up
with whatever RHEL decided to do, being careful not to break
anything.

We don't live in an ideal world and deadlines, initial rejection
by Fedora, and issues implementing Modularity forced at least _some_
of it to go the other direction, RHEL -> Fedora.

So now we're stuck trying to improve Modularity in Fedora, without
stepping on any RHEL toes, and knowing full well that if the
community rejects Modularity in Fedora (again!), we're stuck supporting
it in RHEL through RHEL 8 (and, likely into RHEL 9). And I think that
worries some people, hence the attempt to influence discussions, name
calling, &c. Others however, want Fedora to remain fully independent
of RHEL, and thus have asked that _failure_ be an option explicitly
on the table. 

I don't work on Modularity though. I only have to use it. I'm, at
best, agnostic as to whether or not it survives in Fedora. But, I
do have to use it in RHEL. There, I'd far rather see it improve
(and, have a chance to influence improvements to issues I've directly
hit NOW rather than later). I'd hate to see it stagnate in its
current state.



> I for one consider RHEL not to be its partner, but it to be an
> initiative to gradually push Fedora out of this planet.

I think that's going a little far. They cater to two different
audiences: hackers or business people. The former will put up with
cutting-edge software and whatever documentation is freely available.
The latter will pay big money for support and consulting to make
sure nothing breaks, and to fix it if it does. 

I'd argue that if RHEL wanted to push anyone out, Fedora would be
a stupid target. RHEL doesn't really compete with Fedora. Target CentOS
first! Its RHEL, but free!

But we don't. Red Hat stepped _up_ its participation in CentOS. We
pay people to work on CentOS full-time, so it keeps going. I think
that's the _opposite_ of trying to push CentOS out of this planet.
Same goes for Fedora. And with RHEL 9, we've announced that we view
Fedora as the _upstream_ for RHEL. More collaboration, not less!

https://fedoramagazine.org/fedora-and-centos-stream/


I'd ask you to consider that we aren't Microsoft of the '90s... We
are human and make mistakes from time to time, but we aren't evil.
We're an Open Source company, and try our best to embody that. We
try our best to work _with_ the community, not against it. That's
why all of these modularity discussions _have_ been in the open and
happening right here, in Fedora. Not on some private mailing list
inside Red Hat. 


At any rate, Pierre's points are also valid.

- Alex

> 
> Ralf
> ___
> 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: Modularity: The Official Complaint Thread

[Alex Scheel]

- Original Message -
> From: "Kevin Kofler" 
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, November 5, 2019 7:48:47 PM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> Alex Scheel wrote:
> > Special care needs to be taken to make sure we discuss what happens
> > when a _module maintainer_ wants to switch the module stream of one
> > of its dependencies, especially a dependency the user never
> > specifically selected a stream for. That should be an allowed and fully
> > supported use case.
> > 
> > This was the pki-core<->idm module fiasco that was never resolved by
> > DNF/Modularity.
> > 
> > I'd post the bug number but the bug isn't public.
> > 
> > 
> > So perhaps split this into:
> > 
> >  1. How does a _user_ change module streams during upgrade?
> >  2. How does the _maintainer_ change module streams of a dependent
> > module? (module a -dep-> module b -- change stream of b from 1 to 2)
> > 
> > 
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
> 
> Indeed, in Fedora, it is quite plausible for a package to be ported to a new
> major version of a library in an update. (In RHEL, it actually also is, but
> for different reasons, i.e., its extremely long lifetime.)
> 
> But this shows how modules are the wrong answer for non-leaf packages. What
> happens if one of the packages you had installed wants to bump the module
> stream of its dependency and another one doesn't? Then suddenly, your system
> cannot be updated anymore, because the packages that previously coexisted
> just fine now irremediably conflict.
> 
> (In fact, this is just a particularly nasty special case of the more general
> design flaw of Modularity that Stephen Gallagher has unfortunately forgotten
> in his list in the original post, the version conflicts caused by versioned
> dependencies without parallel installability. The special case is that the
> conflicts can also be introduced on updates to previously non-conflicting
> packages.)
> 
> Providing incompatible versions of non-leaf packages MUST be done in a
> parallel-installable way. There is no other way out.

Since this is all public, for the rest of the audience:

 - There are three modules in question here, in core RHEL:

   1. pki-deps, an artifact of the original, broken attempt at Modularity
  in RHEL, when builds would take eons. This contains a bunch of
  dependencies of Dogtag. 
   2. pki-core, the core packages of Dogtag:
  - JSS
  - Tomcatjss
  - ldap-jdk
  - Dogtag PKI
   3. The IPA module and its "DL1" stream.

   You can pull these three modules today on RHEL and try them out if
   you want. 

 - The dependency tree is thus: 

IPA:DL1 -> pki-core:10.6 -> pki-deps:10.6

 - What we had wished to do was provide two sets of module streams:

pki-core @ 10.6 -- Dogtag at 10.6 version (in RHEL 8.0 only)
pki-core @ 10.7 -- Dogtag at 10.7 version (in RHEL 8.1 only).

   Anyone who was using pki-core by itself could stay on 10.6 if they
   so desired (by staying on RHEL 8.0) or upgrade to 10.7 (by upgrading
   to RHEL 8.1). This allowed us, in the future, to support multiple
   versions on the same RHEL version if there were breaking changes
   between them. 

   Since IPA is a monolith and wanted features in 10.7, it was going to
   switch to 10.7 in the new RHEL 8.1 release (out today!) because it
   wanted some things we introduced there.

 - Instead, since switching branches as described above wasn't supported,
   we ended up shipping our 10.7 version release in the (now incorrectly
   named) 10.6 branch. This means, on the whole, the pki-core module isn't
   netting us any value. It functions just like an ursine collection of
   packages with only a single version stream available.


So to answer your question:

> What happens if one of the packages you had installed wants to bump the
> module stream of its dependency and another one doesn't?

This was RHEL. We (the Dogtag / RHCS team at Red Hat) had full control
over our package. We could choose to ship whatever version we want. That
meant that we have to _work_ with other teams (in this case, exactly one:
IPA) and ensure what we wanted to ship wouldn't break anything. Part of
that was making sure we can switch streams. It turns out that, while we
wanted to and got sign-off from IPA, the issue was a fundamental limitation
in DNF. In RHEL, we know there is only one such dependent, IPA, and we can
deal with that.

In short, inside RHEL, we can take this as risk and control for it. In
Fedora, it is harder and would require (packaging/FESCO/Modularity/...)
policy to enforce. But it really _isn't_ a hard thing to do: limit it to
Rawhide, require changes t

Re: Modularity: The Official Complaint Thread

[Alex Scheel]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, November 5, 2019 3:17:28 PM
> Subject: Modularity: The Official Complaint Thread

~snip~

> 1. Once enabled, a module stream is never changed on behalf of the
> user. While this adds some strong guarantees to those who want to run
> applications built from those streams, the presence of default streams
> changes the expected upgrade behavior for users. Traditionally, at
> upgrade a user would get the new release's most-updated version of all
> packages currently on their system. With Modularity, if one of their
> packages comes from a default stream and that stream is not the
> default for the next release, they will stay on the current stream (or
> be blocked from upgrading, if the current stream is unavailable on the
> next release). [2]

Special care needs to be taken to make sure we discuss what happens
when a _module maintainer_ wants to switch the module stream of one
of its dependencies, especially a dependency the user never
specifically selected a stream for. That should be an allowed and fully
supported use case.

This was the pki-core<->idm module fiasco that was never resolved by
DNF/Modularity.

I'd post the bug number but the bug isn't public.


So perhaps split this into: 

 1. How does a _user_ change module streams during upgrade?
 2. How does the _maintainer_ change module streams of a dependent
module? (module a -dep-> module b -- change stream of b from 1 to 2)


IMO, without a resolution in Fedora we'll never get one in RHEL.

- Alex
___
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: Java Package Orphanings

[Alex Scheel]

The deed has been done. 

- A

- Original Message -
> From: "Alex Scheel" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, October 30, 2019 9:21:35 AM
> Subject: Java Package Orphanings
> 
> All,
> 
> In the process of unorphaning resteasy, I picked up several other
> packages necessary to keep it alive. After trimming resteasy
> down, I was left with the following packages.
> 
>  - classmate (cc: lef)
>  - cli-parser (cc: lef)
>  - glassfish-gmbal
>  - glassfish-management-api
>  - glassifsh-pfl
>  - grizzly
>  - grizzly-npn
>  - jackson-dataformat-xml (cc: lef, dchen)
>  - jandex-maven-plugin (cc: lef)
>  - java-oauth (cc: lef)
>  - jboss-connector-1.6-api (cc: lef, gil)
>  - jboss-jaspi-1.1-api (cc: lef)
>  - jersey (cc: dchen, gwei3)
>  - mimepull (cc: lef, java-sig)
>  - mustache-java (cc: dchen, lef, mizdebsk)
>  - netty3 (cc: lef, jerboaa)
>  - picketbox (cc: lef, gil)
>  - picketbox-commons (cc: lef, gil)
>  - picketbox-xacml (cc: lef, gil)
>  - rxjava (cc: rfenkhuber)
>  - simple
> 
> I intend to orphan them all on Friday unless someone else
> wants these packages.
> 
> 
> Thanks,
> 
> - Alex
> ___
> 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

Java Package Orphanings

[Alex Scheel]

All,

In the process of unorphaning resteasy, I picked up several other
packages necessary to keep it alive. After trimming resteasy
down, I was left with the following packages.

 - classmate (cc: lef)
 - cli-parser (cc: lef)
 - glassfish-gmbal
 - glassfish-management-api
 - glassifsh-pfl 
 - grizzly 
 - grizzly-npn
 - jackson-dataformat-xml (cc: lef, dchen)
 - jandex-maven-plugin (cc: lef)
 - java-oauth (cc: lef)
 - jboss-connector-1.6-api (cc: lef, gil)
 - jboss-jaspi-1.1-api (cc: lef)
 - jersey (cc: dchen, gwei3)
 - mimepull (cc: lef, java-sig)
 - mustache-java (cc: dchen, lef, mizdebsk)
 - netty3 (cc: lef, jerboaa)
 - picketbox (cc: lef, gil)
 - picketbox-commons (cc: lef, gil)
 - picketbox-xacml (cc: lef, gil)
 - rxjava (cc: rfenkhuber)
 - simple

I intend to orphan them all on Friday unless someone else
wants these packages.


Thanks,

- Alex
___
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: Switching Maven and Ant to OpenJDK 11

[Alex Scheel]

- Original Message -
> From: "Mikolaj Izdebski" 
> To: "java-devel" 
> Cc: maven-ow...@fedoraproject.org, "ant-owner" , 
> mbo...@fedoraproject.org
> Sent: Friday, October 25, 2019 1:30:32 PM
> Subject: Switching Maven and Ant to OpenJDK 11
> 
> Hello,
> 
> Currently default Java runtime in Fedora is OpenJDK 8. This is not the
> latest OpenJDK packaged, but still remains system-default version.
> Because of that Apache Maven and Apache Ant in Fedora are built using
> OpenJDK 8 and run on OpenJDK 8.
> 
> I am planning to switch Maven 3.6 and Ant 1.10 modules to build with
> and run on OpenJDK 11, which is the latest LTS release of OpenJDK.
> This also means that future streams of javapackages-tools module will
> default to use OpenJDK 11 for building packages. Please let me know if
> you have any concerns.

My concern is what will happen to the libraries in the default module
stream? When installing, e.g., dogtag-pki, this brings in the following
packages from a default module stream:

apache-commons-cli-0:1.4-4.module_f28+3939+dc18cd75.noarch
apache-commons-codec-0:1.11-3.module_f28+3939+dc18cd75.noarch
apache-commons-io-1:2.6-3.module_f28+3939+dc18cd75.noarch
apache-commons-logging-0:1.2-13.module_f28+3939+dc18cd75.noarch
httpcomponents-client-0:4.5.5-4.module_f28+3939+dc18cd75.noarch
httpcomponents-core-0:4.4.10-3.module_f28+3939+dc18cd75.noarch

Of these, apache-commons-{cli,codec,io,logging} are all directly required
by dogtag-pki, which doesn't yet fully work with JDK-11. (I'm not quite
sure how httpcomponents-{client,core} gets pulled in).


Will you continue building these with a target bytecode version for use
with JDK8, even though you're building with JDK11? Or are you only building
the maven and ant packages with JDK 11 (and not building all libraries
in the module with JDK 11)?


Thanks,

- Alex 


> 
> --
> Mikolaj Izdebski
> 
> 
___
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: Unretire recordmydesktop

[Alex Thomas]

On Thu, Nov 8, 2018 at 10:40 AM Richard W.M. Jones 
wrote:

> On Thu, Nov 08, 2018 at 12:59:40PM +0100, Felipe Borges wrote:
> > On Tue, Nov 6, 2018 at 8:19 PM Samuel Sieb  wrote:
> > >
> > > On 11/6/18 6:21 AM, Jiri Eischmann wrote:
> > > > Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800:
> > > >> On 11/5/18 12:47 PM, Adam Williamson wrote:
> > > >>> On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote:
> > >  I don't know about the other bugs, but not working on Wayland
> > >  can't be
> > >  held against it.  Nothing works to record the desktop on Wayland
> > >  since
> > >  that isn't supported yet.
> > > >>>
> > > >>> GNOME's inbuilt screen recorder does it fine.
> > > >>
> > > >> Does that use a Gnome shell-specific API or does Wayland have
> > > >> support
> > > >> for that now?
> > > >
> > > > You can either use Mutter API (several utilities can do that, not
> only
> > > > the built-in tool) or newly PipeWire. Works both on Wayland and Xorg.
> > > > Screen recording (or more precisely providing apps with screen
> frames)
> > > > is not something Wayland as a protocol covers and plans to cover.
> > >
> > > Then it's time to port vino to PipeWire, so I don't have to disable
> > > Wayland on all the systems I install.
> >
> > See https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
>
> >When is Wayland going to get X11-style >remote applications support?
>
> >Rich.
>

When someone big tells RH that RHEL 8 w/ wayland is a non starter until
that is fixed. Same way that you finally got local plain text logs under
systemd.

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

Re: Attention Gmail users, please turn off HTML mail

[Alex Thomas]

On Thu, Oct 4, 2018 at 4:33 PM Matthew Miller  wrote:
>
> The fact is, the world has moved away from quoted mail with inline replies.
> Top posting rules basically everywhere except hold-out old-school mailing
> lists. Gmail, both on the web and _especially_ on mobile, makes it almost
> impossible to do quoting and inline replies properly. I can't imagine other
> big consumer email providers are much better.
>
> Yes, this sucks for having nuanced point-by-point discussions. But I don't
> think that's a tide we're really going to hold back. We should look at other
> tools that fit with the way people do asynchronous online discussion today.
> As Brian noted, we're trying out Discourse at 
> https://discussion.fedoraproject.org/
> —  if you're interested in trying it out, come join the conversation there.
>
> Matthew Miller
> 
> Fedora Project Leader
Please no. No more Discourse. Having already stopped keeping up with
one major project (Chef.io) because of that switch.Far easier to live
with how broken gmail is and possibly just stripping out html content,
then trying force web forum software into being useful.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Any idea what is going on with Epson's printer driver (escpr vs escpr2)?

[Alex G.]

Hi,

Epson distributes two drivers for its printers, espcr, and espcr2. espcr 
is happily packaged in Fedora, however, newer printers seem to become 
supported in espcr2.


The problem with espcr2 is that it is missing source code for an 
internal library -- escprlib. escprlib is distributed as static library 
with i386 and amd64 targets. espcr does provide the source code for this 
library. My escpr2 ET-3700 works just fine with the escpr packaged in 
Fedora after some minor PPD changes.


I wanted to know what the difference is and why we have a proprietary 
escpr2, when escpr works just fine. It's obvious that escpr2 is a dumb 
java-like hack-and-slash fork of escpr, but I wanted to know if it's a 
silly mistake, or a deliberate attempt by Epson to hide something.


Thanks to 'git diff -w', the biggest difference is the addition of an 
"RHV2" compression mode, and the infrastructure around it. There's even 
a 2015 patent on RHV2 [1]. From my analysis, it seems that whoever 
implemented this did it in a matter very consistent with the style and 
conventions of escpr. I think this person had prior experience with 
escpr, and I think it's unlikely that the addition of a binary-only 
component is a mistake.


If Epson does indeed want to keep proprietary parts of its (userspace) 
driver, where does that leave Linux users, and Fedora? Do we keep 
ripping PPDs off of escpr2 and hope they work with the open source 
driver? At this point, I expect all escpr2 PPDs to work, but what 
happens when Epson makes new protocol additions that they wish not to 
disclose?


What is the future of using an Epson printer with Linux, and Fedora?

Alex

[1] https://www.google.com/patents/US9110613
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review Swap

[Alex Roithman]

I take review as swap:
https://bugzilla.redhat.com/show_bug.cgi?id=1397089

On 6 December 2016 at 19:18, Greg Hellings  wrote:

> I'm looking to get a review on this package:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1393947
>
> I'm willing to swap with someone if needed.
>
> --Greg
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 System Wide Change: KillUserProcesses=yes by default

[Alex Thomas]

 +1 to the idea that we really do not know how many programs will be
affected by this change. We do know that the tmux folks have shot down
making any changes to accommodate systemd. As they value cross-platform
compatibility, this is understandable.

 As it looks from my vantage point, the choice is either carry a patch
to revert this change in systemd, or accept the load of carrying an unknown
number of patches to allow other software to accommodate this change.

 My suggestion is to plan on reverting the systemd change to
KillUserProcess=no in F25, and reevaluate for F26, when we have a better
understanding of just how many programs have to be rewritten/patched/forked
to accommodate this new paradigm.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please stop modifying other people's packages without coordinating with them first

[Alex Gagniuc]

On Sat, Feb 13, 2016 at 9:57 AM, Till Maas  wrote:
> Hi Alex,

Hi Till,

> the changes were not unrelated but fixed the build error for pulseview
> on Rawhide and extending the build overrides fixed the build errors on
> F23 (which you can also read in the changelog).

I noticed the changes were zero-day patches. I have added instructions
on how to obtain those patches:

# Zero-day patches after 0.3.0 release. Extract using:
# $ git clone git://sigrok.org/pulseview.git
# $ cd pulseview
# $ git checkout a1a3656b4e18cb9fc078a51bf4256066ee307620
# $ git format-patch pulseview-0.3.0

It's important to have such instructions so that the origin of the
patches can be verified.


>> You've done that without  any attempt at contacting me. There are
>
> This is not true, since I tried to contact you via IRC.

yes, I have an IRC bouncer server, so I was able to find your question
after some grepping. It was posted before dawn in my timezone, so I
wouldn't have had a chance to respond anyhow.

> If you think that is the best way forward, please do it. But please make
> sure that you also restore compliance to the packaging guidelines by
> starting the release with 1 and using the %license macro.

I have restored your changes, with the appropriate modifications.
You're still listed as the author in git, as you're the one who
figured it out. Thanks for that.

> Also pushing
> dependent builds in separate updates is against best practices as this
> will lead to broken updates.

I haven't been able to stay up-to date with the latest and greatest
guidelines in the past several years due to jobs, military training,
etc, though I'm always looking for hints on how to improve the process
of pushing out these updates.

Alex
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Please stop modifying other people's packages without coordinating with them first

[Alex Gagniuc]

I was in the process of upgrading to the latest upstream releases,
which came out about a week ago. You've interrupted the process by
pushing some unrelated changes, and now I have to figure out what
happened.

You've done that without  any attempt at contacting me. There are
other persons who helped considerably with these packages, such as
Dan, and every time, they coordinated with me before stepping on my
toes.

I've considered what to do next in order to complete upgrading to the
shiniest upstream release. I've decided that I will revert your
changes, and continue the process where I left it off.

Alex
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intent to orphan shorewall

[Alex Bruneau]

I am new to package maintaining, but Alteeve's Niche uses Shorewall in one of 
our offerings, and I'd be happy to take it on. Our tech lead is available to 
assist as well. Thank you for all of your work on the package!

--
Alex Bruneau
Technician, Alteeve's Niche! Inc.
145 Front St East, Toronto, Canada
abrun...@alteeve.ca
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Kernel 4.2.3-200 stability problems and mouse cursor defects...

[Alex G.S.]

Well, I decided to take the plunge and upgrade to Fedora 23 Workstation, so
I no longer have access to that version. Also on Fedora 23 I don't see that
particular kernel bug.  Everything seems to work great, I'll file any bugs
if I see them.

Thank you!

On Mon, Oct 19, 2015 at 11:22 AM, Alex G.S.  wrote:

> Fedora Devel,
>
> Just wanted to get more information on a bug that bit me over the
> weekend.  Running Fedora 22 and updated to 'kernel.x86_64 4.2.3-200.fc22'.
> There's no mouse cursor on the login screen at all.  When logging in either
> on X11 or the Wayland session I repeatedly get Kernel Oops messages and the
> mouse cursors jumps about and appears jittery or to make duplicated copies
> of itself on screen.  Using Fedora is very difficult and things don't
> appear stable or normal I get a message like this in the backtrace:
>
>  [] dump_stack+0x45/0x57
>  [] warn_slowpath_common+0x86/0xc0
>  [] warn_slowpath_fmt+0x55/0x70
>  [] i915_gem_track_fb+0x129/0x140 [i915]
>  [] intel_prepare_plane_fb+0xe7/0x1a0 [i915]
>  [] drm_atomic_helper_prepare_planes+0x59/0xe0
> [drm_kms_helper]
>  [] __intel_set_mode+0x1ae/0xb60 [i915]
>  [] ? intel_modeset_compute_config+0x3af/0xb60 [i915]
>  [] intel_crtc_set_config+0x2b6/0x580 [i915]
>  [] drm_mode_set_config_internal+0x66/0x100 [drm]
>  [] drm_mode_setcrtc+0x3e9/0x500 [drm]
>  [] drm_ioctl+0x125/0x610 [drm]
>  [] ? avc_compute_av+0x15d/0x190
>  [] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
>  [] do_vfs_ioctl+0x295/0x470
>  [] ? selinux_file_ioctl+0x4d/0xc0
>  [] SyS_ioctl+0x79/0x90
>  [] entry_SYSCALL_64_fastpath+0x12/0x71
>
> This appears similar to bugs:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1241197
> https://bugzilla.redhat.com/show_bug.cgi?id=1254248
>
> Do you have further information on this?
>
> Also I am unable to log-in to Buzilla to further report this problem and
> have sent several reset password requests but no reset link has been sent
> to me.
>
> Thank you!
>
> Best,
> Alex G.S.
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Kernel 4.2.3-200 stability problems and mouse cursor defects...

[Alex G.S.]

Fedora Devel,

Just wanted to get more information on a bug that bit me over the weekend.
Running Fedora 22 and updated to 'kernel.x86_64 4.2.3-200.fc22'.  There's
no mouse cursor on the login screen at all.  When logging in either on X11
or the Wayland session I repeatedly get Kernel Oops messages and the mouse
cursors jumps about and appears jittery or to make duplicated copies of
itself on screen.  Using Fedora is very difficult and things don't appear
stable or normal I get a message like this in the backtrace:

 [] dump_stack+0x45/0x57
 [] warn_slowpath_common+0x86/0xc0
 [] warn_slowpath_fmt+0x55/0x70
 [] i915_gem_track_fb+0x129/0x140 [i915]
 [] intel_prepare_plane_fb+0xe7/0x1a0 [i915]
 [] drm_atomic_helper_prepare_planes+0x59/0xe0
[drm_kms_helper]
 [] __intel_set_mode+0x1ae/0xb60 [i915]
 [] ? intel_modeset_compute_config+0x3af/0xb60 [i915]
 [] intel_crtc_set_config+0x2b6/0x580 [i915]
 [] drm_mode_set_config_internal+0x66/0x100 [drm]
 [] drm_mode_setcrtc+0x3e9/0x500 [drm]
 [] drm_ioctl+0x125/0x610 [drm]
 [] ? avc_compute_av+0x15d/0x190
 [] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
 [] do_vfs_ioctl+0x295/0x470
 [] ? selinux_file_ioctl+0x4d/0xc0
 [] SyS_ioctl+0x79/0x90
 [] entry_SYSCALL_64_fastpath+0x12/0x71

This appears similar to bugs:

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

Do you have further information on this?

Also I am unable to log-in to Buzilla to further report this problem and
have sent several reset password requests but no reset link has been sent
to me.

Thank you!

Best,
Alex G.S.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: New contributor looking for Python projects/packages...

[Alex G.S.]

Hi All,

Thank you for the responses and the suggestions.  The Python SIG looks
awesome.  I'll definitely be looking into these.

Thanks!

Best,
Alexander GS



On Wed, Jun 10, 2015 at 8:13 AM, Stephen Gallagher 
wrote:

> On Tue, 2015-06-09 at 17:38 -0400, Alex G.S. wrote:
> > Devel,
> >
> > Fedora is my favorite Linux distribution by a wide margin and I
> > currently enjoy Workstation on both my work (devops) and home
> > computer.  I've started working with Python and I want to contribute
> > back to Fedora by taking on small tasks where needed.  Can you
> > suggest a list of Python based/oriented components or packages that
> > really need developers/maintainers and aren't too overwhelming or
> > complex for a first-time contributor?  Also is there a person you
> > suggest I reach out to as a point of contact for new contributors?
> >
> > Thank you!
> >
> > Best,
> > Alexander GS
> >
>
> The rolekit project[1] is a Python project and a key component of the
> Fedora Server deliverables. We're just starting on our F23 efforts. If
> you're interested in participating, come by #fedora-server on Freenode
> IRC.
>
> [1] https://sgallagh.wordpress.com/2014/12/11/rolekit-or-how-i-learned
> -to-stop-thinking-in-terms-of-packages/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New contributor looking for Python projects/packages...

[Alex G.S.]

Devel,

Fedora is my favorite Linux distribution by a wide margin and I currently
enjoy Workstation on both my work (devops) and home computer.  I've started
working with Python and I want to contribute back to Fedora by taking on
small tasks where needed.  Can you suggest a list of Python based/oriented
components or packages that really need developers/maintainers and aren't
too overwhelming or complex for a first-time contributor?  Also is there a
person you suggest I reach out to as a point of contact for new
contributors?

Thank you!

Best,
Alexander GS
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Intel driver pain

[Alex G.S.]

>
> On Fri, May 29, 2015 at 12:13 PM, Sergio Belkin  > wrote:
> >* Hi, *>
> >* Could you tell me if anyone else is having this kind of issues: *>
> >* [vie may 29 07:01:22 2015] [drm] Initialized drm 1.1.0 20060810 *>* [vie
> may 29 07:01:22 2015] [drm] Memory usable by graphics device = 2048M *>* [vie
> may 29 07:01:22 2015] fb: switching to inteldrmfb from EFI VGA *>* [vie
> may 29 07:01:22 2015] [drm] Replacing VGA console driver *>* [vie may 29
> 07:01:22 2015] [drm] Supports vblank timestamp caching Rev 2 *>
> * (21.10.2013). *>* [vie may 29 07:01:22 2015] [drm] Driver supports
> precise vblank timestamp *>* query. *>* [vie may 29 07:01:22 2015] [drm]
> Initialized i915 1.6.0 20150130 for *>* :00:02.0 on minor 0 *>*[vie
> may 29 07:01:22 2015] fbcon: inteldrmfb (fb0) is primary device *>* [vie
> may 29 07:01:22 2015] [drm:intel_set_pch_fifo_underrun_reporting *>* [i915]]
> *ERROR* uncleared pch fifo underrun on pch transcoder A *>* [vie may 29
> 07:01:22 2015] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *>* *ERROR*
> PCH transcoder A FIFO underrun *>* [vie may 29 07:01:23 2015] i915
> :00:02.0: fb0: inteldrmfb frame buffer *>* device *What exactly is
> your problem? What are the symptoms? Also bugzilla is
> a better place for those kind of things.


Interestingly I also see this error and usually it tends to be associated
with GNOME instability and lockups or crashes.  There's a thread about
this, specifically in reference to Intel Haswell.  I get crashes and
lockups occasionally and when this happens that error message scrolls
several times.

https://bugzilla.redhat.com/show_bug.cgi?id=1188772
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[no subject]

[Alex G.S.]

>
> On Fri, May 29, 2015 at 12:13 PM, Sergio Belkin  > wrote:
> >* Hi, *>
> >* Could you tell me if anyone else is having this kind of issues: *>
> >* [vie may 29 07:01:22 2015] [drm] Initialized drm 1.1.0 20060810 *>*
> [vie may 29 07:01:22 2015] [drm] Memory usable by graphics device = 2048M *
> >* [vie may 29 07:01:22 2015] fb: switching to inteldrmfb from EFI VGA *>*
> [vie may 29 07:01:22 2015] [drm] Replacing VGA console driver *>* [vie
> may 29 07:01:22 2015] [drm] Supports vblank timestamp caching Rev 2 *>*
> (21.10.2013). *>* [vie may 29 07:01:22 2015] [drm] Driver supports
> precise vblank timestamp *>* query. *>* [vie may 29 07:01:22 2015] [drm]
> Initialized i915 1.6.0 20150130 for *>* :00:02.0 on minor 0 *>* [vie
> may 29 07:01:22 2015] fbcon: inteldrmfb (fb0) is primary device *>* [vie
> may 29 07:01:22 2015] [drm:intel_set_pch_fifo_underrun_reporting *>*
> [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A *>* [vie
> may 29 07:01:22 2015] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *>*
> *ERROR* PCH transcoder A FIFO underrun *>* [vie may 29 07:01:23 2015]
> i915 :00:02.0: fb0: inteldrmfb frame buffer *>* device * What exactly
> is your problem? What are the symptoms? Also bugzilla is
> a better place for those kind of things.


Interestingly I also see this error and usually it tends to be associated
with GNOME instability and lockups or crashes.  There's a thread about
this, specifically in reference to Intel Haswell.  I get crashes and
lockups occasionally and when this happens that error message scrolls
several times.

https://bugzilla.redhat.com/show_bug.cgi?id=1188772
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Alex Kashchenko

[Alex Kashchenko]

Hi Fedora developers,

My name is Alex Kashchenko (Kasko), I just created my first review 
request - https://bugzilla.redhat.com/show_bug.cgi?id=1213065 . It is a 
small vi-like binary editor, I used it previously in Debian and found it 
convenient for small binary changes. I contacted the upstream developer 
(shared patch) and he supported the idea.


About myself: I am a member of Java team at Red Hat (user: akashche). My 
past experience in free and open source projects includes a number of 
projects on GitHub - https://github.com/alexkasko and number of minor 
contributions to OpenJDK6 project - http://openjdk.java.net/census#akasko


Thanks.

--
-Alex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[EPEL-devel] duplicity

[Alex Domoradov]

Hello,

I have encountered with bug in duplicity-0.6.22 -
https://answers.launchpad.net/duplicity/+question/264557 which I have
installed from EPEL repository on CentOS 6.

Is it possible upgrade duplicity at least to 0.6.25?

P.S.
As you can see from the  thread above - there is conflict with librsync-1.0
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: F21 System Wide Change: Wayland

[alex diavatis]

> This is in a sub package now you have to install
gnome-session-wayland-session

Thanks!


On Sat, May 3, 2014 at 5:41 PM, drago01  wrote:

> On Sat, May 3, 2014 at 4:29 PM, alex diavatis 
> wrote:
> > drago01,
> >
> > After upgrading Rawhide today, the Wayland session
> > (/usr/share/wayland-sessions) vanished.
> > How do you start Gnome On Wayland on Rawhide?
>
> This is in a sub package now you have to install
> gnome-session-wayland-session
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[alex diavatis]

>After upgrading Rawhide today, the Wayland session
(/usr/share/wayland-sessions) vanished.
>How do you start Gnome On Wayland on Rawhide?

I know how to start a Gnome Wayland session, but I mean why isn't on GDM by
default.


On Sat, May 3, 2014 at 5:29 PM, alex diavatis wrote:

> drago01,
>
> After upgrading Rawhide today, the Wayland session
> (/usr/share/wayland-sessions) vanished.
> How do you start Gnome On Wayland on Rawhide?
>
>
> On Sat, May 3, 2014 at 5:01 PM, drago01  wrote:
>
>> On Sat, May 3, 2014 at 3:57 PM, Reindl Harald 
>> wrote:
>> >
>> >
>> > Am 03.05.2014 15:51, schrieb Rahul Sundaram:
>> >> On Sat, May 3, 2014 at 9:27 AM, alex diavatis wrote:
>> >>
>> >> From Fedora Docs (https://fedoraproject.org/wiki/Changes/Wayland)
>> >>
>> >> >To avoid destabilizing the X compositor, mutter will ship two
>> separate libraries, and gnome-shell will ship two binaries that will link
>> against them. Concretely, we plan to have a separate mutter-wayland package.
>> >>
>> >> Mutter-Wayland in GNOME 3.13.1 is merged to Mutter, so how can
>> have 2 different packages?
>> >>
>> >> Because Fedora 21 branch has GNOME 3.12
>> >
>> > says who? [...]
>>
>> The whole confusion is because the feature was initially written for
>> 3.12 but then the whole .next thing happened.
>> In short the text needs to be updated.
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
>
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[alex diavatis]

drago01,

After upgrading Rawhide today, the Wayland session
(/usr/share/wayland-sessions) vanished.
How do you start Gnome On Wayland on Rawhide?


On Sat, May 3, 2014 at 5:01 PM, drago01  wrote:

> On Sat, May 3, 2014 at 3:57 PM, Reindl Harald 
> wrote:
> >
> >
> > Am 03.05.2014 15:51, schrieb Rahul Sundaram:
> >> On Sat, May 3, 2014 at 9:27 AM, alex diavatis wrote:
> >>
> >> From Fedora Docs (https://fedoraproject.org/wiki/Changes/Wayland)
> >>
> >> >To avoid destabilizing the X compositor, mutter will ship two
> separate libraries, and gnome-shell will ship two binaries that will link
> against them. Concretely, we plan to have a separate mutter-wayland package.
> >>
> >> Mutter-Wayland in GNOME 3.13.1 is merged to Mutter, so how can have
> 2 different packages?
> >>
> >> Because Fedora 21 branch has GNOME 3.12
> >
> > says who? [...]
>
> The whole confusion is because the feature was initially written for
> 3.12 but then the whole .next thing happened.
> In short the text needs to be updated.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[alex diavatis]

>From Fedora Docs (https://fedoraproject.org/wiki/Changes/Wayland)

>To avoid destabilizing the X compositor, mutter will ship two separate
libraries, and gnome-shell will ship two binaries that will link against
them. Concretely, we plan to have a separate mutter-wayland package.

Mutter-Wayland in GNOME 3.13.1 is merged to Mutter, so how can have 2
different packages?


On Wed, Apr 30, 2014 at 6:23 PM, Thorsten Leemhuis wrote:

> Hi!
>
> Jaroslav Reznik wrote on 30.04.2014 16:27:
> > - Original Message -
> >> Jaroslav Reznik wrote on 29.04.2014 14:04:
> >> > Port the GNOME desktop to Wayland.
> >>
> >> Sorry, but what is actually proposed here? The above sentence for me
> >> doesn't make any sense(¹), as Gnome 3.12 is able to run on Wayland
> >> already (not perfectly, but it works afaik), so it was ported already
> >> I'd say.
> >>
> >> Is this about integrating this work in Fedora? Or more porting work? Or
> >> even make Wayland the default in F21? The section "How To Test" sounds
> >> as if the later is the case, but it's not entirely clear to me.
> >>
> >> (¹) This is not the first change proposal where the summary or the
> >> "Detailed Description" is more confusing then helpful to me (which makes
> >> me write this mail). It afaics would help a lot if those areas would use
> >> words that ordinary people (think of people that have only basic
> >> computer skills here) would be able to understand.
> >
> > I usually try to work with change owners on clear wording,
>
> I know. Many thanks for all your hard work.
>
> > […]
>
> > For wording - Changes are *not* supposed to be read by general public,
>
> But we know the public reads them, as those that write websites, blogs
> and sometimes even magazines articles will pick these things up --
> especially in cases like this. Unclear words or statements thus could
> lead to confusion or bad press.
>
> Side note: "If you can't explain it simply, you don't understand it well
> enough."
>
> > it's internal planning tool and docs/marketing guys makes it consumable
> > in the end.
>
> Thus FESCo, ordinary developers like me (we get these change propose
> mails for a reason) and docs/marketing should be able to properly
> understand it -- which afaics to often is not the case :-/
>
> > But generally I agree - better wording, better understanding.
>
> +1
>
> CU
> knurd
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: orphaning ooolatex + maintainership of my other packages up for grabs

[Alex Lancaster]

Thanks, Luis.

I just orphaned both python-biopython and sqlite2 so you can go ahead
and take ownership via PkgDB (I added myself as a co-maintainer for
both packages before orphaning).

Cheers,
Alex

Luis Enrique Bazán De León wrote:

> I can take part of this work :-)

> Regards!


- Original Message -
> ooolatex needs to be replaced by TeXMaths anyway, see:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1018515
> 
> In general, going forward at least for the immediate
> future, I will have to ramp down some of my Fedora efforts.
> 
> In the meantime feel free to update any of my packages
> if you're provenpackage, or volunteer to be a primary
> maintainer, and I'll happily orphan any of my packages:
> 
> https://admin.fedoraproject.org/pkgdb/users/packages/alexlan?acls=owner
> 
> I do want to continue with Fedora efforts (albeit reduced
> time), and ask to be kept on as co-maintainer, but some of
> these packages deserve more active maintainers than I
> am able to be right now.
> 
> Cheers,
> Alex
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

orphaning ooolatex + maintainership of my other packages up for grabs

[Alex Lancaster]

ooolatex needs to be replaced by TeXMaths anyway, see:

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

In general, going forward at least for the immediate 
future, I will have to ramp down some of my Fedora efforts.

In the meantime feel free to update any of my packages
if you're provenpackage, or volunteer to be a primary
maintainer, and I'll happily orphan any of my packages:

https://admin.fedoraproject.org/pkgdb/users/packages/alexlan?acls=owner

I do want to continue with Fedora efforts (albeit reduced
time), and ask to be kept on as co-maintainer, but some of
these packages deserve more active maintainers than I
am able to be right now.

Cheers,
Alex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL sftp module in proftpd

[Alex Domoradov]

Hello,

Is it possible to build sftp module in proftpd package by default? It
is very uncomfortable to rebuild proftpd each time only for one
module.

Thanks in advance
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Fedora Workstation Desktop Environment Concept

[Alex GS]

Hello list,

I'm a computer science major interested in Linux software engineering and
just beginning to learn programming so I'm use-case #1 and #2.  Currently
out of all my peers I'm the only one using Linux as far as I know.  Most
students and developers even those working on Linux oriented projects
either use Mac OS out of personal preference or Windows because it's the
default in most organizations and institutions of learning.  If users
cannot naturally and effortlessly migrate to the Fedora Workstation from
Mac or Windows and find a "normal" environment they're used to, the product
will fail.  The problem is that the vast majority of Linux desktops don't
meet the design standards set by the established commercial leaders.

Currently my favorite desktop environment is Gnome Shell and my second
favorite is Mate.  Gnome Shell is "almost" there, nearly meets the modern
Mac OS level of quality end-users expect, and has an excellent technical
foundation, it just needs some simple layout modifications and changes to
menu behavior.  I've put together a *.pdf document outlining my suggestions
and ideas outlining my suggestions in this regard, see the attached link.
Hopefully this can be useful to the working group and a provide a starting
point for a discussion about the default graphical user interface for the
Workstation product.

Document Link: http://goo.gl/0IzNgK
*this is a Google Documents link

Thank you for your time and attention!

Regards,
Alexander
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct