Re: Non-responsive maintainer: devrim (gdal, proj, geos)

[Tom Hughes]

On 12/02/2020 07:29, Devrim Gündüz wrote:


Hi Sandro (and Tom),

On Wed, 2020-02-12 at 00:01 +, Tom Hughes wrote:

I've attempted to contact devrim directly 2019-11-27 offering to take
care of updating these packages, but received no reply. My recent PR to
update gdal [2] also received no reply.


...and postgis as well which is FTBFS after the mass rebuild and already
needed rebuilding for dependencies which is blocking a bunch of stuff.


Please keep me as co-maintainer. I'm already maintaining these packages in the
upstream repository (https://yum.PostgreSQL.org) with more options there, and
I'd like to keep things in sync as much as possible.


I'd just like a fixed build so I can rebuild all my FTBFS things which
failed because of postgis... I don't care who does it...

Tom

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

Fedora-Cloud-30-20200212.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Re: deduplicating noarch subpackages

[Nicolas Mailhot via devel]

Le 2020-02-12 01:21, Josh Stone a écrit :


The problem is that those cross-target libraries built by two different
host arches will have different metadata hashes in the filenames,
because the hash includes the full "rustc -Vv" version output, 
including

the host triple.


koji is doing the right thing. For audits and QA checks a noarch package 
must be produced exactly the same ways regardless of the arch of the 
builder.


Either recording the triplet is meaningless, and you should inhibit 
it(the same way reproducible builds inhibit date recording), or it 
serves a purpose, and your builds are archfull by construction.


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

[Peter Robinson]

> > Hi,
> >
> > This package has been deprecated for a very long time (a decade?).
> > Nothing should be using it anymore. Either use GDBus via PyGObject, or
> > another D-Bus client library instead. If anybody wants to take this
> > package, I'm sure that could be arranged. Working out a retirement plan
> > would also be a good idea, though if there are too many rdeps it might
> > not be practical.
> >
>
> This is probably not going to be workable:
>
> $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l
> 106
> $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc -l
> 3
>
> I don't think this was the library that was deprecated either. I'm
> pretty sure that was the libdbus-glib library, though this is
> unfortunately built on top of that.

I wonder how many of those are actual dependencies or ones that are
legacy where the package uses other method but the dependency remains.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Please, IMHO, resolve in some way the Samba MIT kerberos problem.

[Dario Lesca]

Il giorno mar, 11/02/2020 alle 21.35 +0200, Alexander Bokovoy ha
scritto:
> There are few more missing parts here and there that need to
> beimplemented. They might affect some use cases and not others. At
> thispoint, I'd suggest to open bugs as you see them, this will help
> us toclarify more use cases and see what can be supported or not
> (yet).

There are a list of this missing, failings or simply testing
parts  that I can check and report on bugzilla?

For now, the only problem I know on my little network is the w2w now
solved.

In my test environment also the update f-31->f-32rawhide, aka samba
4.11.6 -> samba-4.12rc2 it worked well without problem.
Let me know and I will try to verify.

Many thanks


-- Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: devrim (gdal, proj, geos)

[Sandro Mani]

Hi Devrim


Please keep me as co-maintainer. I'm already maintaining these packages in the
upstream repository (https://yum.PostgreSQL.org) with more options there, and
I'd like to keep things in sync as much as possible.


Thanks for your reply. I read this as you being ok if I proceed with the 
updates? In this case, can you please add me to the packages (FAS: 
smani), namely to gdal, proj and geos, and postgis?


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

Re: dnf exit code

[Daniel Mach]

There seem to be 2 related problems:
1) Only the image on docker.io doesn't work. If you use 
registry.fedoraproject.org/fedora:rawhide, it works as expected.


2) Fedora infra is unreliable. When the image from 
registry.fedoraproject.org cannot be downloaded, there's a fallback to 
docker.io which contains a different image. Running the command several 
times in a row produces "random" results:



$ podman pull fedora:rawhide
Trying to pull registry.fedoraproject.org/fedora:rawhide...
...
a3689ffc0440236cbe0530e9ead8b76d0f601a33cd5ce08409d2d96d70abf56d


$ podman pull fedora:rawhide
Trying to pull registry.fedoraproject.org/fedora:rawhide...
...
a3689ffc0440236cbe0530e9ead8b76d0f601a33cd5ce08409d2d96d70abf56d


$ podman pull fedora:rawhide
Trying to pull registry.fedoraproject.org/fedora:rawhide...
  received unexpected HTTP status: 503 Service Temporarily Unavailable
Trying to pull registry.access.redhat.com/fedora:rawhide...
  name unknown: Repo not found
Trying to pull registry.centos.org/fedora:rawhide...
  manifest unknown: manifest unknown
Trying to pull docker.io/library/fedora:rawhide...
...
e13031c001a8b4a574e3088e2d1ab331d72d821804ccacdd41bf5662ae02cc98



Dne 12. 02. 20 v 0:37 Christoph Junghans napsal(a):

Hi,

I am getting an exit code 143 when running dnf in docker, example:
$ cat Dockerfile
FROM fedora:rawhide
RUN dnf install -y openmpi-devel
$ docker build .
...
Running scriptlet: systemd-245~rc1-2.fc32.x86_64  121/121
Running scriptlet: systemd-udev-245~rc1-2.fc32.x86_64
121/121The command '/bin/sh -c dnf install -y openmpi-devel' returned
a non-zero code: 143

Only on rawhide, f31 works fine, i.e.
$ cat Dockerfile
FROM fedora:31
RUN dnf install -y openmpi-devel
$ docker build .
Complete!
Removing intermediate container 85bb626aff58
  ---> e9a30f6992d7
Successfully built e9a30f6992d7

Any ideas?

Thanks,

Christoph



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Miro Hrončok]

On 12. 02. 20 1:31, Michael Catanzaro wrote:

Hi,


Hey, thanks for your reply. At least now I understand the situation better, yet 
IMHO we are not closer to get it fixed.


This package has been deprecated for a very long time (a decade?). Nothing 
should be using it anymore. Either use GDBus via PyGObject, or another D-Bus 
client library instead. If anybody wants to take this package, I'm sure that 
could be arranged. Working out a retirement plan would also be a good idea, 
though if there are too many rdeps it might not be practical.


This is news to me. The package does not indicate that in any way.

Neither does upstream docs: https://dbus.freedesktop.org/doc/dbus-python/

There are regular releases and the upstream response is very fast.

https://dbus.freedesktop.org/doc/dbus-python/news.html
https://gitlab.freedesktop.org/dbus/dbus-python/commits/master

I also could not found any announcement in Fedora channels about this.

I know a fair bit about deprecating and removing stuff from Fedora and one thing 
for sure, it requires a lot of coordination. However in this case, I'm not sure 
it is actually needed.


Ray's probably the "maintainer" because this package used to be important for 
GNOME. GNOME package maintainers don't normally read or respond to many bugs in 
Red Hat Bugzilla. There are orders of magnitude more bugs than can be dealt 
with, so ignoring all the downstream bugs is usually the only practical 
solution. We need some script to close all the incoming bugs and ask users to 
report upstream instead, where the bugs can plausibly be dealt with, except in 
the case of downstream packaging issues or bugs we need for blocker or FE 
process. Until someone takes the time to write a script, the bugs are just going 
to continue piling up.


This seems like an extremely hostile idea to me. I realize that if you get 
dozens bugzillas a day, it's probably too much to even triage, but autoclosing 
bugzillas redirecting to upstream or ignoring anything outright is just bad.


Most of the dbus-python bugzillas are about packaging problems (please update, 
backport, package differently...). Also, it's less than 1 Bugzilla per month. If 
the "maintainer" is not interested in being an actual maintainer, I suppose 
orphaning the package is the best course of action, not just ignoring it.


