[EPEL-devel] Re: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9

[Christopher Engelhard]

I found it useful to ship the nextcloud package as a module, particularly in 
EPEL, but if after multiple years there really are only 12 packages in the repo 
and even those may or may not work then that is a pretty clear argument for 
eating the sunk cost & abandoning the idea.

-- Christopher
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in 1 week

[Christopher Engelhard]

Hi,

On 01.08.22 14:55, Miro Hrončok wrote:

php-aws-sdk3 lcts
php-pimple   lcts


both fixed.

Best,
Christopher
___
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: Review swaps: A bunch of PHP libraries

[Christopher Engelhard]

On 2021-07-19 11:58, Tomas Korbar wrote:

Hi guys,

I will review https://bugzilla.redhat.com/show_bug.cgi?id=1982618
and https://bugzilla.redhat.com/show_bug.cgi?id=1982621


Thanks. Note that php-giggsey-libphonenumber-for-php requires 
php-giggsey-locale, which is also not in the repos yet.



For exchange could you Christopher please review
https://bugzilla.redhat.com/show_bug.cgi?id=1983601 ?


Sure.
___
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: rpmautospec deployment into production

[Christopher Engelhard]

On 2021-07-19 09:07, Otto Urpelainen wrote:

However, copr seems to understand rpmautospec. Here is a build that
started from a specfile that uses rpmautospec and completed
successfully:

https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/build/2329596/


Not quite. It doesn't error, but it doesn't deal with the macros either. 
%autochangelog should be replaced with the actual changelog during 
builds, which doesn't happen on Copr. I think, though I haven't tested, 
that it also always uses 1. as the release.


See e.g. the .src.rpm here for a rpmautospec build on koji

https://koji.fedoraproject.org/koji/buildinfo?buildID=1780088

Christopher
___
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: Review swaps: A bunch of PHP libraries

[Christopher Engelhard]

On 18.07.21 16:06, Otto Urpelainen wrote:
> mt32emu - C/C++ library for emulating Roland MT-32, CM-32L and LAPC-I
> synthesizer modules
> A cmake project that is somewhat complicated by the fact that it comes
> from a monorepo that also contains other related projects.
> https://bugzilla.redhat.com/show_bug.cgi?id=1980482
> 
> rubygem-sync - A module that provides a two-phase lock with a counter
> Ruby library whose specfile was automatically generated with gem2rpm,
> only small adjustements were needed on top of that.
> https://bugzilla.redhat.com/show_bug.cgi?id=1978395

Sure, I'd be happy to. And thanks.

Christopher
___
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: rpmautospec deployment into production

[Christopher Engelhard]

On 17.07.21 00:59, Miro Hrončok wrote:
> On 16. 07. 21 19:58, Robert-André Mauchin wrote:
>> On 6/16/21 6:03 PM, Nils Philippsen wrote:
>>> Hi everybody,
>>>
>>> we've scheduled the rpmautospec plugin to be deployed into production
>>> for tomorrow, from 14:00 UTC on.
>>>
>>> This means installing the relevant packages and restarting kojid
>>> processes on the builders, which will restart any tasks which are being
>>> processed at that time, i.e. expect delays for builds in-flight at the
>>> time.
>>>
>>> We'll announce when the deployment is done.
>>>
>>> Cheers,
>>> Nils
>>>
>>
>> What is the situation wrt new packages? Should we enforce the use of
>> rpmautospec during reviews or is it completely optional?
> 
> It is completely optional.
> 

One thing to note: If people *are* using it, then right now
fedora-review will complain about a missing dist-tag and rpmlint will
warn about macros in the changelog.
___
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

Review swaps: A bunch of PHP libraries

[Christopher Engelhard]

Hi all,
I finally found some time to unbundle all the 3rdparty PHP/composer 
libraries from the nextcloud package.

The bad news is that due to their various dependency trees, I now have a 
total of 24 new packages that need reviewing.
The good news is that I think quite a few of them will be generally 
useful beyond just nextcloud.

They are all fairly small & simple PHP libraries, build without issues 
and are basically identical in terms of packaging. If there are people 
out there who'd like to try their hand at reviewing for the first time, 
one of these might be a good place to start.

Obviously, if you need something reviewed in return, I'd be happy to do 
that.

Full list of links is below, but to make it easier for people
- I set up a dependency tree ( 
https://bugzilla.redhat.com/buglist.cgi?bug_id=1981857_id_type=anddependson=tvp_id=12016550
 
) so you can pick a leaf.
- I made a copr repository ( 
https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/packages/ ) that 
has builds for all of these, including fedora-review/rpmlint logs (and a 
big thank you to whoever made that last bit possible in Copr, that was 
*extremely* useful). The repo also contains a few forks of existing 
packages, ignore those :) .

Best,
Christopher

List of links:
https://bugzilla.redhat.com/show_bug.cgi?id=1982616
https://bugzilla.redhat.com/show_bug.cgi?id=1982618
https://bugzilla.redhat.com/show_bug.cgi?id=1982619
https://bugzilla.redhat.com/show_bug.cgi?id=1982621
https://bugzilla.redhat.com/show_bug.cgi?id=1982624
https://bugzilla.redhat.com/show_bug.cgi?id=1982627
https://bugzilla.redhat.com/show_bug.cgi?id=1982629
https://bugzilla.redhat.com/show_bug.cgi?id=1982630
https://bugzilla.redhat.com/show_bug.cgi?id=1982631
https://bugzilla.redhat.com/show_bug.cgi?id=1982632
https://bugzilla.redhat.com/show_bug.cgi?id=1982633
https://bugzilla.redhat.com/show_bug.cgi?id=1982635
https://bugzilla.redhat.com/show_bug.cgi?id=1982636
https://bugzilla.redhat.com/show_bug.cgi?id=1982637
https://bugzilla.redhat.com/show_bug.cgi?id=1982638
https://bugzilla.redhat.com/show_bug.cgi?id=1982639
https://bugzilla.redhat.com/show_bug.cgi?id=1982640
https://bugzilla.redhat.com/show_bug.cgi?id=1982643
https://bugzilla.redhat.com/show_bug.cgi?id=1982645
https://bugzilla.redhat.com/show_bug.cgi?id=1982646
https://bugzilla.redhat.com/show_bug.cgi?id=1982647
https://bugzilla.redhat.com/show_bug.cgi?id=1982648
https://bugzilla.redhat.com/show_bug.cgi?id=1982651
https://bugzilla.redhat.com/show_bug.cgi?id=1982652





