Re: Over 500 orphaned packages seeking new maintainers

[Mat Booth]

On Tue, 30 Jul 2019 at 18:28, Christopher 
wrote:
>
> On Tue, Jul 30, 2019 at 1:10 PM Alexander Scheel 
wrote:
> [snip]
> > The Java SIG is here:
> >
> >  - https://fedoraproject.org/wiki/SIGs/Java
>
> Is there anything special one must do to "Join" the Java SIG? I would
> like to join.


No, it was just a loose association of packagers who wanted to coordinate
work on the Java stack. It's kinda moribund these days, but one or two of
us still hang out in #fedora-java on Freenode. Please also join the
(low-traffic) java-devel mailing list.

--
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Rolling out Phase I of rawhide package gating

[Przemek Klosowski via devel]

On 7/31/19 4:34 PM, Kevin Fenzi wrote:

On 7/31/19 12:05 PM, Nicolas Mailhot via devel wrote:

And, just to provide another data point, we tried this month to make
the network install iso talk to https dnf repos (a reposync of fedora
devel x86_64, without x86 packages, because we don't have the storage
budget to mirror 32 bit packages we don't have the use for them
anyway). The repos themselves worked fine from installed systems. But,
anaconda refused to use them, till they were re-exposed in plain un-
secured http.

Any errors? Bug filed? as long as the certs were valid/normal certs,
there should not be any reason that wouldn't work I wouldn't think.


My guess would be a protocol version or cipher suite negotiation 
failure, presumably because the HTTPS end points use newer 
configurations that exclude old versions and ciphers. Hopefully Nicholas 
will find the real reason.



BTW, the new crypto systems like wireguard are eschewing crypto 
negotiation: if the current protocols are determined  to be lacking, the 
plan is to push a new version and force everyone to upgrade.


It's pretty harsh from the operational point of view, but they have a 
point: if the crypto is vulnerable, it should not be possible to force a 
downgrade on connections you care about, and you can still run the old 
protocol specifically for endpoints which you cannot upgrade.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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

corrupt GNU_PROPERTY_TYPE (5) size: 0, bad GNU build attribute

[Miro Hrončok]

Hi.

I get a FTBFS with micropython that I fail to parse.

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

Does anybody know what this means and how shall I fix this?
May it be a glibc regression?

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

Re: Rolling out Phase I of rawhide package gating

[John Florian]

On 2019-07-31 21:35, Jason L Tibbitts III wrote:

"NG" == Neal Gompa  writes:

NG> You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf

NG> That said, you probably don't want to do that, since most downloaded
NG> packages aren't signed...
Cool!  I wasn't even aware of this setting.  Can we set that and then 
override with --nogpgcheck for the exceptions?


I think that the ideal behavior would be to always check, but
warn/prompt for unsigned packages or those with signature failures.
Certainly it's better to verify as much as possible as often as
possible.

That would be even better, except maybe when scripting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: mass rebuild, glusterfs build failed

[Jason Tibbitts]

> "KK" == Kaleb Keithley  writes:

KK> The firewalld packager doesn't seem to know how to add an
KK> ExcludeArch: to the .spec or how to remove the 'Requires: kernel
KK> ...' line.

KK> https://bugzilla.redhat.com/show_bug.cgi?id=1733602

KK> Maybe someone with some authority on the subject can give some
KK> guidance?

I did so yesterday and I believe the matter has been resolved (pending
builds and such, of course).  The dependency was there because firewalld
required certain kernel features.  It should have been either a conflict
or a Boolean dependency instead of a hard dependency, but for f30+ it's
not necessary at all and so has been removed.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: update hung in "pending" status

[Mátyás Selmeci]

On 7/31/19 10:17 PM, Kevin Fenzi wrote:
> On 7/31/19 4:18 PM, Mátyás Selmeci wrote:
>> Hi,
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been 
>> stuck in "pending" status for several hours now.  Can someone kick them so 
>> they get into testing?
> 
> Updates pushes for stable releases happen once a day, starting at 00:00.
> 
> Those are both in the current pushes that are going out now... they
> should be out in a few more hours.
> 
> kevin

Ah, I didn't know that.  I've seen emails go by about stuck updates which is 
why I thought this might be the case.

If I want to get an early start on testing those packages, should I just 
download them from Koji?

Thanks,
-Mat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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

Fwd: Sunset of infinote (Gobby) service

[Clement Verna]

Dear all,

The Fedora Infrastructure is planning to retire the infinote [0]
service. This service allows text collaboration using the Gobby
client[1] and was mainly used by the Infrastructure team to coordinate
our weekly meeting and the mass update & reboot of the machines.

The service will be taken offline on August 30th 2019. If you wish to
backup some of the document currently hosted, you should make sure
that you have downloaded them locally before that date.

The Infrastructure team will most likely use the service provided by
hackmd.io [2] for their needs. Other alternatives like public etherpad
can also be used to replace this service.

Thanks,
Clément

[0] - https://infinote.fedoraproject.org/infinote/
[1] - https://fedoraproject.org/wiki/Gobby
[2] - https://opensource.com/article/19/7/enable-collaboration-hackmd
___
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

Fwd: Sunset of infinote (Gobby) service

[Clement Verna]

Dear all,

The Fedora Infrastructure is planning to retire the infinote [0]
service. This service allows text collaboration using the Gobby
client[1] and was mainly used by the Infrastructure team to coordinate
our weekly meeting and the mass update & reboot of the machines.

The service will be taken offline on August 30th 2019. If you wish to
backup some of the document currently hosted, you should make sure
that you have downloaded them locally before that date.

The Infrastructure team will most likely use the service provided by
hackmd.io [2] for their needs. Other alternatives like public etherpad
can also be used to replace this service.

Thanks,
Clément

[0] - https://infinote.fedoraproject.org/infinote/
[1] - https://fedoraproject.org/wiki/Gobby
[2] - https://opensource.com/article/19/7/enable-collaboration-hackmd
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