Although, in fairness, I suppose that usual explanation 
maybe doesn't apply when the default assignee is a defunct mailing list


To be fair: a "maintainer" who deliberately ignores all Bugzillas or a defunct 
mailing list -- both have the same outcome.


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

[Miro Hrončok]

On 12. 02. 20 2:40, Leigh Scott wrote:
I have updated dbus-python as cinnamon depends on it but I don't intend 
to maintain it again unless I have to.


Thanks for unblocking us now. However, I guess we still seek for a maintainer.

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

[Vojtěch Trefný]

On 2020-02-12 03:03, Neal Gompa wrote:
> On Tue, Feb 11, 2020 at 7:32 PM Michael Catanzaro  
> wrote:
>>
>> On Tue, Feb 11, 2020 at 11:37 pm, Miro Hrončok 
>> wrote:
>>> Since cca mid-2018 there was no reply from any maintainer in
>>> Bugzillas.
>>
>> Hi,
>>
>> This package has been deprecated for a very long time (a decade?).
>> Nothing should be using it anymore. Either use GDBus via PyGObject, or
>> another D-Bus client library instead. If anybody wants to take this
>> package, I'm sure that could be arranged. Working out a retirement plan
>> would also be a good idea, though if there are too many rdeps it might
>> not be practical.
>>
> 
> This is probably not going to be workable:
> 
> $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l
> 106
> $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc -l
> 3
> 
> I don't think this was the library that was deprecated either. I'm
> pretty sure that was the libdbus-glib library, though this is
> unfortunately built on top of that.
> 

From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS:

"The deprecated dbus-glib library is no longer required. A bundled copy
  of its main loop integration code is included instead."

We are using dbus-python in some of our packages (mostly test suite for
UDisks and some helper scripts etc.). From the git repo it looks like
the project is actively maintained and latest release is less than month
old so I think there is no reason to retire dbus-python.
If nobody wants to maintain this package I can do that. It's definitely
easier than rewriting our code to something else.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Alexander Bokovoy]

On ke, 12 helmi 2020, Peter Robinson wrote:

> Hi,
>
> This package has been deprecated for a very long time (a decade?).
> Nothing should be using it anymore. Either use GDBus via PyGObject, or
> another D-Bus client library instead. If anybody wants to take this
> package, I'm sure that could be arranged. Working out a retirement plan
> would also be a good idea, though if there are too many rdeps it might
> not be practical.
>

This is probably not going to be workable:

$ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l
106
$ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc -l
3

I don't think this was the library that was deprecated either. I'm
pretty sure that was the libdbus-glib library, though this is
unfortunately built on top of that.


I wonder how many of those are actual dependencies or ones that are
legacy where the package uses other method but the dependency remains.


FreeIPA depends on python3-dbus for quite a lot of its essential
functionality. I filed a ticket https://pagure.io/freeipa/issue/8194 to
eventually migrate to GIO-based approach. But I don't think that will
'fix' the dependencies for the rest.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Vojtěch Trefný]

On 2020-02-12 11:01, Vojtěch Trefný wrote:
> 
> 
> On 2020-02-12 03:03, Neal Gompa wrote:
>> On Tue, Feb 11, 2020 at 7:32 PM Michael Catanzaro  
>> wrote:
>>>
>>> On Tue, Feb 11, 2020 at 11:37 pm, Miro Hrončok 
>>> wrote:
 Since cca mid-2018 there was no reply from any maintainer in
 Bugzillas.
>>>
>>> Hi,
>>>
>>> This package has been deprecated for a very long time (a decade?).
>>> Nothing should be using it anymore. Either use GDBus via PyGObject, or
>>> another D-Bus client library instead. If anybody wants to take this
>>> package, I'm sure that could be arranged. Working out a retirement plan
>>> would also be a good idea, though if there are too many rdeps it might
>>> not be practical.
>>>
>>
>> This is probably not going to be workable:
>>
>> $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l
>> 106
>> $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc -l
>> 3
>>
>> I don't think this was the library that was deprecated either. I'm
>> pretty sure that was the libdbus-glib library, though this is
>> unfortunately built on top of that.
>>
> 
> From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS:
> 
> "The deprecated dbus-glib library is no longer required. A bundled copy
>   of its main loop integration code is included instead."
> 
> We are using dbus-python in some of our packages (mostly test suite for
> UDisks and some helper scripts etc.). 

Actually lvmdbusd is using dbus-python so Anaconda indirectly depends on
it (Blivet is using LVM DBus API for LVM management).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Miro Hrončok]

On 12. 02. 20 11:01, Vojtěch Trefný wrote:

This package has been deprecated for a very long time (a decade?).
Nothing should be using it anymore. Either use GDBus via PyGObject, or
another D-Bus client library instead. If anybody wants to take this
package, I'm sure that could be arranged. Working out a retirement plan
would also be a good idea, though if there are too many rdeps it might
not be practical.


I don't think this was the library that was deprecated either. I'm
pretty sure that was the libdbus-glib library, though this is
unfortunately built on top of that.



 From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS:

"The deprecated dbus-glib library is no longer required. A bundled copy
   of its main loop integration code is included instead."

We are using dbus-python in some of our packages (mostly test suite for
UDisks and some helper scripts etc.). From the git repo it looks like
the project is actively maintained and latest release is less than month
old so I think there is no reason to retire dbus-python.
If nobody wants to maintain this package I can do that. It's definitely
easier than rewriting our code to something else.


I agree that retiring this is premature. Thank you, Vojta, for volunteering.

Ray, could you please give this package to to FAS user "vtrefny"?

We can help with Python related problems if @python-sig group is added, although 
I am afraid that adding yet another group would simply increase the diffusion of 
responsibility.


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

[Neal Gompa]

On Wed, Feb 12, 2020 at 5:14 AM Miro Hrončok  wrote:
>
> On 12. 02. 20 11:01, Vojtěch Trefný wrote:
> >>> This package has been deprecated for a very long time (a decade?).
> >>> Nothing should be using it anymore. Either use GDBus via PyGObject, or
> >>> another D-Bus client library instead. If anybody wants to take this
> >>> package, I'm sure that could be arranged. Working out a retirement plan
> >>> would also be a good idea, though if there are too many rdeps it might
> >>> not be practical.
> >>>
> >> I don't think this was the library that was deprecated either. I'm
> >> pretty sure that was the libdbus-glib library, though this is
> >> unfortunately built on top of that.
> >>
> >
> >  From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS:
> >
> > "The deprecated dbus-glib library is no longer required. A bundled copy
> >of its main loop integration code is included instead."
> >
> > We are using dbus-python in some of our packages (mostly test suite for
> > UDisks and some helper scripts etc.). From the git repo it looks like
> > the project is actively maintained and latest release is less than month
> > old so I think there is no reason to retire dbus-python.
> > If nobody wants to maintain this package I can do that. It's definitely
> > easier than rewriting our code to something else.
>
> I agree that retiring this is premature. Thank you, Vojta, for volunteering.
>
> Ray, could you please give this package to to FAS user "vtrefny"?
>
> We can help with Python related problems if @python-sig group is added, 
> although
> I am afraid that adding yet another group would simply increase the diffusion 
> of
> responsibility.
>

I pretty much live and breathe by this library for dnfdaemon, so I'm
also willing to co-maintain it too.



-- 
真実はいつも一つ！/ 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

Fedora-Cloud-31-20200212.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

[Martin Kolman]