___
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 check for siwinski (Shawn Iwinski)

[Christopher Engelhard]

Hi,
does anyone know how to get in touch with Shawn? There are a couple bugs
I opened a while ago that have seen no response, e.g. here:
https://bugzilla.redhat.com/show_bug.cgi?id=1933633

Non-responsive maintainer bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1982667

Thanks,
Christopher
___
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: discord fedora .rpm and repo

[Christopher Engelhard]

Hi,
unless I'm very much mistaken, since Discord isn't open source software
it cannot be packaged by Fedora.

Christopher

On 11.06.21 19:54, Cătălin George Feștilă wrote:
> Dear team 
> Dear team.
> I would like to know if anyone took care of integrating the discord 
> application in the Fedora distribution?
> Do we have a repo for this application?
> On the official website, I saw packet deb and tar.
> Thank you.
> ___
> 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: Orphaned packages looking for new maintainers

[Christopher Engelhard]

On 18.05.21 22:04, Miro Hrončok wrote:
> php-opencloud-openstack

I'll take this, I'll need it for nextcloud unbundling.
___
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: Orphaned packages looking for new maintainers

[Christopher Engelhard]

On 08.03.21 11:52, Miro Hrončok wrote:
> php-deepdiver-zipstreamer orphan   0
> weeks ago
> php-opencloud-openstack   orphan   0
> weeks ago

I've taken these, I will need them for nextcloud
___
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

[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)

[Christopher Engelhard]

On 09.12.20 15:20, Troy Dawson wrote:
> Does anyone know of a group that is going to start their own RHEL Clone?

I'm sure the Scientific Linux people will do something, given that they
just recently decided to not release SL8 but rather use CentOS 8. I feel
quite bad for them, actually ...

Some tentative work seem to be happening here:
https://github.com/hpcng/rocky
but it's early days obviously. They seem to be interested in
coordination with other attempts
(https://github.com/hpcng/rocky/issues/2), which is good.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)

[Christopher Engelhard]

On 09.12.20 11:17, Miro Hrončok wrote:
> However, since CentOS Linux 8 (and 9!) will be no more, do we have some
> ideas how to handle this? Do we require all EPEL contributors to obtain
> the developer RHEL subscription (seems like a huge pain)? Do we switch
> to Oracle Linux (only half joking)? Do we try to fight this decision
> (however I am afraid I've exhausted my fight capacity on different
> decisions)?

Intuitively, I think that requiring RHEL dev subscriptions would pretty
much kill  EPEL packaging on Copr. Unless you specifically want to
create EPEL packages, why would you get and keep a RHEL dev subscription
when you could just not check the EPEL-boxes?

From a purely technical perspective, i.e. pretending it were CentFork
Community Linux, are there reasons not to use Oracle Linux?

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

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Christopher Engelhard]

On 2020-12-03 09:31, David Kaufmann wrote:

On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote:
That would be amazing! In order for it to remain as an edition, we 
(speaking
generally for the Council) like to see regular meetings -- at least 
monthly.


I'll check the situation there - if there are more people interested in
a meeting I'll definitely join. There is a set date currently, I can
make that next week I think and for now I'll just use that one.


I'd definitely be interested as well.

One outstanding thing that could be worked on is the merger of the 
Fedora

Cloud Base image and Fedora Server. We agreed that this should be done
several Flocks ago, but no one has had time to actually make it 
happen.


Until now I thought of both as having a very different target audience,
I've never looked at Cloud Base, as I almost completely self-host.
I don't really understand why it should be merged, is there some
document or chat log for that?


I have no inside knowledge on this, so these are just my thoughts:
I'd say the cloud & server editions actually do very similar things - 
I'd expect that the Fedora Cloud images get most use as a server of some 
kind. From a user perspective, if I fired up a Fedora Cloud image on 
AWS, I'd expect it to look pretty much like a (maybe pared down?) Fedora 
Server Edition. One has anaconda, the other cloud-init (or whatever AWS 
uses), but otherwise more or less the same system. Ideally, I would like 
to be presented with more or less the same system regardless of whether 
I'm on AWS, DO, linode, ... or bare metal.


There was also talk of working more closely with Ansible on system 
roles.

I'd love to see that revived too! There is also potential for greater
collaboration with CentOS and the CentOS Stream project. I'd love to 
have a
clear, non-competitive answer for each of these projects on when one 
should

use what.


Same as above, I'd like to read up on that. I'm not sure what "system
roles" relate to, I've found linux-system-roles.github.io and I know
a big chunk of fedora-infra systems is managed using ansible.


Again, just my thoughts. This would go very much in the 'discuss what do 
we want the edition to be' pile. That said, all editions sort of decide 
how the user will by default interact with them. Workstation assumes the 
user will manage the system via the DE for obvious reasons, CoreOS 
assumes that the user will be managing the system via container tools, 
Fedora Server assumes the user will monitor the system via Cockpit, and 
actually manage it via  poking around in config files.
So one could think about making Ansible the central configuration tool 
for Fedora Server, just like Cockpit is its central monitoring tool:


Workstation = general purpose workstation use, managed & monitored via 
the DE
CoreOS = general purpose container/kubernetes use, managed & monitored 
via those tools
Server = general purpose non-container server use, managed & monitored 
via cockpit & ansible