Re: Authentication in fedpkg

[Stephen John Smoogen]

On Thu, 1 Aug 2019 at 03:52, Björn Persson  wrote:

> Stephen John Smoogen wrote:
> >Changes in
> >authentication methods require a lot of dedicated work because it affects
> >all workflows somewhere.. and because it would mean so much downtime.. it
> >has never gotten the resources in time and engineers to do.
>
> Obviously replacing an authentication protocol is a big change that
> affects many things, but some smaller improvements could make the user
> interface suck less. Asking for a password instead of just failing is
> an isolated client-side change. It would take some programming work of
> course, but little or no coordination between different components.
>

I think we are talking about different things. I am talking about fixing
the backend to make it so fedpkg can authenticate easier. You are talking
about having fedpkg talk to a non-working 80% api backend. The fedpkg could
ask for a password.. it could also fail regularly spectacularly because the
backend wasn't meant to deal with that but was hacked together to sort of
work like that. So to make the front end have a better user experience..
you need to make the backend work consistently. [Even the kerberos side you
mention is not really tied into authentication easily.. but is done through
a set of clever programming to make disparate tools work together.]



> Authenticating in advance with kinit would continue to work, so nobody's
> workflow would break.
>
> Björn Persson
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe 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

[EPEL-devel] Zabbix 4.0

[Orion Poplawski]

I've got a package of Zabbix 4.0.5 going to epel-testing:

https://bodhi.fedoraproject.org/updates/zabbix40-4.0.5-1.el7

feedback appreciated.

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-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: systemd-243-rc1

[Nicolas Mailhot via devel]

Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> 
> > Since these things are both the case, a simple 1:1 mapping from "-" 
> > to
> > "~" (and even back) is exactly correct.
> > So I think the systemd.spec is doing exactly the right thing here.
> > 
> > The only issue I see is the arbitrary (?) restriction that git tags
> > cannot contain the tilde character.
> > Or is that there for filesystem compatibility, because tags are
> > just files?
> 
> git uses "~" for referencing commits relative to a commit identifier,
> see:
> 
> https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em
> 
> Hence they do not allow it in tag names, to avoid the ambiguity.
> 
> I guess RPM is the outlier for using ~ the way it uses it, I don't
> think much other software does that. 

~ is a debianism, introduced in rpm because some felt it was going to
satisfy uptream needs for irregular preversiob versioning

what rpm likes, and pretty much all component management stacks like
and support, is pure series of numbers separated with dots, without the
-foo pre-version madness that breaks everywhere in slightly different
ways.

Don't release anything that is not a series of numbers separated with
dots, no one ever managed to define anything else that works for
everyone (and many tried).

The preversion in semver is basically "it will break right and left,
who cares, no one will use it". Written by idealists that forgot the
point of preversions is to be used and deployed so some testing is done
before final release. 

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

Re: mass rebuild, glusterfs build failed

[Kaleb Keithley]

On Wed, Jul 31, 2019 at 3:43 PM Kevin Fenzi  wrote:

> On 7/31/19 12:01 PM, Kaleb Keithley wrote:
>
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1733602
> >
> > One of the suggestions there is to "drop the arch."   I.e. i686.
> >
> > If that ends up being the solution that pretty much would force me to
> drop
> > the arch too for glusterfs. (GlusterFS has a bit of plumbing around
> opening
> > ports in the firewall. It might just fail — silently or not so silently.
> > It's hard to know, nobody has tested it.
> >
> > I suspect dropping the arch might cause some amount of heartache in some
> > circles.
> >
> > OTOH, I haven't paid close enough attention to really understand what it
> > means to stop building i686 kernels. Does that mean no Fedora
> distribution
> > for i686 hardware?  Does it even make sense to keep building glusterfs
> for
> > i686?
>
> I would drop the kernel dependency. It doesn't make sense already in
> some contexts (containers) and this is a Fedora package for Fedora
> users, so I think anyone who would install it would have a kernel, and
> if it's a supported Fedora release it would be larger than 4.18.0.
>

glusterfs is not the package with the dependency on kernel. Its dependency
is on firewalld, which is where the kernel dependency comes from.

The firewalld packager doesn't seem to know how to add an ExcludeArch: to
the .spec or how to remove the 'Requires: kernel ...' line.

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

Maybe someone with some authority on the subject can give some guidance?

Personally I'd be perfectly happy to stop building glusterfs for 32-bit
platforms. I honestly don't think anyone runs on 32-bit and the developers
aren't really thinking about 32-bit as they work on it. (I had to add a
32-bit build in the CI just to catch all the 32-bit sprintf format mistakes
they were making.)

And FWIW, Ceph has abandoned 32-bit platforms starting with
Nautilus/14.x.x.  I have suggested that GlusterFS officially abandon 32-bit
starting with 7.0. Not sure whether that hasn't fallen on deaf ears.

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Muneendra

[Muneendra Kumar M via devel]

Hi Matthew,
I have submitted a new package and the details are below.
The main purpose of this daemon is to add FC network intelligence in host
and host intelligence in FC network. This daemon would interoperate with
Brocade FC fabric in order to improve the response time of the MPIO
failovers. In future, it can also collect the congestion related details and
perform workload analysis, and provide QOS at application level by
interoperating with application performance profiling software.

The linux  changes necessary for this package is already available in
upsteam.

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

Regards,
Muneendra.



-Original Message-
From: Matthew Miller [mailto:mat...@fedoraproject.org]
Sent: Thursday, August 1, 2019 2:44 PM
To: Muneendra Kumar M via devel 
Cc: Muneendra Kumar M 
Subject: Re: Self Introduction: Muneendra

On Thu, Aug 01, 2019 at 12:32:06PM +0530, Muneendra Kumar M via devel wrote:
> My name is Muneendra Kumar, I’m working for Broadcom . I have been
> working in Linux for more than 15 years and submitted couple of
> commits to open source.