- Original Message -
> From: "Vojtěch Trefný" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, February 12, 2020 11:07:29 AM
> Subject: Re: Seeking the maintainer of dbus-python
> 
> 
> 
> On 2020-02-12 11:01, Vojtěch Trefný wrote:
> > 
> > 
> > On 2020-02-12 03:03, Neal Gompa wrote:
> >> On Tue, Feb 11, 2020 at 7:32 PM Michael Catanzaro 
> >> wrote:
> >>>
> >>> On Tue, Feb 11, 2020 at 11:37 pm, Miro Hrončok 
> >>> wrote:
>  Since cca mid-2018 there was no reply from any maintainer in
>  Bugzillas.
> >>>
> >>> Hi,
> >>>
> >>> This package has been deprecated for a very long time (a decade?).
> >>> Nothing should be using it anymore. Either use GDBus via PyGObject, or
> >>> another D-Bus client library instead. If anybody wants to take this
> >>> package, I'm sure that could be arranged. Working out a retirement plan
> >>> would also be a good idea, though if there are too many rdeps it might
> >>> not be practical.
> >>>
> >>
> >> This is probably not going to be workable:
> >>
> >> $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l
> >> 106
> >> $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc
> >> -l
> >> 3
> >>
> >> I don't think this was the library that was deprecated either. I'm
> >> pretty sure that was the libdbus-glib library, though this is
> >> unfortunately built on top of that.
> >>
> > 
> > From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS:
> > 
> > "The deprecated dbus-glib library is no longer required. A bundled copy
> >   of its main loop integration code is included instead."
> > 
> > We are using dbus-python in some of our packages (mostly test suite for
> > UDisks and some helper scripts etc.).
> 
> Actually lvmdbusd is using dbus-python so Anaconda indirectly depends on
> it (Blivet is using LVM DBus API for LVM management).
Yeah, I don't think Anaconda directly uses python-dbus anymore. We have recently
migrated to the rather new (F32+) pure-Python dasbus DBus library and it has 
been working
nice so far:

https://github.com/rhinstaller/dasbus
https://koji.fedoraproject.org/koji/packageinfo?packageID=30190


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Please, IMHO, resolve in some way the Samba MIT kerberos problem.

[Alexander Bokovoy]

On ke, 12 helmi 2020, Dario Lesca wrote:

Il giorno mar, 11/02/2020 alle 21.35 +0200, Alexander Bokovoy ha
scritto:

There are few more missing parts here and there that need to
beimplemented. They might affect some use cases and not others. At
thispoint, I'd suggest to open bugs as you see them, this will help
us toclarify more use cases and see what can be supported or not
(yet).


There are a list of this missing, failings or simply testing
parts  that I can check and report on bugzilla?


So far, it is 'test what you can, please report issues in bugzilla'.


For now, the only problem I know on my little network is the w2w now
solved.

In my test environment also the update f-31->f-32rawhide, aka samba
4.11.6 -> samba-4.12rc2 it worked well without problem.


Good to hear! 


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mass Branching

[Vít Ondruch]

Receiving the email at 2:05 on 11th of February, I doubt that the 10th
could be "tomorrow" for anybody ...


Vít


Dne 11. 02. 20 v 2:05 Mohan Boddu napsal(a):
> Hello All,
>
> Fedora 32 will be branched from rawhide on February 10th 2020 which is
> tomorrow as per the Fedora 32 schedule[1]. The process takes about a
> day and everything should be ready by February 11th 2020. You can
> still be able to build packages normally until then, but after the
> mass branching rawhide and F32 will be separated.
>
> We will send another email once the branching is done.
>
> Thanks,
> Mohan Boddu.
>
> [1] https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
> ___
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Ray Strode]

hi,

On Wednesday, February 12, 2020, Miro Hrončok  wrote:
> Ray, could you please give this package to to FAS user "vtrefny"?

sure.  amigadave, do you want to be comaintainer too?

Ray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bugzilla Spammers

[Vít Ondruch]

Dne 11. 02. 20 v 14:43 Ben Cotton napsal(a):
> On Tue, Feb 11, 2020 at 8:40 AM Michael Cronenworth  wrote:
>> Who / Where is the best place to report spammers in Bugzilla? I think this 
>> is the
>> first (maybe for me) I've seen spam comments in the Red Hat Bugzilla.
>>
> Yuck. I guess I'm the best person to contact for now. I've set the
> spam comments to private and I'll work with the Bugzilla admins to see
> what we can do about it.
>
>

Hi Ben,

You should probably cleanup the CC list as well as remove the needinfo
to restore the bug original state.


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

Re: Seeking the maintainer of dbus-python

[Miro Hrončok]

On 12. 02. 20 12:08, Ray Strode wrote:

hi,

On Wednesday, February 12, 2020, Miro Hrončok > wrote:

 > Ray, could you please give this package to to FAS user "vtrefny"?

sure.  amigadave, do you want to be comaintainer too?


You can only make one person a main admin. Any co-maintainers can be handled 
later by them.


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

[Ray Strode]

hi,

On Wednesday, February 12, 2020, Miro Hrončok  wrote:
>> sure.  amigadave, do you want to be comaintainer too?
>
> You can only make one person a main admin. Any co-maintainers can be
handled later by them.

well i added neal and amigadave as admins, too, before giving the project
to vojtech.

Ray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing multi-builds updates gating

[Dridi Boukelmoune]

On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> We are pleased to announce that the work to gate rawhide packages has leveled
> up!
>
> Back in July we announced the first phase where bodhi got the support to gate
> single-build updates. We can now officially announce that bodhi can gate
> multi-builds updates. This is achieved through the use of side-tags, which can
> be created on demand via ``fedpkg request-side-tag``. The package can then be
> built using ``fedpkg build --target=`` or via ``fepdkg
> chain-build --target=``. Once all your packages are built, you
> can create a bodhi update from this side-tag using either the ``Use Side-Tag``
> drop-down or in the CLI by using the ``--from-tag`` argument to the ``bodhi
> updates new`` command.
>
> Every build in the update will then be tested by the CI system which will 
> report
> the outcome. Bodhi will then query greenwave which will rely on the collection
> of these individual results to make a decision about whether to gate the 
> update
> or not.
>
> More detailed documentation is available at:
> - https://fedoraproject.org/wiki/Package_update_HOWTO
> - https://docs.fedoraproject.org/en-US/rawhide-gating/
>
> Note: this is not the end of rawhide-gating. We still have some changes 
> planned
> to make it easier for greenwave to make a decision about an update containing
> multiple builds, we want to improve the documentation for on-boarding new CI
> systems and make them matter for rawhide as well as for stable releases.
> We then have all the work ahead to improving our tests, including enabling 
> some
> of them distribution-wide, looking at the reverse dependencies or testing for
> the impact of an update on our composes.
>
>
> Looking forward for your feedback!

I was immediately on board because there was a coordinated major
release of 4 packages I maintain right after this announcement.

Unfortunately I wasn't able to test dependent packages because the
mass rebuild kicked in and in effect updated the packages
automatically on Rawhide. Especially unfortunate since my bandwidth
for Fedora is very limited these days.

Question: can I build for rawhide, in a side tag, on an arbitrary git branch?

Remark: fedpkg's request-side-tag command doesn't appear in the manual
or bash autocomplete output.

Browsing the online docs I also don't know how to delete the side tag
since the builds were superseded by the packages from the mass
rebuild.

Thanks,
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Miro Hrončok]

On 12. 02. 20 12:18, Ray Strode wrote:

hi,

On Wednesday, February 12, 2020, Miro Hrončok > wrote:

 >> sure.  amigadave, do you want to be comaintainer too?
 >
 > You can only make one person a main admin. Any co-maintainers can be handled 
later by them.


well i added neal and amigadave as admins, too, before giving the project to 
vojtech.


Thanks. I've also opened:

https://pagure.io/releng/fedora-scm-requests/pull-request/22108

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

[Vojtěch Trefný]

On 2020-02-12 12:18, Ray Strode wrote:
> hi,
> 
> On Wednesday, February 12, 2020, Miro Hrončok  wrote:
>>> sure.  amigadave, do you want to be comaintainer too?
>>
>> You can only make one person a main admin. Any co-maintainers can be
> handled later by them.
> 
> well i added neal and amigadave as admins, too, before giving the project
> to vojtech.
> 
> Ray
> 