Not sure how feasible that is, but I can see the reasoning (full 
disclosure, I love ansible, so I'm in no way impartial here).



Christopher
___
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 rawhide compose report: 20201112.n.0 changes

[Christopher Engelhard]

Hi,
something weird is going on with the rawhide compose (thanks Vit for
alerting me)

On 13.11.20 00:44, Fedora Rawhide Report wrote:
> Package:  nextcloud-20.0.1-3.fc34
> Old package:  nextcloud-20.0.1-2.fc34
> Summary:  Private file sync and share server
> RPMs: nextcloud nextcloud-httpd nextcloud-mysql nextcloud-nginx 
> nextcloud-postgresql nextcloud-sqlite
> Size: 415.35 MiB
> Size change:  325.60 MiB
> Changelog:
>   * Wed Nov 11 2020 Christopher Engelhard  - 20.0.1-3
>   - Remove CentOS/RHEL 7 support from spec file

The only difference between the two builds is the removal of a separate
config file for EL7 from the .src.rpm. I checked the builds locally and
in koji[1][2] and the packages are virtually identical in size (~115MB
for the .src.rpm, ~90MB total for the rpms).

Anybody any idea what is happening here?

Christopher

[1] 20.0.1-2 https://koji.fedoraproject.org/koji/buildinfo?buildID=1640582
[2] 20.0.1-3 https://koji.fedoraproject.org/koji/buildinfo?buildID=1640923
___
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: list major languages first in anaconda

[Christopher Engelhard]

On 22.10.20 10:41, Zbigniew Jędrzejewski-Szmek wrote:
> Also, I think we should go by the *total* number of speakers, not just the 
> speakers
> for whom the language is the *first* language. My thinking (and I would love
> to hear from people who are in this situation) is that many parts of the world
> people know multiple languages and are likely to select the interface in
> a second language, if that second language for example is of European origin
> and uses the Latin alphabet or is otherwise better supported by the software.

I think that makes sense. I usually set English even though my other
languages are well supported, because it means less mentally switching
back and forth.

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 14.10.20 19:32, Kevin Fenzi wrote:
> We now allow scls if: 
> 
> * They only need to be used at build time (ie, the rpms produced do not
> require users to install/enable any scls)
> * They are approved by the epel steering comittee. 
> 
> So far we have only enabled devtoolset. (so for example, chromium uses
> devtoolset to build with a newer gcc, but does not require users to
> install or enable anything to use it). 
> 
> In the case of php, this would likely not work because it would require
> users to install/enable php to get the webserver module or cmd line. 

Thanks for the clarification, but you're right, that won't help here, as
NC has extensive runtime PHP7.2+ dependencies.

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 13.10.20 12:14, Leon Fauster wrote:
> My recall was this
> 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DBAQB3V35TXPNUV4UKKHXUC52BENZJUQ/

OK, thanks, that clears that up. So I'll go ahead and retire the EPEL7
package. Maybe I can put an updated one on Copr instead.

Thanks to all of you, you helped tremendously.

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 12.10.20 10:49, Leon Fauster wrote:
> Not sure but IIRC EPEL should not depend on software collections ...?

Can someone confirm that? If the package can't depend on php7.2+, then
the question of how to deal with EPEL7 is moot.

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 12.10.20 12:09, Petr Pisar wrote:
> RHEL releases a minor version every six months. And as I remember, EPEL8
> allows breaking upgrades at each new RHEL release. Thus technically, it's
> possible to rebase the package every year without getting into conflict with
> packaging guidelines. On the other hand, I'm not sure whether the users know
> it and expect it.

OK, that might work - somehow I remembered the minor versions being
released more rarely.

> You could package each new incompatible version into a separate module stream
> and keep maintaining only the latest one. This way the users could switch
> to the newer stream whenever they feel comfortable. If they slip switching
> to the latest stream, then can migrate any later by hopping through all the
> intermediary streams up to the latest one. That could be even automated by
> a script.

At As Nick Howitt pointed out, NC can be modified to skip the version
check, so maybe the hopping isn't even necessary. Still, if the old
streams remain available ... intriguing possibilities.
> 
> There is a downside of the modules: There is no mechanism for tracking the
> latest stream automatically. DNF team is willing to implement the mechanism,
> but so far it's only a conception. It's also dubious whether the new mechanism
> would be ported back to RHEL 8. So far users have to switch the streams
> manually.

I was thinking of offering a nextcloud-stable or -latest stream that
simply follows upstream release channel (i.e. N+1.0 replaces N.x, even
if N is still supported and receiving updates) in addition
tonextcloud-. Or have a normal (ursine?) package for that. That
way users can choose between an automatically updating or version-stable
Nextcloud, and whatever they choose, they know what they're in for.

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 11.10.20 23:29, Nick Howitt wrote:
> How do you intend to handle the switch to PHP7.3?

Not sure yet - I wanted to make sure it even makes sense to keep
nextcloud in EPEL7 first. But that's another reason it's probably risky
to jump people from NC10 to NC18+ (NC13 was the last release to support
PHP5.x, so that's no use). Maybe Copr is the way to go here, people will
definitely only get the package if they seek it out, and it's easier to
leave instructions/caveats where people will see them.

My current plan is
 - put current nextcloud, following their 'stable' path in epel-8-playground
 - see about creating nextcloud-XX and maybe nextcloud-latest modules
for inclusion in epel8
 - epel7: ???

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 11.10.20 15:10, H wrote:
> I'd like it updated, and kept updated, for EPEL 7.

Do you happen to have a system with the current 10.0.something EPEL7
package set up & would you be willing to - if I make an updated package
- test the upgrade process? I could set up something myself, but I think
most problems are going to be with database changes, and that's not
really testable on an empty test install ...

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

One thing I forgot that makes things even worse:

- upstream does not support updates across more than one major version,
so anybody who actually has the old v10 installed will have their
installation completely broken by ANY update at this point
- for the same reason, trying to limit major updates to whenever
CentOS/RHEL release a new version won't work either.

I think I'll retire and look into re-adding it via modularity.

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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Christopher Engelhard]

On 11.10.20 13:57, Nicolas Chauvet wrote:
> I'm fine with retiring it.
> 
> But on the alternatives , you can have modules (or application
> streams) for both epel and fedora.
> It would be a good way forward. so it won't enforce nextcloud version
> with a given fedora and or epel and would allow to update nextcloud at
> users own pace.

I'm sort of hesitant to dive into learning how modularity works, though
... although, maybe a good opportunity to learn.

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

[EPEL-devel] Fast-moving packages in EPEL

[Christopher Engelhard]

Hi,
the nextcloud server package is currently stuck at ancient version 10
(current is 20) in EPEL7 (It's not (yet) available EPEL8 repos).

I'd like to fix that, but

- upstream releases a new version roughly every 4 months
- they support them only for roughly 1 year (officially it's "at least 8
months")
- nextcloud receives A LOT of bug- and CVE-fixes, and there is no way
I'll be able to backport all of those, so staying on an older version
after upstream stopped support is not really an option.

So, should this still be in EPEL even though it would receive major
version updates or is it better to retire it from EPEL?

I suspect that EPEL users would probably prefer to run it from
upstream's containers anyways, so retiring might make more sense, but
I'm open either way.

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

Re: F33 Workstation/btrfs: Can't reinstall while preserving /home

[Christopher Engelhard]

On 10.10.20 00:45, Chris Murphy wrote:
> This might be a good Quick Doc candidate.
> https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home

Good idea, I'll do that.

Christopher
___
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 Workstation/btrfs: Can't reinstall while preserving /home

[Christopher Engelhard]

On 09.10.20 20:59, Brandon Nielsen wrote:
> It's certainly a little different. See if an answer in this thread works
> for you:
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/VZFJ2MWPJLSP3RFCWN4H7MWDXXWEXLNL/

Thanks, I must have missed that thread. Deleting & recreating the
subvolume works as expected, both in Blivet & Custom partitioning.

We should probably change the error message from 'requires a new
partition' to 'requires a new partition or btrfs subvolume' - that will
make it clearer to users, I hope. I'll file a RFE bug for that.

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

F33 Workstation/btrfs: Can't reinstall while preserving /home

[Christopher Engelhard]

Hi,
I just tried to reinstall a Fedora 33 Workstation system that uses the
F33 default btrfs partitioning (i.e. subvolumes for / and /home). I
can't seem to find an option to install to / while preserving the /home
subvolume, Anaconda insists on a reformatted partition for root - which
would of course wipe /home as well.

Am I missing something?

Christopher
___
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: mock, febootstrap, building chroots a.k.a. debootstrap

[Christopher Engelhard]

On 07.10.20 11:47, Daniel Pocock wrote:
> When using debootstrap, the user has to do some things manually, like
> mounting /proc, /sys, /dev and /dev/shm
> 
> It is relatively easy to duplicate those things for both Fedora and
> Debian chroots

ArchLinux has a nice script for this (arch-chroot) as part of their
arch-install-scripts [1][2].

Christopher

[1] https://git.archlinux.org/arch-install-scripts.git/tree/arch-chroot.in
[2] https://copr.fedorainfracloud.org/coprs/lcts/easy-chroot/
___
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: ichavero

[Christopher Engelhard]

Hi,

This is a non-responsive maintainer check for ichavero, in accordance 
with

policy [0].

I submitted 2 bugs [1][2] related to outdated nextcloud versions 
containing multiple (moderate) CVEs [3] about a month ago, but have not 
had any response. nextcloud has a huge number of open bugs [4], although 
most of them were reported against older nextcloud versions. Last 
activity from commit history was three months ago.


Does anyone know how to contact the maintainer?

Christopher

[0] 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1873705
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1873704
[3] https://nextcloud.com/security/advisories/
[4] 
https://bugzilla.redhat.com/buglist.cgi?component=nextcloud_id=11393781=Fedora
[5] 
https://src.fedoraproject.org/rpms/nextcloud/c/a4e7ed8572f74a415bcf5fe57f84073989faf768?branch=master

___
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: REAR and Fedora | Non-responsive maintainer

[Christopher Engelhard]

On 22.09.20 10:21, Andrea Perotti wrote:
> That has changed in the last hour, after the bugzilla has been opened [0].
> Glad to see the status in our systems now match the (sad) reality:
> at least if there are ppl interested in it, they could step up.

I took it, I'll work on getting it updated to 2.6 over the weekend.

Christopher
___
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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Christopher Engelhard]

On 10.09.20 17:53, Michael Catanzaro wrote:
> I'm a bit concerned that two different people are seeing this. I don't
> think we have any scriptlets tha writes to /etc/nsswitch.conf or
> /etc/authselect/nsswitch.conf on its own. But maybe, for non-live
> installs, that could happen if the systemd RPM gets installed before the
> authselect RPM? Then systemd would think /etc/nsswitch.conf is not
> managed by authselect. Hm
> 
> Anyway, if you can find a way to get to this state from a clean install,
> without touching those files manually, then please do report a bug. That
> shouldn't be happening.

I have this same issue on a system that was installed as F33 rawhide &
is now F34 rawhide. I never touched those files, nor did I do anything
that should have caused anything else to change them.

I'll file a bug - would this be against authselect or  systemd?

Christopher
___
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: Query on upgrading the Fedora package

[Christopher Engelhard]

Hi Muneendra,

On 28.08.20 10:47, Muneendra Kumar M via devel wrote:
> After stable time i.e 14 day's the updates  will be automatically moved to
> stable .Is this correct.

That is the default yes, but you can configure it differently in the
Bodhi web interface if you choose.

Check out the EPEL Guidelines if you're unsure [1][2].

Personally, I disable all automatic pushing to stable for EPEL, because
I try to align updates there with major updates to the underlying
CentOS/RHEL release & give it enough time in Fedora to iron out any
issues - the package will still be available in the testing repo for
those who like to try it early.

Best,
Christopher

[1] https://fedoraproject.org/wiki/EPEL_Updates_Policy
[2] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
___
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: Query on upgrading the Fedora package

[Christopher Engelhard]

On 28.08.20 10:04, Muneendra Kumar M wrote:
> Do I need to call fedpkg update --type enhancement after fedpkg build for
> epel8 ?

Yes. Any branch that is Bodhi-enabled (normally any branch except
rawhide & epel8-playground) will require a 'fedpkg update' to actually
submit the build to the repositories.

See here the documentation [1][2] for more info.

Christopher

[1]
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#bodhi-enabling
[2] https://fedoraproject.org/wiki/Package_maintenance_guide
___
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: Query on upgrading the Fedora package

[Christopher Engelhard]

On 27.08.20 13:27, Muneendra Kumar M via devel wrote:
> Hi Josey,
> Will the below steps work to upgrade the package for epel7.

Epel works just like any other Fedora branch, so unless there are
differences in dependencies on CentOS/RHEL vs Fedora (doesn't seem to be
the case, as you already have the old EPEL builds) just merging master
and building should work.

If there are incompatibilities you can either adapt the spec after
merging or deal with them with conditionals in the master spec file.

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

[Christopher Engelhard]

On 24.08.20 20:06, Simo Sorce wrote:
> 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.

Or a separate package, but at least the logic of selecting a default
from the available groups should probably reside in crypto-policies.

Christopher

P.S.: I put the package I created to install various default DH groups
on my systems on Copr, in case this is useful for anyone else:
https://gitlab.com/lcts/crypto-groups
https://copr.fedorainfracloud.org/coprs/lcts/fedora-rpm-addons/package/crypto-groups/
___
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

[Christopher Engelhard]

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?

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

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.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: Orphaned packages looking for new maintainers

[Christopher Engelhard]

On 24.08.20 12:25, Miro Hrončok wrote:
> numix-gtk-theme    mymindstorm, orphan 0 weeks ago
> numix-icon-theme   mymindstorm, orphan 0 weeks ago
> numix-icon-theme-circle    mymindstorm, orphan 0 weeks ago

If Brendan / mymindstorm isn't interested, I can take these.

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

[Christopher Engelhard]

On 23.08.20 04:26, Kevin Kofler wrote:
> While I understand the motivation behind the RFC (interoperability, safety 
> against intentionally or unintentionally bad parameters), hardcoded 
> parameters sound suspicious to me. How do we know that these are not chosen 
> to allow the NSA or some other country's equivalent agency to decrypt the 
> conversation?

Good point, that's a thorny issue in general.

I have, of course, not way to disprove that, but those parameters are
not just some random magic numbers, they're derived from a public,
defined & simple [1] formula, using as far as possible common constants
with no known relation to the DHE problem. This is no different than the
process that gives us Ed25519 [2], although admittedly that one is more
extensively explained in the relevant RFC.

There are mathematical ways of looking for trapdoors, and having the
method that created the number known makes such analysis feasable.

In the ideal case, (1) server operator A generates & validates & uses
safe parameters, and (2) user B knows & trusts A to have done so.
However, in general while (1) might well be true, but (2) usually isn't.

So the tradeoff is 'unvetted but secret' vs. 'highly vetted but known to
the NSA'.

There's probably no good answer here (other than not using FFDHE, of
course), but I think given that Fedora by default also uses the
potentially-NSA-tainted NIST curves & TLSv3 with FFDHE, encouraging use
of RFC7919 generally removes some potential security issues while not
introducing attack vectors that we already deem not significant (in
default configurations - what anyone deems significant for their own
system is of course entirely their business).

Christopher


[1] for a given definition of simple - RFC7919 primes are defined as

p = 2^b - 2^{b-64} + (floor(2^{b-130}*e)+X) * 2^64 - 1

where b is the bitsize and X is the smallest integer that creates a safe
prime.

[2] https://tools.ietf.org/html/rfc7748#appendix-A

There's some discussion of the general problem of validating DHE
parameters here:
[3] https://eprint.iacr.org/2019/032.pdf
___
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

RFC7919 Diffie-Hellman parameters in Fedora

[Christopher Engelhard]

Hi,
tl;dr should we make it easier/automatic for users to use the 
Diffie-Hellman parameters defined in RFC7919?


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

Re: Proposal to Add: Log In/Out Blocker Criteria

[Christopher Engelhard]

On 04.08.20 11:54, Paul Howarth wrote:
> If you remove the "with multiple user accounts" then being able to log
> in and out on a single-user system would satisfy the requirement even
> if the multi-user bug was present, which wouldn't be very helpful.

Hm, true. As usual, the devil is in the details.

Christopher
___
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 to Add: Log In/Out Blocker Criteria

[Christopher Engelhard]

On 04.08.20 10:47, Miro Hrončok wrote:
> I would even go further and remove the "with multiple user accounts"
> condition. Even on a singe user system, I'd like to be able to log out
> and back in again.

+1 on that.

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

[Christopher Engelhard]

On 08.07.20 23:47, Adam Williamson wrote:
> I think it's `efibootmgr -b  -L DefinitelyNotFedora`, where  is
> the number of the entry called 'Fedora', which you could find by just
> running `efibootmgr` to get a list of entries. -b selects the entry to
> operate on and -L changes the 'label', which I think is what we're
> dealing with here.

AFAIK efibootmgr can't change the label of an existing entry, but you
can delete it and then recreate it with the new name.
___
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.

[Christopher Engelhard]

On 04.07.20 17:59, Lennart Poettering wrote:
> btw, sd-boot has a few tricks up its sleeve: if during boot you keep
> "w" pressed down it will automatically boot into windows, similar if
> you keep "l" pressed down it will automaticall boot into linux, "a"
> will boot into macos, all without showing any UI at all.

I didn't know that (although I've used sd-boot since when it was still
called gummiboot) - that's pretty cool.
___
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.