Hi, and welcome! I'm definitely glad to see more open source involvement
from Broadcom. Let me know if you get stuck on anything and I'll make sure
we find someone to help!

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

Re: systemd-243-rc1

[Lennart Poettering]

On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:

> Since these things are both the case, a simple 1:1 mapping from "-" to
> "~" (and even back) is exactly correct.
> So I think the systemd.spec is doing exactly the right thing here.
>
> The only issue I see is the arbitrary (?) restriction that git tags
> cannot contain the tilde character.
> Or is that there for filesystem compatibility, because tags are just files?

git uses "~" for referencing commits relative to a commit identifier,
see:

https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em

Hence they do not allow it in tag names, to avoid the ambiguity.

I guess RPM is the outlier for using ~ the way it uses it, I don't
think much other software does that. Upstream software should hence
probably stick to how the majority does it, not necessarily just how
RPM likes it, unless the software is clearly focussed on the RPM world
only.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: systemd-243-rc1

[Lennart Poettering]

On Do, 01.08.19 05:31, Nico Kadel-Garcia (nka...@gmail.com) wrote:

> On Thu, Aug 1, 2019 at 4:16 AM Fabio Valentini  wrote:
>
> > So ... prerelease versions are usually tagged with an "-rc1" suffix
> > (or similar), which is a valid value for git tags, but RPM doesn't
> > allow versions to contain hyphens.
> > In RPM versions, prereleases can be tagged with an "~rc1" suffix (or
> > similar), which does exactly the right thing for version comparisons
> > in RPM, but is not a valid value for a git tag.
>
> It's also not following semver. Semver numbering, which is shown by
> the numbering of semver releases at https://semver.org/,  would be
> "-rc.1".

If you look at the actual spec wording, you'll see that "-rc1" is
fine too. Their example says "-rc.1", but if you read the rules then
"-rc1" is as OK as "-rc.1", the only difference being that the former
is *one* dot separated identifier, and the latter are *two* dot
separated identifiers, but both are OK according to the spec.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: EPEL 8 on RHEL 8.1 Beta

[Stephen John Smoogen]

On Thu, 1 Aug 2019 at 06:31, Phil Wyett  wrote:

> On Thu, 2019-08-01 at 11:16 +0530, Thomas Stephen Lee wrote:
> > Hi,
> >
> > Trying to install EPEL 8 on RHEL 8.1 Beta.
> >
> > I did
> >
> > $ yum install
> >
> https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/e/epel-release-8-1.noarch.rpm
> >
> > and doing
> >
> > $ yum update
> >
> > gives the error
> >
> > failed to open: /var/cache/dnf/epel-
> > 7223eb0d0c06d046/repodata/78c05abe94a83354e9759eacd446d11a44df882d8c4
> > 5fbf74b147b09a7fd6c83-updateinfo.xml.zck
> >
> > Tried changing baseurl in /etc/yum.repos.d/epel.repo to
> >
> > https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64
> >
> > and
> >
> > https://dl.fedoraproject.org/pub/epel/testing/8/Everything/x86_64
> >
> > both give the same error
> >
> > Kindly check.
> >
> > thanks
> >
> > --
> > Lee
>
> Hi,
>
> I get errors also.
>
> I would also query why the EPEL-7 gpg key is in the package and a new
> one for 8 has not been used?
>
>
I may have made a mistake in this package. I was going to update things to
a final state before we announced.




> Regards
>
> Phil
>
> --
> *** Playing the game for the games sake. ***
>
> IRC: kathenas
> Twitter: kathenasorg
> Website: https://kathenas.org
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: EPEL 8 on RHEL 8.1 Beta

[Stephen John Smoogen]

On Thu, 1 Aug 2019 at 01:47, Thomas Stephen Lee  wrote:

> Hi,
>
> Trying to install EPEL 8 on RHEL 8.1 Beta.
>
> I did
>
> $ yum install
> https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/e/epel-release-8-1.noarch.rpm
>
> and doing
>
> $ yum update
>
> gives the error
>
> failed to open:
> /var/cache/dnf/epel-7223eb0d0c06d046/repodata/78c05abe94a83354e9759eacd446d11a44df882d8c45fbf74b147b09a7fd6c83-updateinfo.xml.zck
>
>
Thanks for testing something that we have not announced as ready. I am not
sure why zchunk is being used here. You have found a bunch of things we
were going to be testing today. [And no we do not have a way to test this
without putting it on the download servers.. ]


-- 
Stephen J Smoogen.
___
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: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module

[Stephen Gallagher]

On Thu, Aug 1, 2019 at 6:57 AM Matus Honek  wrote:
>
> On Wed, Jul 31, 2019 at 4:57 PM Stephen Gallagher  wrote:
> >
> > On Tue, Jul 23, 2019 at 8:45 AM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/OpenLDAPwithBerkleyDBasModule
> > >
> > > == Summary ==
> > > Change the ''openldap-servers'' package so that BDB and HDB backends
> > > are required to be dynamically loaded.
> > >
> > > == Owner ==
> > > * Name: [[User:mhonek| Matus Honek]]
> > > * Email: mhonek (at) redhat (dot) com
> > >
> >
> > ...
> >
> > > == Upgrade/compatibility impact ==
> > > Server using BDB or HDB backends without modified configuration would
> > > fail to start. See ''User Experience'' section for more information.
> > >
> >
> > Is this avoidable or do you consider it desirable? Is there any harm
> > in shipping a default configuration that does the loadmodule for both
> > deprecated backends?
>
> The default configuration is shipped only when the package is newly
> installed. Given the BDB/HDB should not be used there is no point in
> pre-loading these in new instalments.
>

Understood.