Thank you.

And thank you to neal and amigadave too, I expect dbus-python to be
quite easy to maintain but help is always appreciated. Leigh already did
the update to the latest upstream so everything should be ok for now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing multi-builds updates gating

[Miro Hrončok]

On 12. 02. 20 12:18, Dridi Boukelmoune wrote:

Question: can I build for rawhide, in a side tag, on an arbitrary git branch?


You can, but it's very confusing for others if not kept very self-contained.

Be on that branch and: fedpkg --release master --target  build

And if it blocks you, you can always do:

koji build f33 --nowait 
'git+https://src.fedoraproject.org/rpms/pkg.git#2a1eb42beca5e8b74c966348db6f5ab803b0595b'


--
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: Announcing multi-builds updates gating

[Dridi Boukelmoune]

On Wed, Feb 12, 2020 at 11:27 AM Miro Hrončok  wrote:
>
> On 12. 02. 20 12:18, Dridi Boukelmoune wrote:
> > Question: can I build for rawhide, in a side tag, on an arbitrary git 
> > branch?
>
> You can, but it's very confusing for others if not kept very self-contained.

The timing of the on-demand side tags announcement, the upstream
releases, and the mass rebuild... was unfortunate. But if next time I
check the planning before creating a side tag I should be able to
either work directly on master or live with the confusion :)

> Be on that branch and: fedpkg --release master --target  build
>
> And if it blocks you, you can always do:
>
> koji build f33 --nowait
> 'git+https://src.fedoraproject.org/rpms/pkg.git#2a1eb42beca5e8b74c966348db6f5ab803b0595b'

Thanks for the incantations!

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing multi-builds updates gating

[Pierre-Yves Chibon]

On Wed, Feb 12, 2020 at 11:18:33AM +, Dridi Boukelmoune wrote:
> On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon  
> wrote:
> Remark: fedpkg's request-side-tag command doesn't appear in the manual
> or bash autocomplete output.
> 
> Browsing the online docs I also don't know how to delete the side tag
> since the builds were superseded by the packages from the mass
> rebuild.

For side tags you created via fedpkg, you can delete them using: fedpkg
remove-side-tag. It will remove it without merging it.
If you want to list your side-tags you can do: fedpkg list-side-tags
--user=.

I'm indeed not seeing these commands in the man page, but they do appear in
fedpkg --help if that helps.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcing multi-builds updates gating

[Dridi Boukelmoune]

On Wed, Feb 12, 2020 at 12:58 PM Pierre-Yves Chibon  wrote:
>
> On Wed, Feb 12, 2020 at 11:18:33AM +, Dridi Boukelmoune wrote:
> > On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon  
> > wrote:
> > Remark: fedpkg's request-side-tag command doesn't appear in the manual
> > or bash autocomplete output.
> >
> > Browsing the online docs I also don't know how to delete the side tag
> > since the builds were superseded by the packages from the mass
> > rebuild.
>
> For side tags you created via fedpkg, you can delete them using: fedpkg
> remove-side-tag. It will remove it without merging it.
> If you want to list your side-tags you can do: fedpkg list-side-tags
> --user=.

I imagined this would look like this.

> I'm indeed not seeing these commands in the man page, but they do appear in
> fedpkg --help if that helps.

Indeed, I didn't try that.

Thanks,
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Michael Catanzaro]

On Tue, Feb 11, 2020 at 9:03 pm, Neal Gompa  wrote:

I don't think this was the library that was deprecated either. I'm
pretty sure that was the libdbus-glib library, though this is
unfortunately built on top of that.


OK, I think I see what happened. We had a big push a couple years ago 
to remove dbus-python as a dependency of GNOME, which was mostly 
successful (except for avahi and one or two other small things). I 
guess we must have been treating it as deprecated because it was still 
using libdbus-glib. So maybe it's kosher again now that it no longer 
uses libdbus-glib? (Thanks Vojtĕch for pointing out that major 
change.) At least, I don't see any other reason why we would want to 
get rid of it, especially considering upstream is still active.


So: I think I'm wrong, no need to start another wholesale migration 
away from dbus-python just because GNOME did so.


Michael

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

Re: Announcing multi-builds updates gating

[Lubomír Sedlář]

Pierre-Yves Chibon píše v St 12. 02. 2020 v 13:57 +0100:
> On Wed, Feb 12, 2020 at 11:18:33AM +, Dridi Boukelmoune wrote:
> > On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon <
> > pin...@pingoured.fr> wrote:
> > Remark: fedpkg's request-side-tag command doesn't appear in the
> > manual
> > or bash autocomplete output.
> > 
> > Browsing the online docs I also don't know how to delete the side
> > tag
> > since the builds were superseded by the packages from the mass
> > rebuild.
> 
> For side tags you created via fedpkg, you can delete them using:
> fedpkg
> remove-side-tag. It will remove it without merging it.
> If you want to list your side-tags you can do: fedpkg list-side-tags
> --user=.
> 
> I'm indeed not seeing these commands in the man page, but they do
> appear in fedpkg --help if that helps.

The functionality is actually implemented in python-rpkg. To update the
man page, fedpkg RPM has be rebuilt, which has actually happened a
couple days ago. There is an update in updates-testing now for F30 and
F31.

I also opened a pull request for the bash completion. Help would be
appreciated for ZSH completion.

https://pagure.io/fedpkg/blob/master/f/conf/zsh-completion/_fedpkg

Lubomír

> 
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Highlights from the latest Copr release

[Jakub Kadlcik]

Hello Kevin,
thank you for your feedback.

> This is still inherently flawed and unsafe because you have absolutely no
> way of guaranteeing that the notification mail actually reached the
> maintainer, only that it has been sent. E-mail is not a certified delivery
> mechanism.

True, that's why we wanted to have a 180 days preservation period.
The email accounts are not Copr-specific either, they are linked with
FAS. If somebody's mailbox can't be reached by any Fedora service
for half a year, there is something wrong. And I don't think we can do
anything about it.

Though, we are considering implementing some notification icon directly
on the Copr website. Is this something you would like to see?


> The whole concept of opt-out deletion is inherently flawed. It is
> unacceptable to delete user data without explicit confirmation.

I agree, that in the ideal world, it should be that way. But in the meantime,
Copr is not a paid service and has limited resources - mainly disk space.
Not removing any user data, would mean, that by now it wouldn't be possible
to build any package anymore. We would run out of space months ago.
We got promised new storage, but in the meantime, we need to remove
_outdated_ user data, just to keep the service working. Moreover, once
a new fedora is branched from rawhide, we create the chroots with
packages, that was build in rawhide chroots. This eats a lot (I can check
for the numbers) of space immediately after branching.

You can read more about the disk space issues in the original blog post
http://frostyx.cz/posts/copr-removing-outdated-chroots

We needed to figure out, what data we can remove without affecting the
most users. For years, we are removing old build results for packages
whose newer (or same) version was successfully built in the project.
Complying with "It is unacceptable to delete user data without explicit
confirmation", we wouldn't be allowed to do even this. But thanks to
this feature, we were able to not run out of storage for many months,
maybe even years. But lately, this mechanism wasn't sufficient, so we
needed to save disk space somewhere else. Our original idea was to
announce beforehand but then remove all the outdated chroots. Then
we downgraded the idea a little bit and we came with the concept of
notification emails and once an owner doesn't care about the outdated
chroots for his project, removing them.

If you have any other suggestions how to save storage space, let us
know, please. We will look at it.


> And of course, the fix comes too late for the repositories that you folks
> already irremediably destroyed with your deletion rampage. E.g., the latest
> release of Kannolo, Kannolo 27, is now missing one of its default
> repositories and I have no way to fix that (and neither do you, for that
> matter – the only way the problem could be solved would be to allow building
> for Fedora 27 again, then I could simply build the packages again).