[Christopher Engelhard]

Can we maybe not restart this entire debate? i686 in Fedora has run down
the curtain and joined the choir invisible. Whether we think that was
the correct decision or not, there is absolutely no point in rehashing
all the original arguments, let alone in a thread about BIOS support.

Christopher

On 03.07.20 08:14, John M. Harris Jr wrote:
> On Thursday, July 2, 2020 4:06:55 PM MST Alexander Ploumistos wrote:
>> On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr 
>>> None of the linked blockers are core packages, and some of them are
>>> outright not designed to work on anything other than 64 bit. I really
>>> don't understand how you can see that as justification.
>>
>> Even though both trackers still receive reports, many packagers just
>> stopped bothering with i686, because there was little response and
>> there were long-lasting breakages in rawhide. A distro arch is more
>> than the kernel; what good is having a 32-bit kernel and nothing to
>> run on it? See how many i686 bugs are closed as WONTFIX or
>> INSUFFICIENT_DATA.
> 
> There's more to core packages than just the kernel. There were no bugs in the 
> default install of Fedora Server or Fedora KDE Spin or GNOME 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

Re: booting successfully with read-only file system

[Christopher Engelhard]

On 02.07.20 17:53, Zbigniew Jędrzejewski-Szmek wrote:
> It would be great if we could fairly reliably boot with a read-only
> root file system, all the way to the graphical environment. Obviously,
> such a machine will not be fully functional, but for users, debugging a
> disk problem when they have the normal environment with windows,
> tabbed terminals, graphical editors, and internet is vastly easier.
> 
> It also creates an image of robustness. Imagine that instead of being
> rudely dropped to a terminal prompt, the user is instead able to log in
> as usual and see a popup like
>> Your home directory is read-only. Do this and that. See https://...