> >
> > My guess here is that you want this to be an explicit breakage to help
> > users learn that the backend is no longer supported. If that's the
> > case, I'd like to see that spelled out in the Change.
>
> Correct. I thought this was put clearly but I sure can improve this.
> Would be spelling this in Detailed Description section acceptable?

Yes, please.

>
> >
> > Do any tools exist to simplify the conversion to MDB? Can this be automated?
>
> I am not aware of any such tools. Numerous demands on upstream were
> always responded with more-or-less what I put in the section
> describing the conversion. If any errors are encountered during the
> process they need to be understood and then fixed manually.
>
> Automatic conversion would be far from trivial (and possibly
> load-intensive depending on sizes). There are two types of
> configuration (plaintext and "the more complicated one"). A server may
> have several instances of backends. Each backend type has its own
> configuration specifics (MDB being easier but still a "human guess"
> should be made to configure the expected size of it). Not rarely users
> put configuration into various locations which are not guessable
> automatically at all. Additionally, users should ideally see the
> possible errors during the process of conversion and verify the data
> has not broken.
>
> One relatively simple thing to provide would be a pre-run script that
> would disallow running the slapd's systemd service if the
> configuration contains BDB/HDB instances and the moduleload is not
> present, writing into journal clearly what happened and what needs to
> be done.
>

This would be highly desirable. It would go a long way towards helping
users understand the transition. Including a web link in the journal
message to a detailed conversion HOWTO would be ideal.

> This is not to give reasons not to automate the process, rather
> explain that understanding and thought needs to go into each
> instalment's conversion(s).

Sure, makes sense. Thank you for clarifying.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module

[Matus Honek]

On Wed, Jul 31, 2019 at 4:57 PM Stephen Gallagher  wrote:
>
> On Tue, Jul 23, 2019 at 8:45 AM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/OpenLDAPwithBerkleyDBasModule
> >
> > == Summary ==
> > Change the ''openldap-servers'' package so that BDB and HDB backends
> > are required to be dynamically loaded.
> >
> > == Owner ==
> > * Name: [[User:mhonek| Matus Honek]]
> > * Email: mhonek (at) redhat (dot) com
> >
>
> ...
>
> > == Upgrade/compatibility impact ==
> > Server using BDB or HDB backends without modified configuration would
> > fail to start. See ''User Experience'' section for more information.
> >
>
> Is this avoidable or do you consider it desirable? Is there any harm
> in shipping a default configuration that does the loadmodule for both
> deprecated backends?

The default configuration is shipped only when the package is newly
installed. Given the BDB/HDB should not be used there is no point in
pre-loading these in new instalments.

>
> My guess here is that you want this to be an explicit breakage to help
> users learn that the backend is no longer supported. If that's the
> case, I'd like to see that spelled out in the Change.

Correct. I thought this was put clearly but I sure can improve this.
Would be spelling this in Detailed Description section acceptable?

>
> Do any tools exist to simplify the conversion to MDB? Can this be automated?

I am not aware of any such tools. Numerous demands on upstream were
always responded with more-or-less what I put in the section
describing the conversion. If any errors are encountered during the
process they need to be understood and then fixed manually.

Automatic conversion would be far from trivial (and possibly
load-intensive depending on sizes). There are two types of
configuration (plaintext and "the more complicated one"). A server may
have several instances of backends. Each backend type has its own
configuration specifics (MDB being easier but still a "human guess"
should be made to configure the expected size of it). Not rarely users
put configuration into various locations which are not guessable
automatically at all. Additionally, users should ideally see the
possible errors during the process of conversion and verify the data
has not broken.

One relatively simple thing to provide would be a pre-run script that
would disallow running the slapd's systemd service if the
configuration contains BDB/HDB instances and the moduleload is not
present, writing into journal clearly what happened and what needs to
be done.

This is not to give reasons not to automate the process, rather
explain that understanding and thought needs to go into each
instalment's conversion(s).
-- 
Matúš Honěk
Software Engineer
Red Hat Czech
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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

[Bug 1734372] perl-Catalyst-Controller-HTML-FormFu-2.04-6.fc31 FTBFS: Failed test 'GET http://localhost/basic/formconfig' at t/01basic-formconfig.t line 11

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Catalyst-Controller-HT
   ||ML-FormFu-2.04-6.fc31
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |ppi...@redhat.com
Last Closed||2019-08-01 10:30:56



--- Comment #4 from Petr Pisar  ---
Rebuilt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL 8 on RHEL 8.1 Beta

[Phil Wyett]

On Thu, 2019-08-01 at 11:16 +0530, Thomas Stephen Lee wrote:
> Hi,
> 
> Trying to install EPEL 8 on RHEL 8.1 Beta.
> 
> I did
> 
> $ yum install 
> https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/e/epel-release-8-1.noarch.rpm
> 
> and doing
> 
> $ yum update 
> 
> gives the error
> 
> failed to open: /var/cache/dnf/epel-
> 7223eb0d0c06d046/repodata/78c05abe94a83354e9759eacd446d11a44df882d8c4
> 5fbf74b147b09a7fd6c83-updateinfo.xml.zck
> 
> Tried changing baseurl in /etc/yum.repos.d/epel.repo to
> 
> https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64
> 
> and
> 
> https://dl.fedoraproject.org/pub/epel/testing/8/Everything/x86_64
> 
> both give the same error
> 
> Kindly check.
> 
> thanks
> 
> --
> Lee

Hi,

I get errors also.

I would also query why the EPEL-7 gpg key is in the package and a new
one for 8 has not been used?

Regards

Phil

-- 
*** Playing the game for the games sake. ***

IRC: kathenas
Twitter: kathenasorg
Website: https://kathenas.org


signature.asc
Description: This is a digitally signed message part
___
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: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Dave Love wrote:
> I forget the details, but libxsmm is something that depends on an
> instruction introduced with SSE3, and is a good example of portable
> performance engineering over a wide range of (x86_64) processors.