What happened, was very unfortunate, by any means intentional, and
we are very sorry about it. A bug slipped into production and broke the
notification command, so any email couldn't be sent. After you reported
the issue, we fixed the bug, added several unit tests to cover any possible
regressions in the future, and updated the code so a chroot that we haven't
sent a notification about, can't be removed. I am aware that it won't un-remove
the data, that were already lost, so it is not that comforting for you, but
unfortunately, we have no way to restore the data.

Temporarily enabling outdated chroots for people who care, to rebuild
their data, wouldn't be that easy too. There is no guarantee that
end of life mock chroots still work.


Jakub


On Mon, Feb 10, 2020 at 1:36 PM Kevin Kofler  wrote:
>
> Pavel Raiskup wrote:
> > - The EOL chroot policy scripts responsible for notifying users about
> >   upcoming removals were fixed, users should now always be notified - and
> >   if for some reason they are not, the EOL chroot will not be removed.
>
> This is still inherently flawed and unsafe because you have absolutely no
> way of guaranteeing that the notification mail actually reached the
> maintainer, only that it has been sent. E-mail is not a certified delivery
> mechanism.
>
> The whole concept of opt-out deletion is inherently flawed. It is
> unacceptable to delete user data without explicit confirmation.
>
> And of course, the fix comes too late for the repositories that you folks
> already irremediably destroyed with your deletion rampage. E.g., the latest
> release of Kannolo, Kannolo 27, is now missing one of its default
> repositories and I have no way to fix that (and neither do you, for that
> matter – the only way the problem could be solved would be to allow building
> for Fedora 27 again, then I could simply build the packages again).
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email

Re: Non-Responsive Maintainer Check for jsmith

[Alex Scheel]

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

- Original Message -
> From: "Jared Smith" 
> To: "Alex Scheel" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, February 12, 2020 1:14:11 AM
> Subject: Re: Non-Responsive Maintainer Check for jsmith
> 
> On Tue, Feb 11, 2020 at 4:01 PM Alex Scheel  wrote:
> 
> > I'm initiating the non-responsive maintainer policy for jsmith.
> >
> 
> Sorry for the slow reply -- I've been busy lately finishing up graduate
> school, and I was on vacation last week.  I will attempt to respond to your
> bugzilla request as quickly as possible.
> 
> -Jared
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 Mass Branching

[James Cassell]

On Tue, Feb 11, 2020, at 2:37 PM, Miro Hrončok wrote:
> On 11. 02. 20 19:36, Adam Williamson wrote:
> > On Mon, 2020-02-10 at 20:05 -0500, Mohan Boddu wrote:
> >> Hello All,
> >>
> >> Fedora 32 will be branched from rawhide on February 10th 2020 which is
> >> tomorrow as per the Fedora 32 schedule[1]. The process takes about a
> >> day and everything should be ready by February 11th 2020. You can
> >> still be able to build packages normally until then, but after the
> >> mass branching rawhide and F32 will be separated.
> >>
> >> We will send another email once the branching is done.
> > 
> > Were we not planning to do this only when Rawhide is actually working?
> > It currently has numerous near-showstopper bugs...
> 
> The plan is to have a f32 freeze until the first working branched compose.
> 
> https://fedoraproject.org/wiki/Changes/Freeze_after_branching_until_compose_is_ready
> 

I'm probably misunderstanding, but I thought rawhide would be frozen until 
there were a successful f32 compose, to avoid mirror manager sending requests 
for f32 to f33 content.

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

Any plans to include kotlin in Fedora

[Code Zombie]

Hi

Kotlin is an open source project. Are there any plans to include its
compiler in Fedora (if not already) repositories? Currently, it is
installed manually on Linux to the best of my knowledge, but Mac systems
already install it with HomeBrew.

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

Looking for new urlgrabber maintainer

[Michal Domonkos]

Hi,

I'd like to ask around if anyone would be willing to take ownership of
the python3-urlgrabber package and its upstream repository[1]?

For historical reasons, the project is de facto maintained by us, the
DNF team (with the upstream repo hosted in our GitHub namespace).
However, with the community's departure from YUM (which depended on
urlgrabber) a few years back, we no longer have the incentive or
capacity to keep the project alive, and are considering deprecating it
in the near future, unless someone takes over.

Now, urlgrabber has recently[2] been ported to Python 3, in an effort
to maintain its legacy as a standalone general-purpose URL library,
authored[3] by Jochen Breuer of SUSE in November, 2018.  It's the only
component of the legacy YUM stack that wasn't dropped[4] from the
distro in Fedora 31.  In addition to that, there currently is one last
component in Fedora that requires the package; koji-containerbuild.

That said, I'd like to address this request especially to Jochen and
the maintainers of koji-containerbuild.  Please, let us know if you
(or anyone, really) would be interested in the transfer.

Thank you!

Michal

[1] https://github.com/rpm-software-management/urlgrabber
[2] 
https://github.com/rpm-software-management/urlgrabber/releases/tag/urlgrabber-4-0-0
[3] https://github.com/rpm-software-management/urlgrabber/pull/8
[4] https://fedoraproject.org/wiki/Changes/Retire_YUM_3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Looking for new urlgrabber maintainer

[Neal Gompa]

On Wed, Feb 12, 2020 at 10:52 AM Michal Domonkos  wrote:
>
> Hi,
>
> I'd like to ask around if anyone would be willing to take ownership of
> the python3-urlgrabber package and its upstream repository[1]?
>
> For historical reasons, the project is de facto maintained by us, the
> DNF team (with the upstream repo hosted in our GitHub namespace).
> However, with the community's departure from YUM (which depended on
> urlgrabber) a few years back, we no longer have the incentive or
> capacity to keep the project alive, and are considering deprecating it
> in the near future, unless someone takes over.
>
> Now, urlgrabber has recently[2] been ported to Python 3, in an effort
> to maintain its legacy as a standalone general-purpose URL library,
> authored[3] by Jochen Breuer of SUSE in November, 2018.  It's the only
> component of the legacy YUM stack that wasn't dropped[4] from the
> distro in Fedora 31.  In addition to that, there currently is one last
> component in Fedora that requires the package; koji-containerbuild.
>
> That said, I'd like to address this request especially to Jochen and
> the maintainers of koji-containerbuild.  Please, let us know if you
> (or anyone, really) would be interested in the transfer.
>

Umm, don't I already own python-urlgrabber in Fedora and upstream? Not
that I would mind co-maintainers, but I thought we already did this
switchover during Fedora 31 development...




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

Re: Any plans to include kotlin in Fedora

[Dridi Boukelmoune]

On Wed, Feb 12, 2020 at 3:33 PM Code Zombie  wrote:
>
> Hi
>
> Kotlin is an open source project. Are there any plans to include its compiler 
> in Fedora (if not already) repositories? Currently, it is installed manually 
> on Linux to the best of my knowledge, but Mac systems already install it with 
> HomeBrew.

You could ask the same about Dart, or any other language with an
opensource toolchain missing from Fedora.

I think it boils down to having people to do the work, which is
probably not an easy task. I'm also assuming we'd need a more
up-to-date gradle package, which might not be a trivial task, and I
suspect that the build system is probably full of "Fedora violations"
between the need for an internet access, fetching pre-built
dependencies, bundling some dependencies...

That's usually what discourages me when I look at that kind of stack:
somewhat large and full of no-nos. So I have to assume Kotlin is
missing because nobody was bold enough to take it on (or nobody on
the Fedora project is interested in Kotlin).

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: deduplicating noarch subpackages

[Adam Jackson]

On Tue, 2020-02-11 at 16:21 -0800, Josh Stone wrote:

> Another alternative is to try to remove the host information from the
> metadata hash, which I've already started upstream[3], but I'm not sure
> alleviate their concerns about caching and such.
> 
> [3] https://github.com/rust-lang/cargo/pull/7873
> 
> Worst case, I could just build them as arch'ed subpackages, specific to
> the host which compiled them.

I'd lean in favor of removing at least the architecture part of the
host triple from the hash. koji is still going to build those noarch
packages on every architecture and compare them, so if you do remove
the arch from the hash and they all compare equal, it can't have
mattered which arch you built it from.

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Looking for new urlgrabber maintainer

[Michael McLean]

koji-containerbuild isn't maintained by the core Koji maintainers. That's
the osbs folks.

On Wed, Feb 12, 2020 at 11:06 AM Neal Gompa  wrote:

> On Wed, Feb 12, 2020 at 10:52 AM Michal Domonkos 
> wrote:
> >
> > Hi,
> >
> > I'd like to ask around if anyone would be willing to take ownership of
> > the python3-urlgrabber package and its upstream repository[1]?
> >
> > For historical reasons, the project is de facto maintained by us, the
> > DNF team (with the upstream repo hosted in our GitHub namespace).
> > However, with the community's departure from YUM (which depended on
> > urlgrabber) a few years back, we no longer have the incentive or
> > capacity to keep the project alive, and are considering deprecating it
> > in the near future, unless someone takes over.
> >
> > Now, urlgrabber has recently[2] been ported to Python 3, in an effort
> > to maintain its legacy as a standalone general-purpose URL library,
> > authored[3] by Jochen Breuer of SUSE in November, 2018.  It's the only
> > component of the legacy YUM stack that wasn't dropped[4] from the
> > distro in Fedora 31.  In addition to that, there currently is one last
> > component in Fedora that requires the package; koji-containerbuild.
> >
> > That said, I'd like to address this request especially to Jochen and
> > the maintainers of koji-containerbuild.  Please, let us know if you
> > (or anyone, really) would be interested in the transfer.
> >
>
> Umm, don't I already own python-urlgrabber in Fedora and upstream? Not
> that I would mind co-maintainers, but I thought we already did this
> switchover during Fedora 31 development...
>
>
>
>
> --
> 真実はいつも一つ！/ 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

Koji build failing with "nothing provides kernel"

[Richard W.M. Jones]

Check out the root.log files in this build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=41469323

DEBUG util.py:596:- nothing provides kernel needed by 
libguestfs-1:1.41.8-8.fc32.x86_64

... but only on some architectures, which is even stranger.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Looking for new urlgrabber maintainer

[Martin Basti]

On 12. 2. 2020 17:06, Neal Gompa wrote:
> On Wed, Feb 12, 2020 at 10:52 AM Michal Domonkos  wrote:
>> Hi,
>>
>> I'd like to ask around if anyone would be willing to take ownership of
>> the python3-urlgrabber package and its upstream repository[1]?
>>
>> For historical reasons, the project is de facto maintained by us, the
>> DNF team (with the upstream repo hosted in our GitHub namespace).
>> However, with the community's departure from YUM (which depended on
>> urlgrabber) a few years back, we no longer have the incentive or
>> capacity to keep the project alive, and are considering deprecating it
>> in the near future, unless someone takes over.
>>
>> Now, urlgrabber has recently[2] been ported to Python 3, in an effort
>> to maintain its legacy as a standalone general-purpose URL library,
>> authored[3] by Jochen Breuer of SUSE in November, 2018.  It's the only
>> component of the legacy YUM stack that wasn't dropped[4] from the
>> distro in Fedora 31.  In addition to that, there currently is one last
>> component in Fedora that requires the package; koji-containerbuild.
>>
>> That said, I'd like to address this request especially to Jochen and
>> the maintainers of koji-containerbuild.  Please, let us know if you
>> (or anyone, really) would be interested in the transfer.
>>
> Umm, don't I already own python-urlgrabber in Fedora and upstream? Not
> that I would mind co-maintainers, but I thought we already did this
> switchover during Fedora 31 development...
>
>
Ehm sorry,

it seems that somebody forgot to remove that dependency from
koji-contianerbuild. At least it is not used in upstream I opened PR to
drop it.

https://github.com/containerbuildsystem/koji-containerbuild/pull/159



-- 
Martin Bašti
Senior Software Engineer
Red Hat




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

Re: Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)

[Alain Vigne]

Hello Fabio

I am not very active, and not a software engineer, but Vala/GTK
applications are kind of my hobby, and I had the opportunity to take a look
at elementary applications (code wise too).
You are maintaining much more packages I can ever pretend to maintain, so
this will be a little help.
But I am ready to lend a hand, if I can get some guidance, milestones, and
if we can work together... ?

I am CET time zone based. Do you work from the USA ?

My FAS is: avigne.
Keep me posted.
BR, Alain


On Fri, Jan 31, 2020 at 9:30 PM Fabio Valentini 
wrote:

> Hi everybody,
>
> With more responsibilities (FPC, Stewardship SIG, FESCo) and the
> ever-growing number of packages I maintain, I don't have as much time
> for the things I originally started my contributions to fedora with -
> the Pantheon desktop and the accompanying elementary applications.
>
> What makes things worse is that I am not particularly proficient with
> Vala or C/GObject, other than including upstream patches or doing
> simple backports. That means some issues are punted until upstream
> projects get around to fixing them (and if these issues are only
> affecting "third-party" distros like fedora, that can take a while).
>
> Also, the fact that GNOME frequently (almost with every new major
> stable release, which means with almost every fedora release) breaks
> something - either subtly or not - does not help.
> gnome-settings-daemon changes its DBus interfaces almost every
> release. mutter makes sweeping API changes almost every release. Both
> gala and the elementary LightDM greeter can't keep up with upstream
> mutter, and are basically still stuck on mutter 3.28 support (which is
> why there is a mutter328 compat package) ...
>
> Overall, this results in the quality of all these packages not being
> as high as I would like it to be (though it's still pretty good, all
> things considered). In particular, there are some components that are
> more "crashy" than the rest, and I don't have the time and skill to
> get deep into debugging the issue in most cases:
>
> - wingpanel (the panel for Pantheon); issues in individual indicators
> also crash the whole app because they are just dlopen()ed
> - switchboard (the settings application); issues in individual
> settings panels also crash the whole app because they are just
> dlopen()ed
> - gala (the window manager): obviously bad if the WM crashes, though
> not as bad because it's still an Xorg session
> - plank (the dock); also optionally used on XFCE (I think)
> - sequeler (third-party SQL client developed for Pantheon)
>
> I would greatly appreciate if somebody who knows their GObject-fu
> could help me out here.
>
> The elementaryOS upstream developers are usually helpful and accept
> patches - even for things that are not a problem on elementaryOS, so
> long as they can be switched on/off with e.g. conditional compilation.
> But reported issues - that only affect fedora - without attached
> patches / PRs are obviously low priority for them, and often sit
> untouched for months or years.
>
> In general, I manage to keep the packages for Pantheon / elementary
> projects up-to-date. Having set up "nightly" builds on COPR a few
> years ago really helps to catch potential issues early.
>
> If anybody is interested, here are some pointers:
>
> - all packages are tracked in koschei, in the decathorpe/elementary group:
> https://koschei.fedoraproject.org/groups/decathorpe/elementary
>
> - nightly builds are done on COPR:
> https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/
>
> Thanks,
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


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

[Test-Announce] Fedora 32 Branched 20200212.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200212.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pyparted - 20200207.n.2: pyparted-3.11.3-1.fc32.src, 20200212.n.1: 
pyparted-3.11.4-1.fc32.src

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200212.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Any plans to include kotlin in Fedora

[Bill Chatfield via devel]

 It's probably a good idea to make it available. If I could find time I would 