That would be fantastic, and would be miles ahead from any UX I had on
any computer, ever.

> I hope we can all cooperate to make read-only boots nicely robust and
> functional. Please play with this and report bugs. I'll try to solve any
> that relate to systemd. The systemd version with udev.blockdev-read-only
> is not released yet, but is available from koji ci builds [11].

Thanks for working on this, I will definitely give it a try myself.

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

[Christopher Engelhard]

I like this approach, a lot. I'm all in favour of switching to btrfs
(I've been using it for a while, on server & desktop), and I think this
would be a safe approach to do so.

Christopher

On 01.07.20 20:24, Matthew Miller wrote:
> On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
>> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
>> could be good option. I know technically it is already opt-in, but it's not
>> very visible or popular. We could make the btrfs option more prominent and
>> ask people to pick it if they are ready to handle potential fallout.
> 
> I'm leaning towards recommending this as well. I feel like we don't have
> good data to make a decision on -- the work that Red Hat did previously when
> making a decision was 1) years ago and 2) server-focused, and the Facebook
> production usage is encouraging but also not the same use case. I'm
> particularly concerned about metadata corruption fragility as noted in the
> Usenix paper. (It'd be nice if we could do something about that!)
> 
> Given the number of Fedora desktop users, even an increase of 0.1% in
> now-I-can't-boot situations would be a catastrophe. Is that a risk? I
> literally don't know. Maybe it's not -- but we've worked hard to get Fedora
> a reputation of being problem-free and something that leads without being
> "bleeding edge". It's a tricky balance.
> 
>> Normally we just switch the default or we don't, without half measures. But
>> the fs is important enough and complicated enough to be extra careful about
>> any transitions.
> 
> Exactly.
> 
> Maybe we could add an "Automatically configure with btrfs (experimental)"
> option to the Installation Destination screen, and then feature that in
> Fedora Magazine and schedule a number of test days?
> 
> To be clear, I'm not suggesting this as a blocking tactic. The assumption
> would be that we'd go ahead with flipping the defaults (as you say above)
> for F34 unless the results come back in a way that gives us pause.
> 
___
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 nano the default editor

[Christopher Engelhard]

On 26.06.20 12:20, Ian McInerney wrote:

> git is not the only program that uses the EDITOR variable. Some
> configuration tools on the command-line, such as crontab, will use the
> editor set in the environment variable if there is one.

visudo is also a good spot for a beginner to be stuck in vi.

Christopher
___
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 Packager Dashboard available for testing

[Christopher Engelhard]

This is awesome, thank you.

On my dashboard (https://packager.fedorainfracloud.org/lcts), the
mouse-over tooltips of top-row icons don't show up (I can see them in
other people's dashes).

This might be related to the fact that my packages currently have
nothing to display, as the same thing happens for dashboards of
non-existent accounts: https://packager.fedorainfracloud.org/xxyyzz

Christopher

On 23.06.20 18:28, Josef Skladanka wrote:
> Hi,
> 
> We'd like to announce public testing of the Packager Dashboard - a new
> service for Fedora package maintainers aiming to provide all relevant
> data: FTBFS/FTI status (from both Bugzilla, Koschei and health check),
> orphan warnings, bugzillas, pull requests, active overrides and
> updates - at a single place in an easy to read and filter way.
> 
> The Dashboard is now available: https://packager.fedorainfracloud.org/
> 
> Packager Dashboard leverages caching in the Oraculum backend to
> significantly speed-up loading times with comparison to querying all
> the relevant resources separately. We, of course, can't cache the
> entire Bugzilla, Pagure, Bodhi... so we only cache data for users who
> visit Packager Dashboard at least once per 14 days. Please keep in
> mind that the first load for a “new” user might take a while. Most of
> the data sources are refreshed every hour.
> 
> You can use the Dashboard for individual accounts as well as for FAS groups.
> 
> We'd love to hear your feedback. Please keep in mind that this is
> testing deployment - it's currently running on a server with very
> limited resources and we're aiming for production deployment on
> CommuniShift during this summer.
> 
> Feel free to provide ideas or bug reports at
> https://pagure.io/fedora-qa/packager_dashboard or simply send an email
> reply to this thread with all kinds of feedback.
> 
> I'd like to mention the other people who made this possible:
>  - Miro Hrončok (churchyard) - Original idea
> 
> and ideas for data to display
>  - František Zatloukal - Backend 
>  - Lukáš Brabec - Frontend 
> 
> Josef
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Christopher Engelhard]

It was orphaned, due to lack of time [1].
I'd be happy to take it.

Best,
Christopher


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XCLRSHRQBJRW5FPGIMBGOIH2KYLVSBNH/#XCLRSHRQBJRW5FPGIMBGOIH2KYLVSBNH
___
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: Fedora-Retired-Packages

[Christopher Engelhard]

I can't speak to the implementation of this, but I am in favour of the
approach in general, with one caveat: I think it is important to
implement this in a way that makes it possible for users to keep
*individual* retired packages around. Blacklisting
fedora-retired-packages is too broad a brush from the user perspective,
and will make it much harder to identify problems.

A question regarding this: What would happen if an update to
fedora-retired-packages obsoletes a package that is present on my system
but listed in dnf's excludepkgs?

Christopher
___
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: Bodhi: "how to install" is supposed to work?

[Christopher Engelhard]

On 02.06.20 14:24, Mattia Verga via devel wrote:
> Do you think adding a notice like
> "The following command may take some time to work after this update has 
> been pushed to testing, because the dnf mirrors should synchronize."
> would work? It may be not the best way to express that, since I'm not 
> English mother tongue, so if one has a best phrase let me know and I'll 
> push a PR to Bodhi.

That would be great.

Suggestion:

"It takes some time for repository mirrors to receive this update. If
the above command does not install anything, please wait for mirrors to
synchronize and try again. This should normally not take longer than
.


Christopher
___
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: Bodhi: "how to install" is supposed to work?

[Christopher Engelhard]

Hi Alessio,

On 02.06.20 09:32, Alessio wrote:
> sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-
> 81a3b3df7d
> 
> Is it supposed to work? Because every time I tried it, it didn't work.
> In addition a package received a negative karma due to that ^_^;

It usually takes a bit of time for the mirrors pick up the update, other
than that it should work.

What error are you getting?

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

[Christopher Engelhard]

On 13.05.20 14:55, Solomon Peachy wrote:
> On Tue, May 12, 2020 at 10:57:43PM -0400, Gerald Henriksen wrote:
>> The only way to make sure that the stuff included with Fedora is open
>> source is to build it from source - simply grabbing a binary provided
>> by an upstream means upstream could slip in some closed source
>> portions or have such a complex and undocumented build system that the
>> project may as well be closed source because no one else can build it.
> 
> I've personally encountered Java stuff that, when compiled from its 
> sources, immediately crashed, whereas the "official binaries" worked.

That is just incredibly broken.

Things like this are the reason why I think the build-from-source
principle is important, regardless of the inconvience it undeniably causes.

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

Re: f32-backgrounds look like crap

[Christopher Engelhard]

On 17.04.20 16:07, Kamil Paral wrote:
> Especially the one in Fedora 15 (GNOME edition) and 16 was outstanding.
> Can we do more of those, please?

Not weighing in on the merits of the current art, but 16 is still my
favourite default artwork of any distro, ever.
___
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: %bcond_with/%bcond_without

[Christopher Engelhard]

On 03.04.20 22:36, Zbigniew Jędrzejewski-Szmek wrote:
> So... could we please get a way to express this in rpm with a sane syntax:
> 
> %define_cond docs 0%{?fedora} > 0

Oh please, yes.

Christopher
___
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: Coronavirus: Fedora RTC solutions and YOU

[Christopher Engelhard]

On 30.03.20 19:35, Nathanael D. Noblet wrote:
> On Mon, 2020-03-30 at 18:09 +0200, Dario Lesca wrote:
>> Il giorno sab, 28/03/2020 alle 15.13 +, Sérgio Basto ha scritto:
>>> I will try packaging all Jitsi Meet suite [1] 
> 
> Me too, I've been watching that suite of tools and would love to be a
> little involved as potentially a co-maintainer but definitely a
> tester...

Same here. I don't have much experience with Java, but if I can help
with packaging in any way, let me know.

Christopher
___
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 libffi maintainer

[Christopher Engelhard]

On 2/24/2020 1:46 AM, Anthony Green wrote:
>I would be very happy if somebody could pick up the libffi packaging
> responsibility from me.

I'd be happy to adopt libffi, but given that I am a VERY new packager 
and this is a pretty core package, I think it would be best if someone 
with a bit more experience would offer to co-maintain.

Alternatively, you can just add me (lcts) as a co-maintainer.

Christopher
___
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: Seeking the maintainer of dbus-python

[Christopher Engelhard]

On 2/12/2020 11:01 AM, Vojtěch Trefný wrote:
> If nobody wants to maintain this package I can do that. It's definitely
> easier than rewriting our code to something else.

I can take it, or co-maintain, whichever works for you.

christopher
___
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: Pymol is broken on Fedora 31

[Christopher Engelhard]

On 07.12.19 12:46, Antonio Trande wrote:
> I'm interested.
> 

I'd be happy to co-maintain, if desired.

> On 07/12/19 12:20, Miro Hrončok wrote:
>> On 07. 12. 19 11:53, Henrique Castro wrote:
>>> Hello!
>>> Pymol is a package that, integrated with python-rdkit and other python
>>> packages, makes the lives of people working with drug discovery (and
>>> chemistry in general too) much easier. Unfortunately, the package is
>>> broken and not even build into F31. The maintainer has not replied to
>>> a BZ ticket open months ago.[1]
>>> At this point, the absence of the package is realy making an impact in
>>> science made with Fedora.
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1754678
>>
>> Unfortunately, pymol needs an active maintainer. Since it is retired,
>> any Fedora packager can request it to be unretired and become the owner
>> of it.
>>
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[Christopher Engelhard]

On 11/11/2019 3:51 PM, Scott Talbert wrote:
> Hi, one of the wxGTK maintainers here.  Where is the requirement to use 
> wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  And if 
> it is definitely required, *why* is it required?

On Archlinux audacity-git [1] builds against the default repo version of 
wxGTK, i.e. 3.0.4, so it does not seem to be required.

Christopher

[1] https://aur.archlinux.org/packages/audacity-git/ (ignore stated pkg 
version, package pulls master on install)
___
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