According to the documentation, libxsmm actually also supports a 
generic/SSE2 code path (LIBXSMM_X86_GENERIC), with runtime detection. So I 
do not see a valid reason to require SSE3 in libxsmm.

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

Re: [Rust] Rust applications & i686

[Matthew Miller]

On Sun, Jul 28, 2019 at 05:12:17PM +0200, Igor Gnatenko wrote:
> So that now i686 is no longer exists (I mean as an image), is there
> reason to produce i686 binaries for applications written in Rust? That
> also would mean we would stop testing i686 as a platform for crates,
> but I honestly love this because very often builds fail due to LLVM
> OOM.

Yeah, I don't see much value in pre-built i686 application binaries.

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

Re: systemd-243-rc1

[Nico Kadel-Garcia]

On Thu, Aug 1, 2019 at 4:16 AM Fabio Valentini  wrote:

> So ... prerelease versions are usually tagged with an "-rc1" suffix
> (or similar), which is a valid value for git tags, but RPM doesn't
> allow versions to contain hyphens.
> In RPM versions, prereleases can be tagged with an "~rc1" suffix (or
> similar), which does exactly the right thing for version comparisons
> in RPM, but is not a valid value for a git tag.

It's also not following semver. Semver numbering, which is shown by
the numbering of semver releases at https://semver.org/,  would be
"-rc.1".

Also not that there are many, many projects which do not follow this
semver rule and would use "rc1" without any dash whatsoever. Samba is
an example, and has used such numbering for decades.

With all that said, this is a "what color is the bikeshed" argument.
Let's leave alone the people using git, although a bit oddly, and let
them focus on the actual work.

> Since these things are both the case, a simple 1:1 mapping from "-" to
> "~" (and even back) is exactly correct.
> So I think the systemd.spec is doing exactly the right thing here.
>
> The only issue I see is the arbitrary (?) restriction that git tags
> cannot contain the tilde character.
> Or is that there for filesystem compatibility, because tags are just files?
>
> Fabio

I
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Muneendra

[Matthew Miller]

On Thu, Aug 01, 2019 at 12:32:06PM +0530, Muneendra Kumar M via devel wrote:
> My name is Muneendra Kumar, I’m working for Broadcom . I have been working
> in Linux for more than 15 years and submitted couple of commits to open
> source.

Hi, and welcome! I'm definitely glad to see more open source involvement
from Broadcom. Let me know if you get stuck on anything and I'll make sure
we find someone to help!

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

Re: systemd-243-rc1

[Matthew Miller]

On Wed, Jul 31, 2019 at 09:05:01PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Also, when people are running an -rc kernel, some issues are expected.
> In the beginning it wasn't even clear if the change in the kernel will
> be reverted or not.

Well, also -- systemd-networkd isn't the default for anything Fedora
releases, is it? We looked at it for the Cloud image but decided to stick
with NetworkManager. And, even where people have decided they want to go
with networkd on customized systems, NM is a reasonable fallback. So, I
would *expect* this to not be high priority. Yes, sure, include a fix when
available, but I don't see this as a particular crisis. And there are plenty
of actual crises, so


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

[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31: File not found: /builddir/build/BUILDROOT/fusioninventory-agent-2.5.1-3.fc31.arm/etc/fusioninventory/proxy-server-plugin.cfg

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
Summary|fusioninventory-agent:  |fusioninventory-agent:
   |FTBFS in Fedora rawhide/f31 |FTBFS in Fedora
   ||rawhide/f31: File not
   ||found:
   ||/builddir/build/BUILDROOT/f
   ||usioninventory-agent-2.5.1-
   ||3.fc31.arm/etc/fusioninvent
   ||ory/proxy-server-plugin.cfg



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: systemd-243-rc1

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 01, 2019 at 10:14:06AM +0200, Fabio Valentini wrote:
> On Thu, Aug 1, 2019 at 9:48 AM Lennart Poettering  
> wrote:
> >
> > On Mi, 31.07.19 20:52, Fedora Development ML 
> > (devel@lists.fedoraproject.org) wrote:
> >
> > > Instead, as Lennart explained, systemd has no strong release
> > > discipline. systemd didn't provide anyone a fixed version (requiring
> > > fishing the fix in its git, and wasting integrator time). And when,
> > > finally, systemd makes a new release, it does not even use integrator
> > > and automation-friendly semver numbering, but the awful human-oriented
> > > rcx labelling, that requires manual mapping to be understood by
> > > automation (wasting yet more integrator time).
> >
> > Hmm? "rc" releases are testing releases, beta releases if you so
> > will. They aren't something to deploy in stable distros. They are
> > right for rawhide-style distros, and that's where it has been uploaded
> > to.
> >
> > I mean, we don't do semver in systemd, because we only have one stream
> > of official releases. However, note that what semver says about
> > "pre-release" versions (which is what our rc thing is) is actually
> > pretty much in line with what we do:
> >
> > "A pre-release version MAY be denoted by appending a hyphen
> > and a series of dot separated identifiers immediately
> > following the patch version. Identifiers MUST comprise only
> > ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
> > NOT be empty. Numeric identifiers MUST NOT include leading
> > zeroes. Pre-release versions have a lower precedence than the
> > associated normal version. A pre-release version indicates
> > that the version is unstable and might not satisfy the
> > intended compatibility requirements as denoted by its
> > associated normal version. Examples: 1.0.0-alpha,
> > 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92"
> >
> > (Quote from https://semver.org/#spec-item-9)
> >
> > So, if you so will, we actually do follow semver on this part. We
> > don't follow it on the minor/patch parts, because we only do one stream
> > of releases, but on the "rc" part we are actually in line with the
> > spec, afaics.
> 
> So ... prerelease versions are usually tagged with an "-rc1" suffix
> (or similar), which is a valid value for git tags, but RPM doesn't
> allow versions to contain hyphens.
> In RPM versions, prereleases can be tagged with an "~rc1" suffix (or
> similar), which does exactly the right thing for version comparisons
> in RPM, but is not a valid value for a git tag.
> 
> Since these things are both the case, a simple 1:1 mapping from "-" to
> "~" (and even back) is exactly correct.
> So I think the systemd.spec is doing exactly the right thing here.
> 
> The only issue I see is the arbitrary (?) restriction that git tags
> cannot contain the tilde character.
> Or is that there for filesystem compatibility, because tags are just files?

That's because '~' means first parent in git-versionspec-lang, and
'~n' means n-th ancestor (in the stright line).
So nnn~1 would mean parent of nnn, and would be ambiguous. nnn~rc1
has no meaning in git, but I still think it'd be madness to allow ~
in git tags.

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

Re: python2->python3 mass rebuild and auto tools

[Miro Hrončok]

On 01. 08. 19 4:43, Steve Grubb wrote:

Audit. But is seems that autotools shoul hard code the old sematics so that
all packages do the right thing. It seems that python3 equivalents have been
introduced. They do the right thing with the python migration. But there are
things that are expectd to defaulto python 2.



https://src.fedoraproject.org/rpms/audit/pull-request/4

Autotools usually already does the right thing, aka choosing python2 if it 
cannot find python. Using "python" in Fedora packages is forbidden anyway.



Should they be hardcoded to mean python2 in autotools and swig?


No. That was kinda the point of this change: "python" means Python 3.

Python 2 is deprecated and will be retired.

Of course. But there is a legacy pyexec_PYTHON and there is a py3exec_PYTHON.
What this change means is that they are one in the same. I do not think that
is the intention. Because...is there a py2exec_PYTHON? I do not find it
grepping my system. And this would need to have been advanced years ago, not
today.


I don't know if there is py2exec_PYTHON. But autotools is no magic (although it 
might appear as such), it just uses the commands available. "python" command 
being forbidden in Fedora packages and "python" command meaning Python 3 have 
been advocated for years.