do it, even though I think we have a proliferation of unnecessary new 
languages. But, people want them so it's best to make them available.

On Wednesday, February 12, 2020, 11:06:30 AM EST, Dridi Boukelmoune 
 wrote:  
 
 On Wed, Feb 12, 2020 at 3:33 PM Code Zombie  wrote:
>
> Hi
>
> Kotlin is an open source project. Are there any plans to include its compiler 
> in Fedora (if not already) repositories? Currently, it is installed manually 
> on Linux to the best of my knowledge, but Mac systems already install it with 
> HomeBrew.

You could ask the same about Dart, or any other language with an
opensource toolchain missing from Fedora.

I think it boils down to having people to do the work, which is
probably not an easy task. I'm also assuming we'd need a more
up-to-date gradle package, which might not be a trivial task, and I
suspect that the build system is probably full of "Fedora violations"
between the need for an internet access, fetching pre-built
dependencies, bundling some dependencies...

That's usually what discourages me when I look at that kind of stack:
somewhat large and full of no-nos. So I have to assume Kotlin is
missing because nobody was bold enough to take it on (or nobody on
the Fedora project is interested in Kotlin).

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

Fedora-32-20200212.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 100/158 (x86_64), 1/2 (arm)

ID: 520129  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/520129
ID: 520130  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520130
ID: 520131  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/520131
ID: 520132  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/520132
ID: 520133  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/520133
ID: 520137  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520137
ID: 520142  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/520142
ID: 520143  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/520143
ID: 520144  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/520144
ID: 520145  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/520145
ID: 520146  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/520146
ID: 520154  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/520154
ID: 520159  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/520159
ID: 520162  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/520162
ID: 520169  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520169
ID: 520170  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/520170
ID: 520171  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520171
ID: 520172  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/520172
ID: 520173  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/520173
ID: 520188  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/520188
ID: 520193  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520193
ID: 520197  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/520197
ID: 520199  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/520199
ID: 520206  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/520206
ID: 520208  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/520208
ID: 520209  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/520209
ID: 520210  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/520210
ID: 520211  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/520211
ID: 520212  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/520212
ID: 520213  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/520213
ID: 520214  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/520214
ID: 520215  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/520215
ID: 520216  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/520216
ID: 520217  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/520217
ID: 520219  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/520219
ID: 520220  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/520220
ID: 520221  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/520221
ID: 520222  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/520222
ID: 520223  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/520223
ID: 520224  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/520224
ID: 520225  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/520225
ID: 520226  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/t

Re: Koji build failing with "nothing provides kernel"

[Kevin Fenzi]

On Wed, Feb 12, 2020 at 04:58:43PM +, Richard W.M. Jones wrote:
> Check out the root.log files in this build:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41469323
> 
> DEBUG util.py:596:- nothing provides kernel needed by 
> libguestfs-1:1.41.8-8.fc32.x86_64
> 
> ... but only on some architectures, which is even stranger.

I'm really not sure what happened. This also broke the rawhide compose
today: 

After branching it sees there was a kernel tagged into f33, but it
wasn't showing up on latest-pkg or other things. I went ahead and
re-tagged it and I think thats "fixed" it for now. See:

https://pagure.io/releng/failed-composes/issue/982#comment-626082

for more details. 

kevin


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

Java Packaging Guidelines - .so in JARs?

[Alex Scheel]

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

I found these docs:

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

Which seem to have conflicting commentary on this:

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

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


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


Wondering what the community's thoughts are,

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

Re: Koji build failing with "nothing provides kernel"

[Richard W.M. Jones]

On Wed, Feb 12, 2020 at 12:55:45PM -0800, Kevin Fenzi wrote:
> On Wed, Feb 12, 2020 at 04:58:43PM +, Richard W.M. Jones wrote:
> > Check out the root.log files in this build:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41469323
> > 
> > DEBUG util.py:596:- nothing provides kernel needed by 
> > libguestfs-1:1.41.8-8.fc32.x86_64
> > 
> > ... but only on some architectures, which is even stranger.
> 
> I'm really not sure what happened. This also broke the rawhide compose
> today: 
> 
> After branching it sees there was a kernel tagged into f33, but it
> wasn't showing up on latest-pkg or other things. I went ahead and
> re-tagged it and I think thats "fixed" it for now. See:
> 
> https://pagure.io/releng/failed-composes/issue/982#comment-626082
> 
> for more details. 

I reissued the build a few moments ago and it succeeded
this time, thanks.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Jam failing compose

[Erich Eickmeyer]

Hi all,

I've introduced myself as the new maintainer of the Fedora Jam audio 
lab. I'm looking at the compose log and they're failing[1]. I'm not 
sure why, but it appears as though carla didn't branch to F32 for 
whatever reason. I know it was failing to build, but that got sorted as 
of February 7th[2].


Can someone tell me what's going on [3]?

Thanks,
Erich

[1] 


[2] 
[3] Please? Pretty please?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Turning off keys.fedoraproject.org

[Björn Persson]

Kevin Fenzi wrote:
> well, they are already pretty bad because fas just stores the short
> version, which has been subject to duplicates for... years now?

My FAS account shows a 64-bit key ID. Yours shows 32 bits. I guess it
displays what you give it. As far as I have heard only 32-bit key IDs
have been duplicated.

It would be better if the user interface didn't require users to know
such details.

> Not sure what best to do here. I fear gpg is pretty much a failure these
> days and we need something better, but I am not sure what that is. 

I think GnuPG is best thought of as a building block, essentially a
library that programs can use for their encryption and authentication
needs. It works well when used that way, for example by RPM/Yum. Viewed
as a tool, it's only usable to crypto nerds.

The "web of trust" is clearly not working. In the more than 21 years
I've had PGP keys I have never once been able to validate a key through
a chain of signatures. The attack on SKS is another nail in its coffin.
Another certification method is needed, and WKD is one candidate.

Björn Persson


pgpfCRnITZdNm.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: Turning off keys.fedoraproject.org

[Björn Persson]

Kevin Fenzi wrote:
> Fas is on life support mode, but something could be added to the new
> coming account system interface. 

I understand from this that the entire FAS will be replaced. I had
previously gotten a vague impression that the new project would replace
the authentication bits of FAS or something.

> keys.openpgp.org offers a WKD as a service thing:
> 
> https://keys.openpgp.org/about/usage

Hmm. They state that they support the lookup protocol, but in their FAQ
I find this statement:

| The keys.openpgp.org service is meant for key distribution and
| discovery, not as a de facto certification authority. Client
| implementations that want to offer verified communication should rely
| on their own trust model.

That is, you're not supposed to trust that keys you receive from
keys.openpgp.org are genuine.

WKD, on the other hand, aims to solve that. The WKD Internet Draft
(https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09)
says this about the Web Key Directory Update Protocol:

| To put keys into the key directory a protocol to automate the task is
| desirable.  The protocol defined here is entirely based on mail and
| the assumption that a mail provider can securely deliver mail to the
| INBOX of a user (e.g. an IMAP folder).

Securely dropping an email in a user's mailbox is no problem for an
email provider that controls its own infrastructure. For a third party
like keys.openpgp.org it's another matter. They state that they use
MTA-STS and STARTTLS Everywhere to make sure that verification emails
are sent over TLS, but what do they do if your email provider doesn't
support SMTP over TLS? Do they refuse your key in that case? My guess
is that they send the verification email unprotected, and that that's
one reason why they say they're not a certification authority.

Forwarding aliases like the addresses in fedoraproject.org add another
complication. Even if Red Hat's mail servers support MTA-STS, there is
no way for keys.openpgp.org to know whether the next hop will be secure.

A directory server integrated with FAS's successor wouldn't have to try
to verify keys over insecure email. Users could upload their key to
their account, and that would be sufficient proof that the key is
theirs.