[Christopher Engelhard]

On 11/5/2019 9:17 PM, Stephen Gallagher wrote:
> I'd like to gather a constructive list of the actual use-cases that
> you feel Modularity is causing problems for, 

Thank you, that seems like a very good way forward.

> 6. We don't provide a direct solution for parallel-installability.
> This is an intentional design decision, but it *is* arguably a
> regression from SCL functionality, so I'll include it here.

Others have made this point before, but I want to emphasise how 
important this is:
If we decide that parallel installability is a non-goal - which IMO is a 
reasonable decision to make - we accept that this (via having module 
streams as dependencies) will at some point cause conflicts between 
mostly unrelated pieces of software. This breaks one of the core use 
cases of a software repository:

C1:
- if a user wants some (end-user) software, they install it via the 
software manager, knowing they get a reasonably up-to-date version
- if they hit 'update' when asked to do so, they maintain all their 
software in the 'reasonably up-to-date' state
- beyond that, *they don't have to care*.

Given that, we need mitigation strategies - at a technical or policy 
level - other than containers/VMs, because those are not viable 
solutions for this use case*.

Personally, I like a solution along the lines of what e.g. Kevin Kofler 
suggested earlier, that is

1) every package has a default version
2) any default version can only depend on default versions
3) the package manager distinguishes between 'install default, which 
happens to be version X' and 'install version X, which happens to be 
default', with automatic upgrade of 'X -> X' and 'default -> default' 
being OK and 'X -> default' or 'default -> X' requiring user intervention
4) where (2) cannot be achieved, we use compat packages as before