https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

I'm sorry if that made you packaging work more complicated. But I just don't 
agree that we should make exceptions here. (Nevertheless I would have no idea 
how to do that, since every project ships their own pile of autotools that may 
or may not use the "python" command that way or another).


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

Re: Join the new Minimization Team

[Adam Samalik]

I've already done some experiments with that. I used multi-stage builds
with podman, but it's the same in principle. And yes, the sizes are
smaller. What was interesting though that some additional packages (ones
that wouldn't appear in the images using the Fedora base image) has been
dragged in as dependencies. Some of them are even related to hardware. (See
the report [1] and the github repo [2].)

So that might be one area to focus on — to make sure that these "from
scratch" installations don't drag unnecessary stuff.


[1] https://asamalik.fedorapeople.org/container-randomness/report.html
[2] https://github.com/asamalik/container-randomness



On Tue, Jul 30, 2019 at 9:52 PM Daniel Walsh  wrote:

> If you want small images, just use buildah.
>
> ctr=$(buildah from scratch)
> mnt=$(buildah mount $ctr)
> COPY/DnF/make install into $mnt
> buildah config ... $ctr
> buildah commit $ctr NEWIMAGE
> buildah push NEWIMAGE CONTAINERREGGISTY...
>
> If you want to build off of base images, you can probably create them with
> buildah also.
>
> On 7/30/19 12:05 PM, Christian Glombek wrote:
>
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual package
> manager inside. You just have the container, mount the config, and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely a
> topic of overall interest!
>
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
>
> Christian Glombek
>
> Associate Software Engineer
>
> Red Hat GmbH 
>
> 
>
> cglom...@redhat.com 
> 
>
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
>
>
>
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  wrote:
>
>> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik 
>> wrote:
>> >
>> > Hi everyone!
>> >
>> > I'm starting a Minimization Objective [1] focusing on minimising the
>> installation size of some of the popular apps, runtimes, and other pieces
>> of software in Fedora.
>> >
>> > And there is a new Minimization Team [2] forming. Members of the team
>> will consult and work with Fedora maintainers, develop tooling and
>> services, generate reports showing the status of the Fedora ecosystem and a
>> comparison with other ecosystems, etc. The goal is to build an environment
>> where it's easy for our maintainers to keep things small over time, it's
>> not just a one-off effort. Please see the Action Plan [3] for more details.
>> >
>> > Want to become a member? Let me know!
>> >
>> > Cheers!
>> > Adam
>> >
>> > [1] https://docs.fedoraproject.org/en-US/minimization/
>> > [2] https://docs.fedoraproject.org/en-US/minimization/team/
>> > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>> >
>>
>> I'm interested, but not just for minimization for the sake of it. We
>> need to be thoughtful about how we are changing the dependency tree.
>>
>>
>>
>> --
>> 真実はいつも一つ！/ 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
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe 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
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: 

Re: systemd-243-rc1

[Fabio Valentini]

On Thu, Aug 1, 2019 at 9:48 AM Lennart Poettering  wrote:
>
> On Mi, 31.07.19 20:52, Fedora Development ML (devel@lists.fedoraproject.org) 
> wrote:
>
> > Instead, as Lennart explained, systemd has no strong release
> > discipline. systemd didn't provide anyone a fixed version (requiring
> > fishing the fix in its git, and wasting integrator time). And when,
> > finally, systemd makes a new release, it does not even use integrator
> > and automation-friendly semver numbering, but the awful human-oriented
> > rcx labelling, that requires manual mapping to be understood by
> > automation (wasting yet more integrator time).
>
> Hmm? "rc" releases are testing releases, beta releases if you so
> will. They aren't something to deploy in stable distros. They are
> right for rawhide-style distros, and that's where it has been uploaded
> to.
>
> I mean, we don't do semver in systemd, because we only have one stream
> of official releases. However, note that what semver says about
> "pre-release" versions (which is what our rc thing is) is actually
> pretty much in line with what we do:
>
> "A pre-release version MAY be denoted by appending a hyphen
> and a series of dot separated identifiers immediately
> following the patch version. Identifiers MUST comprise only
> ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
> NOT be empty. Numeric identifiers MUST NOT include leading
> zeroes. Pre-release versions have a lower precedence than the
> associated normal version. A pre-release version indicates
> that the version is unstable and might not satisfy the
> intended compatibility requirements as denoted by its
> associated normal version. Examples: 1.0.0-alpha,
> 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92"
>
> (Quote from https://semver.org/#spec-item-9)
>
> So, if you so will, we actually do follow semver on this part. We
> don't follow it on the minor/patch parts, because we only do one stream
> of releases, but on the "rc" part we are actually in line with the
> spec, afaics.

So ... prerelease versions are usually tagged with an "-rc1" suffix
(or similar), which is a valid value for git tags, but RPM doesn't
allow versions to contain hyphens.
In RPM versions, prereleases can be tagged with an "~rc1" suffix (or
similar), which does exactly the right thing for version comparisons
in RPM, but is not a valid value for a git tag.

Since these things are both the case, a simple 1:1 mapping from "-" to
"~" (and even back) is exactly correct.
So I think the systemd.spec is doing exactly the right thing here.

The only issue I see is the arbitrary (?) restriction that git tags
cannot contain the tilde character.
Or is that there for filesystem compatibility, because tags are just files?

Fabio

> > So, the relevancy to Fedora, that Lennart did not see, is that all this
> > lack of care, results in longer breakage time in Fedora.
>
> Well, I am pretty sure (like most RPMs) ours could use more love and
> dedication, but there are only so many people working on this and only
> 24h in a day. If you feel it needs more love, then volunteer, and
> help, or find somebody who is willing to.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe 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: Join the new Minimization Team

[Adam Samalik]

Thanks all of you who want to join! Welcome!

I'll add you to the team page [1] and follow up with some organisational
stuff — we might want a weekly meeting to sync, etc. I proposed some
communication channels on the team page as well, let me know if that works
for you.

Cheers!
Adam

[1] https://docs.fedoraproject.org/en-US/minimization/team/

On Tue, Jul 30, 2019 at 3:20 PM Adam Samalik  wrote:

> Hi everyone!
>
> I'm starting a Minimization Objective [1] focusing on minimising the
> installation size of some of the popular apps, runtimes, and other pieces
> of software in Fedora.
>
> And there is a new Minimization Team [2] forming. Members of the team will
> consult and work with Fedora maintainers, develop tooling and services,
> generate reports showing the status of the Fedora ecosystem and a
> comparison with other ecosystems, etc. The goal is to build an environment
> where it's easy for our maintainers to keep things small over time, it's
> not just a one-off effort. Please see the Action Plan [3] for more details.
>
> Want to become a member? Let me know!
>
> Cheers!
> Adam
>
> [1] https://docs.fedoraproject.org/en-US/minimization/
> [2] https://docs.fedoraproject.org/en-US/minimization/team/
> [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Authentication in fedpkg

[Björn Persson]

Stephen John Smoogen wrote:
>Changes in
>authentication methods require a lot of dedicated work because it affects
>all workflows somewhere.. and because it would mean so much downtime.. it
>has never gotten the resources in time and engineers to do.

Obviously replacing an authentication protocol is a big change that
affects many things, but some smaller improvements could make the user
interface suck less. Asking for a password instead of just failing is
an isolated client-side change. It would take some programming work of
course, but little or no coordination between different components.
Authenticating in advance with kinit would continue to work, so nobody's
workflow would break.

Björn Persson


pgpkQhOJXkjw2.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: systemd-243-rc1

[Lennart Poettering]

On Mi, 31.07.19 20:52, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> Instead, as Lennart explained, systemd has no strong release
> discipline. systemd didn't provide anyone a fixed version (requiring
> fishing the fix in its git, and wasting integrator time). And when,
> finally, systemd makes a new release, it does not even use integrator
> and automation-friendly semver numbering, but the awful human-oriented
> rcx labelling, that requires manual mapping to be understood by
> automation (wasting yet more integrator time).

Hmm? "rc" releases are testing releases, beta releases if you so
will. They aren't something to deploy in stable distros. They are
right for rawhide-style distros, and that's where it has been uploaded
to.

I mean, we don't do semver in systemd, because we only have one stream
of official releases. However, note that what semver says about
"pre-release" versions (which is what our rc thing is) is actually
pretty much in line with what we do:

"A pre-release version MAY be denoted by appending a hyphen
and a series of dot separated identifiers immediately
following the patch version. Identifiers MUST comprise only
ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
NOT be empty. Numeric identifiers MUST NOT include leading
zeroes. Pre-release versions have a lower precedence than the
associated normal version. A pre-release version indicates
that the version is unstable and might not satisfy the
intended compatibility requirements as denoted by its
associated normal version. Examples: 1.0.0-alpha,
1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92"

(Quote from https://semver.org/#spec-item-9)

So, if you so will, we actually do follow semver on this part. We
don't follow it on the minor/patch parts, because we only do one stream
of releases, but on the "rc" part we are actually in line with the
spec, afaics.

> So, the relevancy to Fedora, that Lennart did not see, is that all this
> lack of care, results in longer breakage time in Fedora.

Well, I am pretty sure (like most RPMs) ours could use more love and
dedication, but there are only so many people working on this and only
24h in a day. If you feel it needs more love, then volunteer, and
help, or find somebody who is willing to.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Rolling out Phase I of rawhide package gating

[Nicolas Mailhot via devel]

Le jeudi 01 août 2019 à 00:27 -0700, Samuel Sieb a écrit :
> On 7/31/19 11:41 PM, Nicolas Mailhot via devel wrote:
> > Le mercredi 31 juillet 2019 à 16:10 -0700, Brian C. Lane a écrit :
> > > If so you can pass
> > > inst.noverifyssl to anaconda to tell it to ignore the error but
> > > still
> > > use https.
> > 
> > Thanks for the suggestion, I had forgotten about it. Is it possible
> > to
> > do that manually without a kickstart? Fot that installation
> > workflow we
> > start from a minimal unmodified install, and customize it in a
> > later
> > stage.
> 
> You can add that to the kernel command line when you boot.

Sor, from grub, before the keyboard layout is properly set up. Ok, not
too convenient, but a lot better than nothing. Thank you.

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

Re: systemd-243-rc1

[Nicolas Mailhot via devel]

Le mercredi 31 juillet 2019 à 21:05 +, Zbigniew Jędrzejewski-Szmek
a écrit :
> On Wed, Jul 31, 2019 at 08:52:36PM +0200, Nicolas Mailhot via devel
> wrote:


> > And when,
> > finally, systemd makes a new release, it does not even use
> > integrator
> > and automation-friendly semver numbering, but the awful human-
> > oriented
> > rcx labelling, that requires manual mapping to be understood by
> > automation (wasting yet more integrator time).
> 
> Nah, not really. In systemd spec:
> Version: 243~rc1
> %global github_version %(c=%{version}; echo ${c}|tr '~' '-')
> and that's all the mapping needed. Things just work ;)

Till someone decides a preX version is prettier… After all Linus
Torvalds does it, what can grow wrong¹

Broken versionning is broken versionning, rpm is flexible enough to
allow complex macro use to salvage anything, but upstream should not
force this kind of salvaging downstream.

¹ Linus is so utterly unconcerned with getting versionning right he
didn't even bother with version objects in git. That is why v prefixes
have started sproutting before versions values with no rhyme nor
reason, it's leakage of the workaround used by git people to try to
identify what git tags are actual versions


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

Re: Rolling out Phase I of rawhide package gating

[Samuel Sieb]

On 7/31/19 11:41 PM, Nicolas Mailhot via devel wrote:

Le mercredi 31 juillet 2019 à 16:10 -0700, Brian C. Lane a écrit :

If so you can pass
inst.noverifyssl to anaconda to tell it to ignore the error but still
use https.


Thanks for the suggestion, I had forgotten about it. Is it possible to
do that manually without a kickstart? Fot that installation workflow we
start from a minimal unmodified install, and customize it in a later
stage.


You can add that to the kernel command line when you boot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Muneendra

[Muneendra Kumar M via devel]

Greetings,



My name is Muneendra Kumar, I’m working for Broadcom . I have been working
in Linux for more than 15 years and submitted couple of commits to open
source.

I need to submit a new package in the FEDORA which I am working on which is
completely based on FC(fibre channel).

I've never made any kind of packages before, so please bear with me if I
make any mistakes.



Regards,

Muneedra.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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: Rolling out Phase I of rawhide package gating

[Nicolas Mailhot via devel]

Le mercredi 31 juillet 2019 à 16:10 -0700, Brian C. Lane a écrit :
> On Wed, Jul 31, 2019 at 09:05:21PM +0200, Nicolas Mailhot via devel
> wrote:
> > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a
> > écrit :
> > > > > > > > "KF" == Kevin Fenzi  writes:
> > > 
> > > KF> * If you use metalinks, rpm signatures are just gravy on top,
> > > in
> > > the
> > > KF> end you are still just trusing SSL CA's.
> > > 
> > > Only if you trust every mirror to always serve authentic content.
> > 
> > And, just to provide another data point, we tried this month to
> > make
> > the network install iso talk to https dnf repos (a reposync of
> > fedora
> > devel x86_64, without x86 packages, because we don't have the
> > storage
> > budget to mirror 32 bit packages we don't have the use for them
> > anyway). The repos themselves worked fine from installed systems.
> > But,
> > anaconda refused to use them, till they were re-exposed in plain
> > un-
> > secured http.
> 
> It's odd that they would work from an installed system and not
> anaconda.
> Are you using a self-signed cert on them?

No, a proper public cert, that even Firefox accepts without grumbling
(not an easy thing to manage those days).

> If so you can pass
> inst.noverifyssl to anaconda to tell it to ignore the error but still
> use https.

Thanks for the suggestion, I had forgotten about it. Is it possible to
do that manually without a kickstart? Fot that installation workflow we
start from a minimal unmodified install, and customize it in a later
stage.

Regards,

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

Re: Rolling out Phase I of rawhide package gating

[Nicolas Mailhot via devel]

Le mercredi 31 juillet 2019 à 13:34 -0700, Kevin Fenzi a écrit :
> On 7/31/19 12:05 PM, Nicolas Mailhot via devel wrote:
> > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a
> > écrit :
> > > > > > > > "KF" == Kevin Fenzi  writes:
> > > 
> > > KF> * If you use metalinks, rpm signatures are just gravy on top,
> > > in
> > > the
> > > KF> end you are still just trusing SSL CA's.
> > > 
> > > Only if you trust every mirror to always serve authentic content.
> > 
> > And, just to provide another data point, we tried this month to
> > make
> > the network install iso talk to https dnf repos (a reposync of
> > fedora
> > devel x86_64, without x86 packages, because we don't have the
> > storage
> > budget to mirror 32 bit packages we don't have the use for them
> > anyway). The repos themselves worked fine from installed systems.
> > But,
> > anaconda refused to use them, till they were re-exposed in plain
> > un-
> > secured http.
> 
> Any errors? Bug filed? as long as the certs were valid/normal certs,
> there should not be any reason that wouldn't work I wouldn't think.

A bug will be filed yes (we gave up on managing to make it work
yesterday). An error would have been mighty fine, IIRC there was
nothing useful returned by anaconda, just the same behaviour as if one
had made a mistake in the URL, that anaconda gave up on after a
timeout.

Regards,

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