Björn Persson


pgpYI_8Vovag9.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: Fedora Jam failing compose

[Kevin Fenzi]

On Wed, Feb 12, 2020 at 02:00:26PM -0800, Erich Eickmeyer wrote:
> Hi all,
> 
> I've introduced myself as the new maintainer of the Fedora Jam audio lab.
> I'm looking at the compose log and they're failing[1]. I'm not sure why, but
> it appears as though carla didn't branch to F32 for whatever reason. I know
> it was failing to build, but that got sorted as of February 7th[2].
> 
> Can someone tell me what's going on [3]?

The kickstart seems to have:

fedora-live-jam_kde.ks:carla

but the package is called: Carla

So, I think changing that lower case  c to a cap C should fix it. 

kevin


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

Re: Fedora Jam failing compose

[Ankur Sinha]

On Wed, Feb 12, 2020 14:00:26 -0800, Erich Eickmeyer wrote:
> Hi all,

Hi Erich,

> 
> I've introduced myself as the new maintainer of the Fedora Jam audio lab. 

Thanks again for taking it up!

> I'm looking at the compose log and they're failing[1]. I'm not sure
> why, but it appears as though carla didn't branch to F32 for whatever
> reason. I know it was failing to build, but that got sorted as of
> February 7th[2].
> 
> Can someone tell me what's going on [3]?

I *think* the package needs to be "Carla", with a capital "c". DNF
doesn't find "carla" with a small "c" either.


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Turning off keys.fedoraproject.org

[Kevin Fenzi]

On Wed, Feb 12, 2020 at 11:14:32PM +0100, Björn Persson wrote:
> Kevin Fenzi wrote:
> > well, they are already pretty bad because fas just stores the short
> > version, which has been subject to duplicates for... years now?
> 
> My FAS account shows a 64-bit key ID. Yours shows 32 bits. I guess it
> displays what you give it. As far as I have heard only 32-bit key IDs
> have been duplicated.
> 
> It would be better if the user interface didn't require users to know
> such details.

Yeah, we may have added a change to let you specify the longer one at
some point. Not sure. 
> 
> > Not sure what best to do here. I fear gpg is pretty much a failure these
> > days and we need something better, but I am not sure what that is. 
> 
> I think GnuPG is best thought of as a building block, essentially a
> library that programs can use for their encryption and authentication
> needs. It works well when used that way, for example by RPM/Yum. Viewed
> as a tool, it's only usable to crypto nerds.

Agreed. 
 
> The "web of trust" is clearly not working. In the more than 21 years
> I've had PGP keys I have never once been able to validate a key through
> a chain of signatures. The attack on SKS is another nail in its coffin.
> Another certification method is needed, and WKD is one candidate.

well, WKD just replaces the 'web of trust' part, the rest of gpg/pgp is
still there: horrible setup, poor docs, configuration thats a nightmare,
etc. 

Sadly, I don't know what the answer is, but getting more than just nerds
using gpg is not going to happen. ;( 

kevin


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

Re: Turning off keys.fedoraproject.org

[Kevin Fenzi]

On Wed, Feb 12, 2020 at 11:15:01PM +0100, Björn Persson wrote:
> Kevin Fenzi wrote:
> > Fas is on life support mode, but something could be added to the new
> > coming account system interface. 
> 
> I understand from this that the entire FAS will be replaced. I had
> previously gotten a vague impression that the new project would replace
> the authentication bits of FAS or something.

The new system is going to depend on freeipa as much it can for the
heavy lifting. There will just be a web interface and api on top of that
to talk to the freeipa backend for things. Hopefully this will be of
interest to other communities/etc and we can get a community to help
maintain things longer term. 

...snip...
> 
> A directory server integrated with FAS's successor wouldn't have to try
> to verify keys over insecure email. Users could upload their key to
> their account, and that would be sufficient proof that the key is
> theirs.

Sure, feel free to make the case to the team working on the interface.

I don't want to commit them to work, but I agree having something might
be nice. Perhaps if not in the initial version in a later one. 

kevin


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

Re: Package uses Gradle (retired) to build: what to do?

[Ankur Sinha]

On Mon, Feb 10, 2020 11:31:08 +, Ankur Sinha wrote:
> On Sun, Feb 09, 2020 14:23:12 -0500, Neal Gompa wrote:
> > On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini  wrote:
> > >
> > 
> > >
> > > > What are our other options? (Of course, I assume bundling the Gradle
> > > > binary for Fedora is out.)
> > >
> > > - Option 1: Convert package build systems from gradle to maven.
> > > Pro: Works with current packaging tools.
> > > Con: might make package updates harder.
> > >
> > 
> > As I think we can see here, this option doesn't really scale well and
> > causes more problems than it solves.
> 
> I'll have a look at this to see what the effort required here is. If it
> can be done automatically, it may not be so hard. I found this, for
> example:
> 
> https://github.com/tvaughan77/gradle2maven
> 
> > > - Option 2: Bring back gradle, possibly in a multi-step bootstrapping
> > > process (like Neal outlined), with a "full-bundled" build is done
> > > first to get things off the ground, and after that, components can be
> > > de-bundled one after another.
> > > Pro: no changes necessary for packages built with gradle.
> > > Con: Lots of work packaging gradle and its ecosystem.
> > >
> > 
> > At least initially, it shouldn't be bad, and unbundling can be done
> > iteratively with relatively little pain. This has the benefit of
> > unlocking most of the JVM ecosystem for Fedora again, as Gradle has
> > become the most popular option for building stuff on the JVM.
> 
> I certainly see your point, but given the (perceived?) lack of Java
> focussed man-power in the community at the moment, it is hard to say if:
> 
> - we'll have enough resources to unbundle it in the short-term future;
> - we'll have enough resources to maintain the whole unbundled ecosystem
>   in the long-term future.
> 
> I.e., will this last in the long term, or will we be having such a
> conversation again soon?
> 
> I guess we can just keep the bundled version as long as we need to, but
> before we go down this option: how many folks in the community can
> commit to helping maintain Gradle, at least in its bundled form, in the
> long term, say till F34 release? If we don't have enough resources for
> this, then the initial effort may not be worth investing in the first
> place.

Anyone with the time to (co-)maintain Gradle? :)

> I can help with general packaging, I don't do a lot of Java, and I
> certainly don't do a lot of Gradle, so I would not want to be the single
> or main point-of-contact for this. My focus in Fedora is
> SciTech/NeuroFedora, and I do not have cycles to also prioritise
> Java/Gradle work.



-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Fedora Jam failing compose

[Erich Eickmeyer]

On Wed, Feb 12, 2020 at 10:44 pm, Ankur Sinha  
wrote:

On Wed, Feb 12, 2020 14:00:26 -0800, Erich Eickmeyer wrote:

 Hi all,


Hi Erich,



 I've introduced myself as the new maintainer of the Fedora Jam 
audio lab.


Thanks again for taking it up!


 I'm looking at the compose log and they're failing[1]. I'm not sure
 why, but it appears as though carla didn't branch to F32 for 
whatever

 reason. I know it was failing to build, but that got sorted as of
 February 7th[2].

 Can someone tell me what's going on [3]?


I *think* the package needs to be "Carla", with a capital "c". DNF
doesn't find "carla" with a small "c" either.



Yes, Kevin and Ankur, you're both absolutely right. I just fixed it and 
sent a pull request for master and f32's branch of the kickstarts. Now, 
if someone would be so kind as to approve the pull request, that would 
be dandy. :)


Thanks,
Erich

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Jam failing compose

[Kevin Fenzi]

> Yes, Kevin and Ankur, you're both absolutely right. I just fixed it and sent
> a pull request for master and f32's branch of the kickstarts. Now, if
> someone would be so kind as to approve the pull request, that would be
> dandy. :)

Done. 

kevin


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