though I freely admit that I absolutely cannot judge how difficult that 
is to actually implement.

Christopher

*i.e. for most desktop users or anyone for whom computers are tools 
rather than infrastructure, really.
___
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: Self-Introduction: Christopher Engelhard

[Christopher Engelhard]

On 10/20/2019 11:28 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi Christopher,
> 
> welcome to Fedora. sshguard review is more than enough for a first package,
> quite a complicated beast. I'll sponsor you into the packager group.
> 
> Zbyszek

Hi,
sorry for the late reply, I was away over the weekend. Thanks you for 
your trust, and again thanks to Michal Schorm, who was a big help during 
the review.

Christopher
___
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 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Christopher Engelhard]

On 18.10.19 17:21, Robbie Harwood wrote:
> While you're right that the solutions from source distros (i.e., NixOS
> and Gentoo) would be very hard to adapt, binary distros have also solved
> this problem in different ways.  I'm most familiar with Debian's
> solution (virtual packages[2], provides:, and alternatives [1]) which
> to my mind maps much more clearly onto Fedora's setup.  Obviously we
> can't use their code wholesale without migrating to APT, but as you say,
> the goal is to derive inspiration.
> 
> Thanks,
> --Robbie
> 
> 1: https://wiki.debian.org/DebianAlternatives
> 2: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

I'm not a Fedora packager (yet[1]), so correct me if I'm
misunderstanding things completely, but is there any reason not to adapt
the existing RPM provides: functionality for this?

That is essentially what Archlinux does with their pacman, where an
second version of the same program will typically both Provide: and
Conflict: with the 'default' package. It's extensively used by users to
provide e.g. development versions of stable packages, see e.g.
inkscape-git [2].

- if you install inkscape, you get the default version
- if you install inkscape-git, you get the development version
- when resolving dependencies, pacman knows that inkscape-git provides
the capabilities of (Provides:) but cannot be installed together with
(Conflicts:) of the package named inkscape
- otherwise, they are two separate packages, so you don't have the
problem of implicitly switching streams

Parallel installability is taken care of with compat packages as usual,
though if the packages happen to be parallel installable, there's
probably no reason not to allow that via 'provides:' without 'conflicts:'

What I like about this approach that all this magic only comes into play
when resolving dependencies. In all other circumstances they are
packages like any other, and are treated as such.


Christopher

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1756582
[2] https://aur.archlinux.org/packages/inkscape-git
___
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: Packaging graph-tool: help speeding up build

[Christopher Engelhard]

On 14.10.19 23:07, Ankur Sinha wrote:
> Out of curiosity, how long did the build take on your machine there?

Almost 3 hours.

Christopher
___
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: Packaging graph-tool: help speeding up build

[Christopher Engelhard]

Hi,

On 14.10.19 19:59, Ankur Sinha wrote:
>> Is the documentation using parallel builds?
> 
> They don't say.

Seems unlikely, see below

> It uses configure/make/make install. I had run the build with make -j1
> too, but that had seemed to run even slower.. I hadn't checked the
> resource usage though, so maybe I'll run that again.

Using a single thread (by setting using %make_build -j1 or
RPM_BUILD_NCPUS=1) takes ages but seems to work at least locally.

Still the RAM usage is nowhere near the 3GB your graph shows.

- Mostly gcc uses around 2GB, with assembler adding up to 4GB on
occasion, very briefly.

- Some of the make steps are insane:
Biggest offenders so far seem to be graph_blockmodel_imp.lo with 10GB
for gcc + 4GB assembler, followed by graph_assortativity.lo with 6GB gcc
+ 4GB assembler, and a few others with 4-5GB gcc + 3-4GB assembler.
Throw multi-threading into the mix and this will easily add up to the
memory usage you're seeing (It totally killed my test server, that's for
sure.

I have no idea what hardware koji is using, so even single-threaded,
this might be an issue, but I'd still give it a try.

Christopher

P.S.: The linked spec file only works for me if I use
%autosetup -S git -n %{modname}-%{version}
because the archive doesn't unpack to packagename-version.ext


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

Self-Introduction: Christopher Engelhard

[Christopher Engelhard]

Hi all,
since I recently submitted my package for sshguard [1] for review [2], 
this is probably a good time to introduce myself (some of you might 
remember me from the packaging list). I'm also looking for a sponsor, 
assuming the package is positively reviewed.

I"m Christopher, 35yr old, from Germany originally but living in the 
Netherlands. I"m a scientist and write mostly octave & some python code 
for data analysis, so I'd consider myself more of a script-wrangler than 
a developer, but I follow - and occasionally submit patches to - a 
number of other open source projects, including sshguard.

About the package:
sshguard is a log-monitoring service that blocks brute-force attempts on 
common services, similar to fail2ban. It"s not as freely configurable as 
the latter, but supports most common services out of the box and 
requires little to no configuration. Additionally, it supports pretty 
much any blocking backend one might think of.

Best,
Christopher

[1] https://www.sshguard.net/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1756582
___
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