Re: Qt 5.14.2 coming to rawhide

[Robin Lee]

On Wed, Apr 8, 2020 at 12:24 PM Kevin Fenzi  wrote:
>
> On Wed, Apr 08, 2020 at 10:45:40AM +0800, Robin Lee wrote:
> > On Sun, Apr 5, 2020 at 6:58 AM Rex Dieter  wrote:
> > >
> > > FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> > > progress being done in side tag f33-build-side-21031
> > >
> > > I figure it'll take at least a few days to get the core bits and all
> > > dependencies rebuilt.  Will provide status updates as warranted.
> > >
> > > -- Rex
> > I built deepin-qt5integration-5.0.0-5.fc33 in the side tag.
> > But when I build deepin-file-manager, the new build of deepin-qt5integration
> > is not found.
> > What should I do to fix this?
>
> It doesn't look to me like thats the cause of the failed build?
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43111751
>
> ...
> ./shutil/dsqlitehandle.h:29:8: error: redefinition of 'struct 
> std::hash'
>29 | struct hash
>   |^
> In file included from /usr/include/qt5/QtCore/qlist.h:47,
>  from /usr/include/qt5/QtCore/qurl.h:47,
>  from /usr/include/qt5/QtCore/QUrl:1,
>  from ./interfaces/durl.h:28,
>  from tag/tagmanager.h:15,
>  from tag/tagmanager.cpp:7:
> /usr/include/qt5/QtCore/qhashfunctions.h:180:16: note: previous definition of 
> 'struct std::hash'
>   180 | struct hash< QT_PREPEND_NAMESPACE(Class) > {\
>   |^~~
> /usr/include/qt5/QtCore/qhashfunctions.h:200:5: note: in expansion of macro 
> 'QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH'
>   200 | QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH(Class, const argument_type &)
>   | ^~~~
> /usr/include/qt5/QtCore/qhashfunctions.h:204:1: note: in expansion of macro 
> 'QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH_BY_CREF'
>   204 | QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH_BY_CREF(QString)
>   | ^~~~
> make[1]: *** [Makefile:3680: tagmanager.o] Error 1
> ...
>
> kevin
Sorry! I checked a wrong task for log.
Now deepin-file-manager is also fixed. New build is
deepin-file-manager-5.0.0-7.fc33

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days

[Igor Gnatenko]

I agree, if this would not happen then everything would just blow up.

On Wed, Apr 8, 2020 at 8:33 AM Clement Verna  wrote:
>
>
>
> On Tue, 7 Apr 2020 at 23:38, Mohan Boddu  wrote:
>>
>> I guess it should be a fixed in bodhi. But for now you can remove the
>> builds that it's complaining about in the update.
>>
>> https://github.com/fedora-infra/bodhi/issues/3991
>
>
> Answered in the ticket, but I think Bodhi is behaving correctly there. When 
> trying to merge the side tag, if Bodhi find a more recent build in the target 
> tag it will push back the update to pending and comment on the update that 
> there are more recent builds in the target tag. Then it is up to the packager 
> to resolve the conflict (either rebuild the conflicting packages or remove 
> them from the update).
>
>>
>>
>> On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones  wrote:
>> >
>> >
>> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
>> >
>> > This one is a Rawhide update from a side tag, submitted on Sunday
>> > morning which has been in pending for 2 days.  (As it's Rawhide it's
>> > supposed to spend 0 days in testing.)  Is there any problem with it,
>> > or do we just have to wait longer?  It is blocking builds of other
>> > packages.
>> >
>> > 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
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide update from side tag pending for 2 days

[Clement Verna]

On Tue, 7 Apr 2020 at 23:38, Mohan Boddu  wrote:

> I guess it should be a fixed in bodhi. But for now you can remove the
> builds that it's complaining about in the update.
>
> https://github.com/fedora-infra/bodhi/issues/3991


Answered in the ticket, but I think Bodhi is behaving correctly there. When
trying to merge the side tag, if Bodhi find a more recent build in the
target tag it will push back the update to pending and comment on the
update that there are more recent builds in the target tag. Then it is up
to the packager to resolve the conflict (either rebuild the conflicting
packages or remove them from the update).


>
> On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones 
> wrote:
> >
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> >
> > This one is a Rawhide update from a side tag, submitted on Sunday
> > morning which has been in pending for 2 days.  (As it's Rawhide it's
> > supposed to spend 0 days in testing.)  Is there any problem with it,
> > or do we just have to wait longer?  It is blocking builds of other
> > packages.
> >
> > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days

[Clement Verna]

On Tue, 7 Apr 2020 at 14:57, Rex Dieter  wrote:

> Richard W.M. Jones wrote:
>
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> >
> > This one is a Rawhide update from a side tag, submitted on Sunday
> > morning which has been in pending for 2 days.  (As it's Rawhide it's
> > supposed to spend 0 days in testing.)  Is there any problem with it,
> > or do we just have to wait longer?  It is blocking builds of other
> > packages.
>
> I saw the same thing, and submitted a infra ticket about it,
> https://pagure.io/fedora-infrastructure/issue/8819


So I started to look at that ticket, and Bodhi had a problem creating the
pending-signing and pending-testing tags in koji. I have fixed that and now
the update was not pushed to stable because there are builds in the side
tag conflicting with builds in the f33 buildroot. You need to edit your
update to either include a rebuild of these conflicting packages or just
remove them  from the update.

There is an handy comment on the update that tells you which builds are
conflicting.

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

[Kevin Fenzi]

On Wed, Apr 08, 2020 at 10:45:40AM +0800, Robin Lee wrote:
> On Sun, Apr 5, 2020 at 6:58 AM Rex Dieter  wrote:
> >
> > FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> > progress being done in side tag f33-build-side-21031
> >
> > I figure it'll take at least a few days to get the core bits and all
> > dependencies rebuilt.  Will provide status updates as warranted.
> >
> > -- Rex
> I built deepin-qt5integration-5.0.0-5.fc33 in the side tag.
> But when I build deepin-file-manager, the new build of deepin-qt5integration
> is not found.
> What should I do to fix this?

It doesn't look to me like thats the cause of the failed build?

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

...
./shutil/dsqlitehandle.h:29:8: error: redefinition of 'struct 
std::hash'
   29 | struct hash
  |^
In file included from /usr/include/qt5/QtCore/qlist.h:47,
 from /usr/include/qt5/QtCore/qurl.h:47,
 from /usr/include/qt5/QtCore/QUrl:1,
 from ./interfaces/durl.h:28,
 from tag/tagmanager.h:15,
 from tag/tagmanager.cpp:7:
/usr/include/qt5/QtCore/qhashfunctions.h:180:16: note: previous definition of 
'struct std::hash'
  180 | struct hash< QT_PREPEND_NAMESPACE(Class) > {\
  |^~~
/usr/include/qt5/QtCore/qhashfunctions.h:200:5: note: in expansion of macro 
'QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH'
  200 | QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH(Class, const argument_type &)
  | ^~~~
/usr/include/qt5/QtCore/qhashfunctions.h:204:1: note: in expansion of macro 
'QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH_BY_CREF'
  204 | QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH_BY_CREF(QString)
  | ^~~~
make[1]: *** [Makefile:3680: tagmanager.o] Error 1
...

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: v4l2loopback kernel module in Fedora?

[Christopher]

On Tue, Apr 7, 2020 at 6:06 AM Iñaki Ucar  wrote:
>
> On Tue, 7 Apr 2020 at 05:58, Christopher  wrote:
> >
> > If I get the motivation, I'll file a bug against the RPMFusion package.
>
> Here's the bug tracker: https://bugzilla.rpmfusion.org/

Thanks.

>
> > As for the original issue regarding packaging: there is a ticket being
> > tracked to get it upstream into the kernel:
> > https://github.com/umlaeute/v4l2loopback/issues/268
>
> Yeap, I saw this, and that's why I said that upstream doesn't seem to
> be willing to push this forward, because the maintainer's message is
> basically "I'm totally open, but I'm not going to move a finger
> besides merging PRs".
>

My interpretation of their message was more "I tried a little, but
don't know where to go from here". They might just need help... but I
don't really know. :)

One more thing: can anybody point me to good docs on how to
automatically sign DKMS on build/install in Fedora? I tried editing
/etc/dkms/framework.conf to add SIGN_TOOL and also POST_INST, but
nothing seemed to work. I can't even get my script to run. I can sign
it manually after I `dkms install` but that's kind of annoying to do
after every dnf update that updates the kernel. All the docs out there
seem to be written for Ubuntu, and the instructions don't seem to work
on Fedora. If I can't get good docs, I'm going to have to start
ripping apart /usr/sbin/dkms and filling it with print debug
statements. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14.2 coming to rawhide

[Robin Lee]

On Sun, Apr 5, 2020 at 6:58 AM Rex Dieter  wrote:
>
> FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> progress being done in side tag f33-build-side-21031
>
> I figure it'll take at least a few days to get the core bits and all
> dependencies rebuilt.  Will provide status updates as warranted.
>
> -- Rex
I built deepin-qt5integration-5.0.0-5.fc33 in the side tag.
But when I build deepin-file-manager, the new build of deepin-qt5integration
is not found.
What should I do to fix this?

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

[ANN] python-hypothesis 5.8.0 in fc33, fc32

[Michel Alexandre Salim]

Hi all,

I just updated python-hypothesis to the latest 5.8.0 version. It should 
be fine for Rawhide, but for Fedora 32 it's probably worth testing 
(since the previous version we have in the repo is a bit behind -- 4.23.8).


I'm putting it as a buildroot override in case maintainers for the 
dependent packages want to verify this works as expected:


https://bodhi.fedoraproject.org/overrides/python-hypothesis-5.8.0-2.fc32

$ sudo dnf repoquery --whatrequires python3-hypothesis
python3-argon2-cffi-0:19.2.0-2.fc32.x86_64
python3-hs-dbus-signature-0:0.06-6.fc32.noarch
python3-hypothesis-fspaths-0:0.1-5.fc32.noarch

Best regards,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Nvidia 440.82 came out today

[Adam Williamson]

On Tue, 2020-04-07 at 20:55 -0400, Paul Dufresne via devel wrote:
> I saw that Nvidia published version 440.82 of their drivers today.
> 
> Last one was 440.62 released on February 28.

That is offtopic here, as Fedora does not ship or support proprietary
software. There are third-party repositories that do ship this driver,
you could discuss it on their mailing lists etc.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Nvidia 440.82 came out today

[Paul Dufresne via devel]

I saw that Nvidia published version 440.82 of their drivers today.

Last one was 440.62 released on February 28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 FTBFS packages to be orphaned in 1 week

[Fabio Valentini]

On Mon, Apr 6, 2020 at 1:00 PM Miro Hrončok  wrote:
>
> On 29. 03. 20 13:13, Miro Hrončok wrote:
> > According to the Fedora's Fails To Build From Source policy:
> >
> > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> >
> >
> > The following packages will be orphaned on Monday 2020-04-06.
> >
> > Their F32FTBFS Bugzillas are in NEW state for the defined period of time and
> > they have the necessary reminders. They were not successfully rebuilt in 
> > Fedora
> > 32 since the Bugzillas were opened.
> >
> > If you can fix your package to build, perform a build in koji, and either 
> > create
> > an update in bodhi, or close the relevant bug without creating an update, if
> > updating is not appropriate. If you are working on a fix, set the status to
> > ASSIGNED to acknowledge this and prevent the orphaning.
> >
> > Oprhaning is a easily revertible nondesctructiove action.
> > Only packages orphaned for 6+ weeks will be retired (removed from) Fedora
> > rawhide (i.e. not form Fedora 32).
>
> Done.

(snip)

> Orphaned:

> graphite2
> libaccounts-glib

I've taken these two, since my packages transitively depend on them.
The build failures don't look too difficult, I'll try to resolve them tomorrow.

Fabio

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

Re: Rawhide update from side tag pending for 2 days

[Mohan Boddu]

On Tue, Apr 7, 2020 at 8:34 AM Fabio Valentini  wrote:
>
> On Tue, Apr 7, 2020 at 8:56 AM Richard W.M. Jones  wrote:
> >
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> >
> > This one is a Rawhide update from a side tag, submitted on Sunday
> > morning which has been in pending for 2 days.  (As it's Rawhide it's
> > supposed to spend 0 days in testing.)  Is there any problem with it,
> > or do we just have to wait longer?  It is blocking builds of other
> > packages.
>
> Yeah, this update looks stuck ... the koji builds aren't even tagged
> into the right tags yet, neither are they signed (from what I can
> see).
>
> I seem to have the same - or at least a similar - issue with three
> updates that are also stuck in pending for two days already (and the
> builds are not even signed yet, either):
>
> - https://bodhi.fedoraproject.org/updates/FEDORA-2020-460f0f4d48
> - https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ea279079e
> - https://bodhi.fedoraproject.org/updates/FEDORA-2020-755f442b4c

This is a different case, can you file a ticket at
https://pagure.io/releng/new_issue. I am guessing this is caused by
the recent release of enabling side tags in now rawhide releases.

>
> Those three were also made from side tags, but for stable releases, so
> I'm not sure whether it's the same issue or not.
>
> Fabio
>
> > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days

[Mohan Boddu]

I guess it should be a fixed in bodhi. But for now you can remove the
builds that it's complaining about in the update.

https://github.com/fedora-infra/bodhi/issues/3991

On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones  wrote:
>
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
>
> This one is a Rawhide update from a side tag, submitted on Sunday
> morning which has been in pending for 2 days.  (As it's Rawhide it's
> supposed to spend 0 days in testing.)  Is there any problem with it,
> or do we just have to wait longer?  It is blocking builds of other
> packages.
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Gordon Messmer]

On 4/6/20 5:19 AM, Alex Scheel wrote:

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



I tend to think that a survey would be less useful than a list of 
dist-git integrations that will need to be rebuilt in order to move that 
service and an estimate of man-hours required, vs a list of feature gap 
and estimated cost to close it.

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

Fedora 33 System-Wide Change proposal: OpenSSL 3.0

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/OpenSSL3.0

== Summary ==
The OpenSSL package is rebased to version 3.0 and the dependent
packages are rebuilt.

== Owner ==
* Name: [[User:Tmraz| Tomáš Mráz]]
* Email: 

== Detailed Description ==

The OpenSSL 3.0 release is going to be a significantly new release
with changed ABI however with minimal API changes. That means most of
the dependent packages will need just a rebuild to work with the new
OpenSSL package. However (at least temporarily) a compat-openssl11
package will be provided along the base package so the operation of
the Rawhide is not disrupted.

The OpenSSL 3.0 is still in development now but a first beta release
should be done in June. After that time the work on the rebase will
start and it should be possible to finish it still with a beta
releases. Later releases up to the final one should not be disruptive
and they should not break API/ABI.

== Benefit to Fedora ==

This change introduces OpenSSL 3.0 with its significantly reworked
internals which allow for better replacement of the crypto
implementations via the
[https://www.openssl.org/docs/OpenSSL300Design.html Crypto Providers]
concept.

== Scope ==

* Proposal owners: Provide a compat-openssl11 package, identify
dependent packages, provide the rebased openssl package, work with
dependent package owners on rebuilds.

* Other developers: Dependent package owners rebuild their packages.
Most of the dependencies will not require code changes but for some
more fragile dependencies (mostly language bindings) there might be
changes needed especially in the test cases which depend on some
legacy behavior.

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] If compat package is provided a mass rebuild should not be
necessary.

* Policies and guidelines: No update of packaging guidelines or other
policies should be needed.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

If compat-openssl11 package is provided there should be no issues with upgrades.

== How To Test ==
If your application uses OpenSSL to communicate via TLS or perform
other tasks that use cryptographic algorithms from OpenSSL, please
test whether it continues to work properly. This should be covered by
the comprehensive upstream testsuite of OpenSSL. However many
dependent packages also provide good test coverage of OpenSSL
functionality.

== User Experience ==
There should be no impact on end-user experience.

== Dependencies ==
There are many packages which depend on libssl or libcrypto from
OpenSSL. Most of them should just work after rebuild with the new
openssl package. However it is also not critically needed to rebuild
everything at once if compat library compat-openssl11 package is
provided.

== Contingency Plan ==

If the openssl-3.0 is too unstable before the branching point of
Fedora 33 we will not update the package and delay the change to
Fedora 34.

If the openssl is already updated but it is found out to be too
unstable later we can revert to previous version however a rebuild of
all dependencies that were already rebuilt will be needed.

* Contingency mechanism: Revert package, rebuild updated dependencies.
* Contingency deadline: Before release
* Blocks release? No
* Blocks product? No

== Documentation ==

[https://www.openssl.org/docs/OpenSSL300Design.html OpenSSL 3.0
upstream design document]

[https://www.openssl.org/policies/releasestrat.html OpenSSL 3.0
release schedule]

== Release Notes ==

Fedora 33 comes with OpenSSL 3.0 as the primary OpenSSL package. It
brings support for Crypto Providers interface.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide update from side tag pending for 2 days

[Mohan Boddu]

On Tue, Apr 7, 2020 at 8:57 AM Rex Dieter  wrote:
>
> Richard W.M. Jones wrote:
>
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> >
> > This one is a Rawhide update from a side tag, submitted on Sunday
> > morning which has been in pending for 2 days.  (As it's Rawhide it's
> > supposed to spend 0 days in testing.)  Is there any problem with it,
> > or do we just have to wait longer?  It is blocking builds of other
> > packages.
>
> I saw the same thing, and submitted a infra ticket about it,
> https://pagure.io/fedora-infrastructure/issue/8819

In https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c, I
can see that qt-creator-4.12.0-0.3.rc1.fc33 is the latest version and
the latest build compared to the qt-creator-4.12.0-0.2.beta1.fc33
build in the update. You can remove the build from the update to move
it to stable.

>
> -- Rex
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Replace buildroot overrides with user side tags?

[Mohan Boddu]

This is a great idea, but I wouldn't recommend removing buildroot
overrides totally for one more reason than the others that are already
mentioned here. Side tags are resource intensive compared to buildroot
override as each side tag needs its own buildroot.

On Sat, Apr 4, 2020 at 5:02 PM Richard Shaw  wrote:
>
> On Sat, Apr 4, 2020 at 3:52 PM Neal Gompa  wrote:
>>
>> On Sat, Apr 4, 2020 at 4:50 PM Richard Shaw  wrote:
>> >
>> > To be clear, I've only used them for rawhide, but can they be used in 
>> > other branches?
>> >
>>
>> As of last Monday, yes. There are still some quirks to iron out, though...
>
>
> Awesome! Not only are they easier to use but being able to choose the side 
> tag in the Bodhi web interface makes pushing the updates painless!
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: koji wait-repo (newRepo) is really taking a long time

[Mohan Boddu]

Things should be getting better now

https://pagure.io/koji/issue/2119#comment-640757

On Sat, Apr 4, 2020 at 5:13 AM Richard W.M. Jones  wrote:
>
> On Sat, Apr 04, 2020 at 12:42:29AM +0200, Miro Hrončok wrote:
> > On 03. 04. 20 13:03, Richard W.M. Jones wrote:
> > >
> > >I've been waiting on:
> > >
> > >$ koji wait-repo f33-build-side-20855 --build=ocaml-lacaml-9.3.2-17.fc33
> > >
> > >for hours now.  Seems like newRepo generation is again taking a very
> > >long time?
> > >
> > >Also it'd be nice if this command didn't time out after 2 hours
> > >(seems like a very odd and arbitrary choice - why not wait forever?)
> > >and also coped with transient network failures.
> >
> > For timeout, there is:
> >
> >   --timeout=TIMEOUT  Amount of time to wait (in minutes) before giving up
> >  (default: 120)
> >
> > For network issues, I've been using:
> >
> > while ! koji wait-repo ...; do sleep 15; done
> >
> > ...quite successfully.
>
> Thanks, hopefully with this change it'll be more robust:
>
> http://git.annexia.org/?p=goals.git;a=commitdiff;h=cda1f0160b96e57a0037085f33aa2d440453a30b
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Network Time Security

[Kevin Fenzi]

On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote:
> On 4/6/20 4:08 PM, Ben Cotton wrote:
> > [snip]
> > 
> > 
> 
> It doesn't make much sense to me for this to default to on if we still
> "trust" the DNS servers provided over DHCP. Additionally, it's not clear to
> me from the proposal what it would take for an NTP server provided over DHCP
> to be "trusted", or what a "trusted network" is. Are only NTS-enabled
> sources to be trusted?
> 
> What becomes of the old default fedora.pool.ntp.org?
> 
> Finally, from a purely personal standpoint, I don't like seeing yet more
> infrastructure being handed over to a hyperscaler like Cloudflare (see also
> DoH in Firefox). I would be less opposed to this being default if
> pool.ntp.org found a way to support it.

I don't know the answers to your questions on the change, but just FYI,
firefox in Fedora is not using DoH. 

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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Charalampos Stratakis]

- Original Message -
> From: "Stephen Gallagher" 
> To: devel-annou...@lists.fedoraproject.org
> Sent: Monday, April 6, 2020 11:53:47 PM
> Subject: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I've just published a fourth version[1] of the ELN proposal. With a
> lot of input from Miro Hrončok, I think I've finally been able to
> clarify some of the points that we were getting hung up on.
> 
> Changes in this version of the proposal[2]:
> 
> * Improve our explanation of why we are doing ELN in the first place
> * Clarify the relationship with Rawhide
> * Better describe what happens if packages don't build on ELN
> * Explain our plan for when to use conditionals (this was getting a
> larger share of the conversation than it warranted because we didn't
> do a good job of explaining that they should be the exception and not
> the rule)
> * Clarify that the time limit on PRs is only for determining if the
> maintainer is responsive. If they reply, the timer is cleared.
> * Fixed the question about upstream features to make it clear that
> what we meant is that new features should go upstream first, not be
> implemented as a fork in ELN
> * Added a section explaining how we will deal with side-tags
> * Make it clear that we don't want to diverge wherever possible and
> that any planned divergence should be discussed with the ELN SIG ahead
> of time
> * Cleaned up the contingency plan section.
> 
> I hope that these changes will make our position more clear. Thank you
> to everyone who has contributed to this discussion. I think the
> feedback has been very valuable and I sincerely appreciate it.
> 
> 
> 
> [1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> [2]
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=570854&oldid=570256
> -BEGIN PGP SIGNATURE-
> 
> iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo
> bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp
> eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn
> EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk
> 3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/
> f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq
> rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW
> IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY
> Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI
> 8ShPIeos
> =+lwN
> -END PGP SIGNATURE-
> ___
> 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
> 

I've glanced briefly through the changes, and while I didn't have time to 
properly solicit feedback on the info, I would like to say a big thank you for 
hearing our feedback and working with that.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher  wrote:
> I've just published a fourth version[1] of the ELN proposal. With a
> lot of input from Miro Hrončok, I think I've finally been able to
> clarify some of the points that we were getting hung up on.

Up to this point, we've been a little vague on what "there will
eventually be a way to maintain a fork of your package that will go
into RHEL" actually means. I can finally make this clearer:

- From now until RHEL 9 Alpha ships, work that is intended for
inclusion in RHEL 9 should be contributed to Fedora Rawhide (later,
F34 branch). After Alpha ships, a branch of CentOS Stream will open
that will accept contributions towards RHEL 9 Beta.

I'm pretty excited about this, myself.
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6MzJQACgkQRduFpWgo
bRHp0Av9G5HQD5rdP9JQOtmk2bWfCIXLF0fabZrjPZogIyDVEeEfNQdyledQQnDQ
RQWpwVP9nYeAjYAOSSAasSnN3jJ71uc08IOYQbHs1hSW+FSM06RNraan4r2rhYOj
/fWBtwZGABDMLzNrwZqmD6xDtk93yFTo4TWIUWiOwjr02TIIL8A/xiat7TsMHJtS
90INry2rQ3qi5OeTTTHQf6bQPHP8FRNTIcgmispObJchHtAPbUKcn6n45b/L5mB6
94GVpYf56J3MLoJp2r5TbIdxuJMQSpVwPpk2AbjbWdAQA2SR8LSLU9+HAINiTKQV
qBmOpHFGTK4e8+VE5W7pqo/sswDminRlCrXd/VQcx6C0jg/AWEQ21JG/DcRvDquP
n8rMyMf7SKkpj2os3y63MfNXvbm3BHs1BT7znaLbopZG0GxorPsSE/MvwQX9HVka
nXEGZn7pqXaUhOLWT8+hp0MSQUhkb2j0CVxESsM6AE6u/HGonBR8+T6cDpvP8/EO
V1QcdQ6M
=nb+r
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 2:49 PM James Cassell
 wrote:
> eln9.100.0 makes the relation to RHEL cycle obvious without looking like a 
> RHEL tag. Is dot allowed here? Do we need eln9_100_1?

The dots would be permissible here.

That said, can you describe what value you see in having the RHEL
cycle represented in the RPM name? (Because that's basically the only
practical effect here.) Particularly if you consider that we do not
plan to have mass-rebuilds scheduled around RHEL releases, so a
package that isn't updated for a long time after ELN starts tracking
towards RHEL 10 is going to start confusing people the same way that
having ".fc30" packages in Fedora 31 continues to do.

I'm not saying "no", I'd just like to hear a clear value justification
for carrying that number in the package name.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Detecting when building under mock?

[Scott Talbert]

On Tue, 7 Apr 2020, Paul Howarth wrote:


Is there a recommended way for detecting when a package is being
built under mock?  I have a package where some tests fail due to
various things not being present in a mock container, e.g, /dev/log
doesn't exist.  I can just disable these tests downstream, but
upstream might take a change if I can wrap them in a "if !mock"
condition.


Why not test for the presence of /dev/log before running such tests?


Well, in the particular case of that test, checking whether /dev/log 
exists *is* the test.


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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[James Cassell]

On Tue, Apr 7, 2020, at 2:42 PM, Josh Boyer wrote:
> On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher  wrote:
> >
> > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa  wrote:
> > > > > This definitely solves the issue I've been thinking of. I'm not sure I
> > > > > understand why we want to disconnect the ELN version from the upcoming
> > > > > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > > > > separate when we all know this is about building the next RHEL major,
> > > > > and we all know what the next version is, and we all know the
> > > > > timelines.
> > > >
> > > > Don't get me wrong, I am not trying to hide the fact that we are
> > > > building RHEL type of packages.
> > > >
> > > > But
> > > > 1) aligning those versions is a more complex task than it looks.
> > > >
> > > > Historically we had this %rhel macro to map to next release version
> > > > working, because we were building Fedora content for RHEL only during
> > > > the specific phase of RHEL development, where this number is known and
> > > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
> > > > it is not that clear when exactly the jump of this version will
> > > > happen. Because of the continuity the mapping between eln packages and
> > > > RHEL packages is less obvious: It depends on which phase internal RHEL
> > > > development is. but more to that, it can depend on which phase the
> > > > development of a specific package is, as some packages can diverge
> > > > from upstream earlier than others.
> > > >
> > > > So this eln to rhel mapping is a more complicated topic, then mapping
> > > > EPEL to RHEL for example. And we probably will have to rethink it
> > > > several times in the next couple of years.
> > > >
> > > > 2) we may need to bump version of the eln buildroot much more often
> > > > than RHEL does major releases.
> > > >
> > > > As it comes from the use cases and the problem you have described, we
> > > > want to actively experiment with the buildroot setup. So it makes
> > > > sense to track it through versioning.
> > > >
> > >
> > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes
> > > sense. With that adjustment, at least from my perspective I think this
> > > is okay.
> >
> > The other piece of it is that there's a UX/psychological piece to it.
> > If we call it .eln9.1.0, people are quite likely to skim over the 'n'
> > and confuse themselves into thinking it's a RHEL 9.1.0 package. That
> > way lies a support nightmare. We absolutely agree with your assessment
> > that the dist tag needs to be versioned (see my earlier mail), but we
> > want to disambiguate it so it doesn't look like a real RHEL package.
> > (I'm debating starting with a higher number like 100 so it doesn't get
> > confused with Fedora or RHEL versions that we're likely to see any day
> > soon.)
> 
> I appreciate the amount of thought that went into that.  It's not
> something most people even consider, and I think your concerns are
> well founded.  Thanks for thinking that through!
> 

eln9.100.0 makes the relation to RHEL cycle obvious without looking like a RHEL 
tag. Is dot allowed here? Do we need eln9_100_1?

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

Re: Detecting when building under mock?

[Paul Howarth]

On Tue, 7 Apr 2020 11:43:26 -0400 (EDT)
Scott Talbert  wrote:

> Is there a recommended way for detecting when a package is being
> built under mock?  I have a package where some tests fail due to
> various things not being present in a mock container, e.g, /dev/log
> doesn't exist.  I can just disable these tests downstream, but
> upstream might take a change if I can wrap them in a "if !mock"
> condition.

Why not test for the presence of /dev/log before running such tests?

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Josh Boyer]

On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher  wrote:
>
> On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa  wrote:
> > > > This definitely solves the issue I've been thinking of. I'm not sure I
> > > > understand why we want to disconnect the ELN version from the upcoming
> > > > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > > > separate when we all know this is about building the next RHEL major,
> > > > and we all know what the next version is, and we all know the
> > > > timelines.
> > >
> > > Don't get me wrong, I am not trying to hide the fact that we are
> > > building RHEL type of packages.
> > >
> > > But
> > > 1) aligning those versions is a more complex task than it looks.
> > >
> > > Historically we had this %rhel macro to map to next release version
> > > working, because we were building Fedora content for RHEL only during
> > > the specific phase of RHEL development, where this number is known and
> > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
> > > it is not that clear when exactly the jump of this version will
> > > happen. Because of the continuity the mapping between eln packages and
> > > RHEL packages is less obvious: It depends on which phase internal RHEL
> > > development is. but more to that, it can depend on which phase the
> > > development of a specific package is, as some packages can diverge
> > > from upstream earlier than others.
> > >
> > > So this eln to rhel mapping is a more complicated topic, then mapping
> > > EPEL to RHEL for example. And we probably will have to rethink it
> > > several times in the next couple of years.
> > >
> > > 2) we may need to bump version of the eln buildroot much more often
> > > than RHEL does major releases.
> > >
> > > As it comes from the use cases and the problem you have described, we
> > > want to actively experiment with the buildroot setup. So it makes
> > > sense to track it through versioning.
> > >
> >
> > Makes some sense to me. I'm a bit skeptical, but the reasoning makes
> > sense. With that adjustment, at least from my perspective I think this
> > is okay.
>
> The other piece of it is that there's a UX/psychological piece to it.
> If we call it .eln9.1.0, people are quite likely to skim over the 'n'
> and confuse themselves into thinking it's a RHEL 9.1.0 package. That
> way lies a support nightmare. We absolutely agree with your assessment
> that the dist tag needs to be versioned (see my earlier mail), but we
> want to disambiguate it so it doesn't look like a real RHEL package.
> (I'm debating starting with a higher number like 100 so it doesn't get
> confused with Fedora or RHEL versions that we're likely to see any day
> soon.)

I appreciate the amount of thought that went into that.  It's not
something most people even consider, and I think your concerns are
well founded.  Thanks for thinking that through!

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

Re: Fedora 33 Self-Contained Change proposal: Network Time Security

[Brandon Nielsen]

On 4/6/20 4:08 PM, Ben Cotton wrote:

[snip]




It doesn't make much sense to me for this to default to on if we still 
"trust" the DNS servers provided over DHCP. Additionally, it's not clear 
to me from the proposal what it would take for an NTP server provided 
over DHCP to be "trusted", or what a "trusted network" is. Are only 
NTS-enabled sources to be trusted?


What becomes of the old default fedora.pool.ntp.org?

Finally, from a purely personal standpoint, I don't like seeing yet more 
infrastructure being handed over to a hyperscaler like Cloudflare (see 
also DoH in Firefox). I would be less opposed to this being default if 
pool.ntp.org found a way to support it.

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

Re: @core install picking up desktop packages

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 07, 2020 at 11:46:20AM -0400, Steve Grubb wrote:
> I think out of this whole experience, there might need to be a rule that any 
> weak depency added to a package in @Core should not result in pulling is a 
> nearly working desktop. Maybe that should also be extended to @Base?

That's pretty much what the reporting produced by Minimization
Objective [1] is looking at. There is no automatic enforcement though.

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

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Neal Gompa]

On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher  wrote:
>
> On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa  wrote:
> > > > This definitely solves the issue I've been thinking of. I'm not sure I
> > > > understand why we want to disconnect the ELN version from the upcoming
> > > > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > > > separate when we all know this is about building the next RHEL major,
> > > > and we all know what the next version is, and we all know the
> > > > timelines.
> > >
> > > Don't get me wrong, I am not trying to hide the fact that we are
> > > building RHEL type of packages.
> > >
> > > But
> > > 1) aligning those versions is a more complex task than it looks.
> > >
> > > Historically we had this %rhel macro to map to next release version
> > > working, because we were building Fedora content for RHEL only during
> > > the specific phase of RHEL development, where this number is known and
> > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
> > > it is not that clear when exactly the jump of this version will
> > > happen. Because of the continuity the mapping between eln packages and
> > > RHEL packages is less obvious: It depends on which phase internal RHEL
> > > development is. but more to that, it can depend on which phase the
> > > development of a specific package is, as some packages can diverge
> > > from upstream earlier than others.
> > >
> > > So this eln to rhel mapping is a more complicated topic, then mapping
> > > EPEL to RHEL for example. And we probably will have to rethink it
> > > several times in the next couple of years.
> > >
> > > 2) we may need to bump version of the eln buildroot much more often
> > > than RHEL does major releases.
> > >
> > > As it comes from the use cases and the problem you have described, we
> > > want to actively experiment with the buildroot setup. So it makes
> > > sense to track it through versioning.
> > >
> >
> > Makes some sense to me. I'm a bit skeptical, but the reasoning makes
> > sense. With that adjustment, at least from my perspective I think this
> > is okay.
>
> The other piece of it is that there's a UX/psychological piece to it.
> If we call it .eln9.1.0, people are quite likely to skim over the 'n'
> and confuse themselves into thinking it's a RHEL 9.1.0 package. That
> way lies a support nightmare. We absolutely agree with your assessment
> that the dist tag needs to be versioned (see my earlier mail), but we
> want to disambiguate it so it doesn't look like a real RHEL package.
> (I'm debating starting with a higher number like 100 so it doesn't get
> confused with Fedora or RHEL versions that we're likely to see any day
> soon.)

Okay then. :)


-- 
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa  wrote:
> > > This definitely solves the issue I've been thinking of. I'm not sure I
> > > understand why we want to disconnect the ELN version from the upcoming
> > > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > > separate when we all know this is about building the next RHEL major,
> > > and we all know what the next version is, and we all know the
> > > timelines.
> >
> > Don't get me wrong, I am not trying to hide the fact that we are
> > building RHEL type of packages.
> >
> > But
> > 1) aligning those versions is a more complex task than it looks.
> >
> > Historically we had this %rhel macro to map to next release version
> > working, because we were building Fedora content for RHEL only during
> > the specific phase of RHEL development, where this number is known and
> > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
> > it is not that clear when exactly the jump of this version will
> > happen. Because of the continuity the mapping between eln packages and
> > RHEL packages is less obvious: It depends on which phase internal RHEL
> > development is. but more to that, it can depend on which phase the
> > development of a specific package is, as some packages can diverge
> > from upstream earlier than others.
> >
> > So this eln to rhel mapping is a more complicated topic, then mapping
> > EPEL to RHEL for example. And we probably will have to rethink it
> > several times in the next couple of years.
> >
> > 2) we may need to bump version of the eln buildroot much more often
> > than RHEL does major releases.
> >
> > As it comes from the use cases and the problem you have described, we
> > want to actively experiment with the buildroot setup. So it makes
> > sense to track it through versioning.
> >
>
> Makes some sense to me. I'm a bit skeptical, but the reasoning makes
> sense. With that adjustment, at least from my perspective I think this
> is okay.

The other piece of it is that there's a UX/psychological piece to it.
If we call it .eln9.1.0, people are quite likely to skim over the 'n'
and confuse themselves into thinking it's a RHEL 9.1.0 package. That
way lies a support nightmare. We absolutely agree with your assessment
that the dist tag needs to be versioned (see my earlier mail), but we
want to disambiguate it so it doesn't look like a real RHEL package.
(I'm debating starting with a higher number like 100 so it doesn't get
confused with Fedora or RHEL versions that we're likely to see any day
soon.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Neal Gompa]

On Tue, Apr 7, 2020 at 2:11 PM Aleksandra Fedorova  wrote:
>
> On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa  wrote:
> >
> > On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova  
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok  wrote:
> > > >
> > > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > > > >> What I'm confused about is the hangup with versioning the ELN tree.
> > > > >> Why is this a problem?
> > > > > I explained it in one of the previous threads:
> > > > >
> > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > > >
> > > > > But I guess we need to extend this conversion by answering:
> > > > > 1) versioning of what exactly?
> > > > > 2) versioning by which number?
> > > > >
> > > > >  From the problem you describe, it looks like the solution for it is 
> > > > > to
> > > > > have %{?dist} resolved to a versioned data. But the versioning here
> > > > > should be independent from both RHEL and Fedora versioning. It should
> > > > > be based on changes in eln buildroot configuration itself: As soon as
> > > > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > > > And this action is not linked to Fedora or RHEL releases. This number
> > > > > may as well be the date, or a simple counter.
> > > > >
> > > > > If we do versioning in this way, then it resolves both concerns I had
> > > > > in my reply there:
> > > > > 1) we don't try to link to particular RHEL release;
> > > > > 2) we don't version the koji tag and target, and we don't need to
> > > > > update Koji configuration every time Fedora creates a branch. Thus the
> > > > > pipelines we create for building eln packages can still be
> > > > > unversioned.
> > > >
> > > >
> > > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > > > particular "the versioning here should be independent from RHEL" and 
> > > > "we don't
> > > > try to link to particular RHEL release" is very weird considering that 
> > > > %{eln}
> > > > and %{rhel} will evaluate to "next RHEL version".
> > >
> > > You are right. Originally we were thinking of %{eln} as a boolean,
> > > rather than a meaningful data. So the important part was that we set
> > > it to something, so that in those very rare cases where we may want to
> > > have a condition based on eln, we can use it.
> > > We defined %{eln} to be "something", and that something just happened
> > > to be %{rhel}.
> > >
> > > But since we are talking about versioning for eln now, it makes sense
> > > to use this macro to store the actual data about eln buildroot.
> > >
> > > So I am thinking of adjusting the change in the following form:
> > >
> > > 
> > > * %{rhel} will be set and will return a number one higher than the
> > > most recent major release of Red Hat Enterprise Linux (at present,
> > > that will be 9).
> > > * %{eln} will be set and will expand to the ELN version (independent
> > > of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
> > > rebuilds, Y - for other changes.
> > > * %{dist} will be set to "eln%{eln}"
> > >
> > > Explicit usage of %{eln} macro in spec files should be discouraged. As
> > > its main purpose is the versioning of the build environment, not
> > > adjusting the sources.
> > > 
> > >
> > > This way we can experiment with the configuration ELN-buildroot
> > > without bumping package sources.
> > >
> > > And we will have RHEL versioning available, but not directly, which
> > > adds some flexibility in relation between ELN and RHEL.
> > >
> >
> > This definitely solves the issue I've been thinking of. I'm not sure I
> > understand why we want to disconnect the ELN version from the upcoming
> > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > separate when we all know this is about building the next RHEL major,
> > and we all know what the next version is, and we all know the
> > timelines.
>
> Don't get me wrong, I am not trying to hide the fact that we are
> building RHEL type of packages.
>
> But
> 1) aligning those versions is a more complex task than it looks.
>
> Historically we had this %rhel macro to map to next release version
> working, because we were building Fedora content for RHEL only during
> the specific phase of RHEL development, where this number is known and
> fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
> it is not that clear when exactly the jump of this version will
> happen. Because of the continuity the mapping between eln packages and
> RHEL packages is less obvious: It depends on which phase internal RHEL
> development is. but more to that, it can depend on which phase the
> development of a specific package is, as some packages can diverge
> from upstream earlier than others.
>
> So this eln to rhel mapping is a more complicated topic, then mapping
> EPEL to 

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Aleksandra Fedorova]

On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa  wrote:
>
> On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova  wrote:
> >
> > Hi,
> >
> > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok  wrote:
> > >
> > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > > >> What I'm confused about is the hangup with versioning the ELN tree.
> > > >> Why is this a problem?
> > > > I explained it in one of the previous threads:
> > > >
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > >
> > > > But I guess we need to extend this conversion by answering:
> > > > 1) versioning of what exactly?
> > > > 2) versioning by which number?
> > > >
> > > >  From the problem you describe, it looks like the solution for it is to
> > > > have %{?dist} resolved to a versioned data. But the versioning here
> > > > should be independent from both RHEL and Fedora versioning. It should
> > > > be based on changes in eln buildroot configuration itself: As soon as
> > > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > > And this action is not linked to Fedora or RHEL releases. This number
> > > > may as well be the date, or a simple counter.
> > > >
> > > > If we do versioning in this way, then it resolves both concerns I had
> > > > in my reply there:
> > > > 1) we don't try to link to particular RHEL release;
> > > > 2) we don't version the koji tag and target, and we don't need to
> > > > update Koji configuration every time Fedora creates a branch. Thus the
> > > > pipelines we create for building eln packages can still be
> > > > unversioned.
> > >
> > >
> > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > > particular "the versioning here should be independent from RHEL" and "we 
> > > don't
> > > try to link to particular RHEL release" is very weird considering that 
> > > %{eln}
> > > and %{rhel} will evaluate to "next RHEL version".
> >
> > You are right. Originally we were thinking of %{eln} as a boolean,
> > rather than a meaningful data. So the important part was that we set
> > it to something, so that in those very rare cases where we may want to
> > have a condition based on eln, we can use it.
> > We defined %{eln} to be "something", and that something just happened
> > to be %{rhel}.
> >
> > But since we are talking about versioning for eln now, it makes sense
> > to use this macro to store the actual data about eln buildroot.
> >
> > So I am thinking of adjusting the change in the following form:
> >
> > 
> > * %{rhel} will be set and will return a number one higher than the
> > most recent major release of Red Hat Enterprise Linux (at present,
> > that will be 9).
> > * %{eln} will be set and will expand to the ELN version (independent
> > of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
> > rebuilds, Y - for other changes.
> > * %{dist} will be set to "eln%{eln}"
> >
> > Explicit usage of %{eln} macro in spec files should be discouraged. As
> > its main purpose is the versioning of the build environment, not
> > adjusting the sources.
> > 
> >
> > This way we can experiment with the configuration ELN-buildroot
> > without bumping package sources.
> >
> > And we will have RHEL versioning available, but not directly, which
> > adds some flexibility in relation between ELN and RHEL.
> >
>
> This definitely solves the issue I've been thinking of. I'm not sure I
> understand why we want to disconnect the ELN version from the upcoming
> RHEL version, even in the DistTag? It seems to be a weird hoop to
> separate when we all know this is about building the next RHEL major,
> and we all know what the next version is, and we all know the
> timelines.

Don't get me wrong, I am not trying to hide the fact that we are
building RHEL type of packages.

But
1) aligning those versions is a more complex task than it looks.

Historically we had this %rhel macro to map to next release version
working, because we were building Fedora content for RHEL only during
the specific phase of RHEL development, where this number is known and
fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
it is not that clear when exactly the jump of this version will
happen. Because of the continuity the mapping between eln packages and
RHEL packages is less obvious: It depends on which phase internal RHEL
development is. but more to that, it can depend on which phase the
development of a specific package is, as some packages can diverge
from upstream earlier than others.

So this eln to rhel mapping is a more complicated topic, then mapping
EPEL to RHEL for example. And we probably will have to rethink it
several times in the next couple of years.

2) we may need to bump version of the eln buildroot much more often
than RHEL does major releases.

As it comes from the use cases and the problem you have described, we
want to

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Neal Gompa]

On Tue, Apr 7, 2020 at 2:02 PM Stephen Gallagher  wrote:
>
> On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa  wrote:
> > This definitely solves the issue I've been thinking of. I'm not sure I
> > understand why we want to disconnect the ELN version from the upcoming
> > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > separate when we all know this is about building the next RHEL major,
> > and we all know what the next version is, and we all know the
> > timelines.
>
> It's not about being cagey about the release, it's actually about us
> retaining the ability to perform a rebuild without needing to push a
> release-bump into the Fedora dist-git for issues that are
> ELN-specific. (For example, ELN might carry a link-time-optimization
> flag that we discover causes bugs to appear on certain packages. That
> flag isn't used on Fedora, so we wouldn't want to bother the
> maintainer with a version bump. We'd just bump the Y value of %{eln}
> and resubmit it to Koji, which would then not have a duplicate NEVRA
> appearing.

That part I get... I mean, why not eln%{rhel}.X.Y?


-- 
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa  wrote:
> This definitely solves the issue I've been thinking of. I'm not sure I
> understand why we want to disconnect the ELN version from the upcoming
> RHEL version, even in the DistTag? It seems to be a weird hoop to
> separate when we all know this is about building the next RHEL major,
> and we all know what the next version is, and we all know the
> timelines.

It's not about being cagey about the release, it's actually about us
retaining the ability to perform a rebuild without needing to push a
release-bump into the Fedora dist-git for issues that are
ELN-specific. (For example, ELN might carry a link-time-optimization
flag that we discover causes bugs to appear on certain packages. That
flag isn't used on Fedora, so we wouldn't want to bother the
maintainer with a version bump. We'd just bump the Y value of %{eln}
and resubmit it to Koji, which would then not have a duplicate NEVRA
appearing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Neal Gompa]

On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova  wrote:
>
> Hi,
>
> On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok  wrote:
> >
> > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > >> What I'm confused about is the hangup with versioning the ELN tree.
> > >> Why is this a problem?
> > > I explained it in one of the previous threads:
> > >
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > >
> > > But I guess we need to extend this conversion by answering:
> > > 1) versioning of what exactly?
> > > 2) versioning by which number?
> > >
> > >  From the problem you describe, it looks like the solution for it is to
> > > have %{?dist} resolved to a versioned data. But the versioning here
> > > should be independent from both RHEL and Fedora versioning. It should
> > > be based on changes in eln buildroot configuration itself: As soon as
> > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > And this action is not linked to Fedora or RHEL releases. This number
> > > may as well be the date, or a simple counter.
> > >
> > > If we do versioning in this way, then it resolves both concerns I had
> > > in my reply there:
> > > 1) we don't try to link to particular RHEL release;
> > > 2) we don't version the koji tag and target, and we don't need to
> > > update Koji configuration every time Fedora creates a branch. Thus the
> > > pipelines we create for building eln packages can still be
> > > unversioned.
> >
> >
> > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > particular "the versioning here should be independent from RHEL" and "we 
> > don't
> > try to link to particular RHEL release" is very weird considering that 
> > %{eln}
> > and %{rhel} will evaluate to "next RHEL version".
>
> You are right. Originally we were thinking of %{eln} as a boolean,
> rather than a meaningful data. So the important part was that we set
> it to something, so that in those very rare cases where we may want to
> have a condition based on eln, we can use it.
> We defined %{eln} to be "something", and that something just happened
> to be %{rhel}.
>
> But since we are talking about versioning for eln now, it makes sense
> to use this macro to store the actual data about eln buildroot.
>
> So I am thinking of adjusting the change in the following form:
>
> 
> * %{rhel} will be set and will return a number one higher than the
> most recent major release of Red Hat Enterprise Linux (at present,
> that will be 9).
> * %{eln} will be set and will expand to the ELN version (independent
> of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
> rebuilds, Y - for other changes.
> * %{dist} will be set to "eln%{eln}"
>
> Explicit usage of %{eln} macro in spec files should be discouraged. As
> its main purpose is the versioning of the build environment, not
> adjusting the sources.
> 
>
> This way we can experiment with the configuration ELN-buildroot
> without bumping package sources.
>
> And we will have RHEL versioning available, but not directly, which
> adds some flexibility in relation between ELN and RHEL.
>

This definitely solves the issue I've been thinking of. I'm not sure I
understand why we want to disconnect the ELN version from the upcoming
RHEL version, even in the DistTag? It seems to be a weird hoop to
separate when we all know this is about building the next RHEL major,
and we all know what the next version is, and we all know the
timelines.



-- 
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Aleksandra Fedorova]

Hi,

On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok  wrote:
>
> On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> >> What I'm confused about is the hangup with versioning the ELN tree.
> >> Why is this a problem?
> > I explained it in one of the previous threads:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> >
> > But I guess we need to extend this conversion by answering:
> > 1) versioning of what exactly?
> > 2) versioning by which number?
> >
> >  From the problem you describe, it looks like the solution for it is to
> > have %{?dist} resolved to a versioned data. But the versioning here
> > should be independent from both RHEL and Fedora versioning. It should
> > be based on changes in eln buildroot configuration itself: As soon as
> > we want to have a non-disruptive rebuild in eln buildroot, we
> > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > And this action is not linked to Fedora or RHEL releases. This number
> > may as well be the date, or a simple counter.
> >
> > If we do versioning in this way, then it resolves both concerns I had
> > in my reply there:
> > 1) we don't try to link to particular RHEL release;
> > 2) we don't version the koji tag and target, and we don't need to
> > update Koji configuration every time Fedora creates a branch. Thus the
> > pipelines we create for building eln packages can still be
> > unversioned.
>
>
> What you say here is very inconsistent with %{eln} and %{rhel} value. In
> particular "the versioning here should be independent from RHEL" and "we don't
> try to link to particular RHEL release" is very weird considering that %{eln}
> and %{rhel} will evaluate to "next RHEL version".

You are right. Originally we were thinking of %{eln} as a boolean,
rather than a meaningful data. So the important part was that we set
it to something, so that in those very rare cases where we may want to
have a condition based on eln, we can use it.
We defined %{eln} to be "something", and that something just happened
to be %{rhel}.

But since we are talking about versioning for eln now, it makes sense
to use this macro to store the actual data about eln buildroot.

So I am thinking of adjusting the change in the following form:


* %{rhel} will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be 9).
* %{eln} will be set and will expand to the ELN version (independent
of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
rebuilds, Y - for other changes.
* %{dist} will be set to "eln%{eln}"

Explicit usage of %{eln} macro in spec files should be discouraged. As
its main purpose is the versioning of the build environment, not
adjusting the sources.


This way we can experiment with the configuration ELN-buildroot
without bumping package sources.

And we will have RHEL versioning available, but not directly, which
adds some flexibility in relation between ELN and RHEL.



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



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

Fedora 32 compose report: 20200407.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200406.n.0
NEW: Fedora-32-20200407.n.0

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

Size of added packages:  1.72 MiB
Size of dropped packages:17.30 MiB
Size of upgraded packages:   3.11 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -212.80 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-32-20200406.n.0.iso

= ADDED PACKAGES =
Package: ghc-path-io-1.4.2-1.fc32
Summary: Interface to ???directory??? package for users of ???path???
RPMs:ghc-path-io ghc-path-io-devel ghc-path-io-doc ghc-path-io-prof
Size:1.36 MiB

Package: python-pysmt-0.8.0-2.fc32
Summary: Solver-agnostic library for SMT Formulae manipulation and solving
RPMs:python3-pysmt
Size:370.49 KiB


= DROPPED PACKAGES =
Package: mutter328-3.28.4-7.fc32
Summary: Window and compositing manager based on Clutter
RPMs:mutter328 mutter328-devel mutter328-libs mutter328-tests
Size:17.30 MiB


= UPGRADED PACKAGES =
Package:  Zim-0.72.1-1.fc32
Old package:  Zim-0.72.0-2.fc32
Summary:  Desktop wiki & notekeeper
RPMs: Zim
Size: 1.70 MiB
Size change:  2.33 KiB
Changelog:
  * Sun Mar 29 2020 Robin Lee  - 0.72.1-1
  - Update to 0.72.1


Package:  aircrack-ng-1.6-1.fc32
Old package:  aircrack-ng-1.5.2-8.fc32
Summary:  802.11 (wireless) sniffer and WEP/WPA-PSK key cracker
RPMs: aircrack-ng aircrack-ng-devel aircrack-ng-doc
Added RPMs:   aircrack-ng-devel aircrack-ng-doc
Size: 6.01 MiB
Size change:  -9.17 MiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
1.5.2-9
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Mon Apr 06 2020 Vitaly Zaitsev  - 1.6-1
  - Resurrected package.
  - Updated to version 1.6.
  - Performed SPEC cleanup.


Package:  anaconda-32.24.5-1.fc32
Old package:  anaconda-32.24.4-1.fc32
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets 
anaconda-widgets-devel
Size: 19.26 MiB
Size change:  8.98 KiB
Changelog:
  * Fri Apr 03 2020 Martin Kolman  - 32.24.5-1
  - Don't clear errors by expanding pages in the custom spoke (vponcova)
  - Fix the permission for changing a mount point (#1818500) (vponcova)
  - Allow to use an existing unlocked LUKS in one special case (#1772902)
(vponcova)
  - Fix the encryption checkbox in the custom spoke (#1819360) (vponcova)
  - Don't manually trigger a device encryption change (vponcova)
  - Rename _test_dbus_property to _check_dbus_property (jkonecny)


Package:  astrometry-0.78-6.fc32
Old package:  astrometry-0.78-5.fc32
Summary:  Blind astrometric calibration of arbitrary astronomical images
RPMs: astrometry astrometry-data astrometry-data-4204 
astrometry-data-4205 astrometry-data-4206 astrometry-data-4207 astrometry-devel 
astrometry-libs python3-astrometry
Size: 1.77 GiB
Size change:  -57.43 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
0.78-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild


Package:  astrometry-tycho2-2.0-8.fc32
Old package:  astrometry-tycho2-2.0-6.fc31
Summary:  Tycho-2 catalogue for astrometry.net
RPMs: astrometry-tycho2
Size: 812.71 MiB
Size change:  -205.05 MiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.0-7
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Sun Mar 29 2020 Mattia Verga  - 2.0-8
  - Temporarily disable s390 due to astrometry dependency


Package:  atk-2.36.0-1.fc32
Old package:  atk-2.35.1-2.fc32
Summary:  Interfaces for accessibility support
RPMs: atk atk-devel
Size: 2.61 MiB
Size change:  25.60 KiB
Changelog:
  * Thu Apr 02 2020 Kalev Lember  - 2.36.0-1
  - Update to 2.36.0


Package:  boost-1.69.0-15.fc32
Old package:  boost-1.69.0-14.fc32
Summary:  The free peer-reviewed portable C++ source libraries
RPMs: boost boost-atomic boost-build boost-chrono boost-container 
boost-context boost-contract boost-coroutine boost-date-time boost-devel 
boost-doc boost-doctools boost-examples boost-fiber boost-filesystem 
boost-graph boost-graph-mpich boost-graph-openmpi boost-iostreams boost-jam 
boost-locale boost-log boost-math boost-mpich boost-mpich-devel 
boost-mpich-python3 boost-mpich-python3-devel boost-numpy3 boost-openmpi 
boost-openmpi-devel boost-openmpi-python3 boost-openmpi-python3-devel 
boost-program-options boost-python3 boost-python3-devel boost-random 
boost-regex boost-serialization boost-stacktrace boost-static boost-system 
boost-test boost-thread boost-timer boost-type_erasure boost-wave
Size: 310.18 MiB
Size ch

Logs for the Open NeuroFedora Meeting: 1600 UTC on Tuesday, 4th April

[Aniket Pradhan]

Hello people

Thanks for attending the meeting. We shall meet in two weeks' time. I
will share a whenisgood to the NeuroFedora ML to schedule a suitable
time for the next meeting.

Links to the logs from today's meeting:
- 
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.log.html
- 
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.html

Minutes of the meeting in text:

===
#fedora-neuro: NeuroFedora - 2020-04-07
===


Meeting started by MeWjOr at 16:02:30 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.log.html
.



Meeting summary
---
* Agenda for today's meeting  (MeWjOr, 16:05:47)
* Intros/roll call  (MeWjOr, 16:05:56)
* Tasks from last meeting:
  
https://meetbot.fedoraproject.org/fedora-neuro/2020-03-24/neurofedora.2020-03-24-16.00.html
  (MeWjOr, 16:06:07)
* Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
  (MeWjOr, 16:06:14)
* Bugzilla tickets: https://tinyurl.com/neurofedora-bugs  (MeWjOr,
  16:06:20)
* (neuro)science query of the week  (MeWjOr, 16:06:30)
* Next meeting, time, date, chair  (MeWjOr, 16:06:37)
* Open floor  (MeWjOr, 16:06:43)
* Intros/Roll call  (MeWjOr, 16:07:01)

* Tasks from last meeting:
  
https://meetbot.fedoraproject.org/fedora-neuro/2020-03-24/neurofedora.2020-03-24-16.00.html
  (MeWjOr, 16:12:21)
  * FranciscoD submit 3 banner candidates to websites - Done  (MeWjOr,
16:12:58)
  * FranciscoD submit apps and logos to websites - Done  (MeWjOr,
16:13:36)
  * FranciscoD submit all the content to websites - Done  (MeWjOr,
16:13:47)
  * https://pagure.io/fedora-websites/issue/1010  (MeWjOr, 16:13:55)
  * FranciscoD include open position call for: social media manager,
package maintainers, testers in next blog post --- The tracker for
the post is up: https://pagure.io/neuro-sig/NeuroFedora/issue/348
(MeWjOr, 16:14:40)
  * mhough write a blog post about the neurotecx online meetings -
status: pending  (MeWjOr, 16:15:18)

* Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
  (MeWjOr, 16:17:15)
  * NeuroFedora Brochure:
https://pagure.io/neuro-sig/NeuroFedora/issue/301  (MeWjOr,
16:18:33)
  * ACTION: FranciscoD Comment on the ticket to provide feedback on the
neurofedora brochure within the next week  (MeWjOr, 16:23:34)
  * ACTION: MeWjOr Send a mail to the members so that they can provide
feedback on the neurofedora brochure within the next week  (MeWjOr,
16:24:09)
  * Next blog post: https://pagure.io/neuro-sig/NeuroFedora/issue/348
(MeWjOr, 16:24:57)

* Bugzilla bugs: https://tinyurl.com/neurofedora-bugs  (MeWjOr,
  16:32:08)

* Next meeting: time, date, chair  (MeWjOr, 16:37:13)
  * ACTION: MeWjOr set up a new whenisgood and inform ML  (FranciscoD,
16:49:08)
  * ACTION: lbazan to work on pending review tickets  (FranciscoD,
16:49:28)

* (neuro)science query of the week  (MeWjOr, 16:51:23)
  * LINK:

https://alleninstitute.org/what-we-do/brain-science/news-press/press-releases/allen-institute-announces-new-phase-neuroscience-research
(FranciscoD, 16:51:34)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/318  (MeWjOr,
16:52:46)
  * LINK:
https://sourceforge.net/projects/genesis-sim/lists/genesis-sim-users
-> I'll go subscribe to that too  (FranciscoD, 16:56:32)
  * ACTION: MeWjOr send out the meeting logs to the ML  (MeWjOr,
16:57:08)

Meeting ended at 16:57:17 UTC.




Action Items

* FranciscoD Comment on the ticket to provide feedback on the
  neurofedora brochure within the next week
* MeWjOr Send a mail to the members so that they can provide feedback on
  the neurofedora brochure within the next week
* MeWjOr set up a new whenisgood and inform ML
* lbazan to work on pending review tickets
* MeWjOr send out the meeting logs to the ML




Action Items, by person
---
* FranciscoD
  * FranciscoD Comment on the ticket to provide feedback on the
neurofedora brochure within the next week
* lbazan
  * lbazan to work on pending review tickets
* MeWjOr
  * MeWjOr Send a mail to the members so that they can provide feedback
on the neurofedora brochure within the next week
  * MeWjOr set up a new whenisgood and inform ML
  * MeWjOr send out the meeting logs to the ML
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* MeWjOr (98)
* FranciscoD (76)
* mhough (16)
* zodbot (13)
* lbazan (13)
* tg-fedneuro (11)
* fm-neuro (7)
* gicmo (2)
* alciregi (0)
* bt0 (0)
* zbyszek (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


-- 
Thanks
Regards

Aniket Pradhan
http://home.iiitd.edu.in/~aniket17133/
Aliases: MeWjOr/major

()  ascii ribbon campaign - against html e-mail

Re: Modularity Survey

[Adam Williamson]

On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote:
> I'm sure we can trust that Red Hat did its
> 
> due diligence and Google isn't using responses to a customer's form to
> 
> track those taking the survey.

I don't really know why you'd think anyone can trust that. Google
tracks everyone everywhere as hard as it can. It's what Google *does*.

But I didn't actually suggest it's Terribly Awful to run this survey
through Google. I just said the privacy declaration seems to be wrong.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity Survey

[Alex Scheel]

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

(I'm not on the modularity team).

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

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


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

Part of that is collecting data and stories from people.

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


Let's try and be reasonable here.


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



Thanks,

- Alex


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

Re: Modularity Survey

[Xavier Bachelot]

Le 07/04/2020 à 12:29, Kevin Kofler a écrit :

Adam Williamson wrote:

Well. Uh. Clearly it's being provided to *Google*.


Indeed. Once again, Fedora is depending on third-party, proprietary,
privacy-invading SaaS.



Meets exactly my thoughts...
This is yet again another disappointing choice of tool.

I'm not going to give anything to Google, hence I can _not_ answer the 
survey.
Too bad, there is much to be said about modularity, as the lengthy 
threads have already shown.


Unfortunately, Fedora is drifting more and more away from the Libre 
Software philosophy that over time made me a Linux-only user and a 
Fedora packager. At some point, I will have to put my money where my 
mouth is and find another ship.

Yes, I'm bitter...

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

Re: libcdio soname bump in rawhide

[Adrian Reber]

On Mon, Mar 30, 2020 at 09:27:56AM +0200, Adrian Reber wrote:
> I will update libcdio to 2.1.0 next week in rawhide. As always, libcdio
> comes with a new SO version.
> 
> The following packages have to be rebuilt and I will do the necessary
> rebuilds:
> 
> cantata
> cdw
> clementine
> gstreamer1-plugins-ugly-free
> gvfs
> kover
> libcddb
> libcdio-0:2.0.0-6.fc32.src
> libcdio-paranoia
> pcsxr
> pragha
> python-pycdio
> qmmp
> strawberry
> tellico
> whipper
> xmms2

libcdio, libcdio-paranoia and python-pycdio have been updated and all
dependencies have been rebuilt.

Only pcsxr failed rebuilding but it was already FTBFS before the libcdio
upgrade.

Adrian


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

[Test-Announce] Fedora 32 Branched 20200407.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200407.n.0. 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:
anaconda - 20200404.n.0: anaconda-32.24.4-1.fc32.src, 20200407.n.0: 
anaconda-32.24.5-1.fc32.src
lorax - 20200404.n.0: lorax-32.5-2.fc32.src, 20200407.n.0: lorax-32.8-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_20200407.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_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: @core install picking up desktop packages

[Steve Grubb]

On Tuesday, April 7, 2020 11:24:28 AM EDT Adam Williamson wrote:
> On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote:
> > On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote:
> > > Maybe libsecret spec could provide an empty libsecret-never-fail
> > > subpackage that would hard-require a libsecret server and the
> > > applications like geary would require that subpackage. (Alternatively
> > > libsecret-devel could provide a RPM macro that the applications use to
> > > add a direct dependency on a server.) But this abstractions is quite
> > > academic provided the only libsecret server in Fedora is
> > > gnome-keyring.
> > 
> > I wouldn't focus on a particular package because the situation can
> > repeat with any other package in the future, and would make the question
> > more generic.
> > 
> > Is it expected, are we OK with the fact, that with default settings
> > of weak dependencies enabled in dnf and anaconda, installing @group
> > can eventually pull in way more packages than originally listed
> > in the group, beyond the hard dependencies? Should following the weak
> > dependencies be a boolean yes/no setting, or should it be a score and
> > should the resolver have an option to favour weak dependencies when
> > resolving the first level of depenencies from the original package
> > list but decrease (perhaps radically) favouring them in next and
> > next-next-levels, potentially even taking into account if the
> > intermediate dependencies were explicit ones or implicit libraries?
> > 
> > In other words, if I list packages A, B, C in transaction, I might
> > want to have their weak dependencies thrown onto the system as well.
> > But if A requires libX.so and libY.so, and package X requires G and
> > that has weak dependency on K, I might not care about K.
> > 
> > If I explicitly say I want G, then again, sure, give me K as well.
> 
> Boy, I don't know about you but I sure am looking forward to taking a
> degree in math to understand why packages are or are not installed!

I think out of this whole experience, there might need to be a rule that any 
weak depency added to a package in @Core should not result in pulling is a 
nearly working desktop. Maybe that should also be extended to @Base?

-Steve


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

Detecting when building under mock?

[Scott Talbert]

Is there a recommended way for detecting when a package is being built 
under mock?  I have a package where some tests fail due to various things 
not being present in a mock container, e.g, /dev/log doesn't exist.  I can 
just disable these tests downstream, but upstream might take a change if I 
can wrap them in a "if !mock" condition.


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

[Till Hofmann]

On 4/7/20 9:21 AM, Mattia Verga via devel wrote:
> we have updated the script which provides the cached review trackers 
> pages at https://fedoraproject.org/PackageReviewStatus/ (thanks to 
> cverna for the assistance).

It looks like 1821497 [1] is displayed incorrectly (currently at the
bottom of the page), maybe bccause of the unusual title ("Review
Request:  - ")?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1821497
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: @core install picking up desktop packages

[Adam Williamson]

On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote:
> On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote:
> > Maybe libsecret spec could provide an empty libsecret-never-fail subpackage
> > that would hard-require a libsecret server and the applications like geary 
> > would
> > require that subpackage. (Alternatively libsecret-devel could provide a RPM
> > macro that the applications use to add a direct dependency on a server.) But
> > this abstractions is quite academic provided the only libsecret server in
> > Fedora is gnome-keyring.
> 
> I wouldn't focus on a particular package because the situation can
> repeat with any other package in the future, and would make the question
> more generic.
> 
> Is it expected, are we OK with the fact, that with default settings
> of weak dependencies enabled in dnf and anaconda, installing @group
> can eventually pull in way more packages than originally listed
> in the group, beyond the hard dependencies? Should following the weak
> dependencies be a boolean yes/no setting, or should it be a score and
> should the resolver have an option to favour weak dependencies when
> resolving the first level of depenencies from the original package
> list but decrease (perhaps radically) favouring them in next and
> next-next-levels, potentially even taking into account if the
> intermediate dependencies were explicit ones or implicit libraries?
> 
> In other words, if I list packages A, B, C in transaction, I might
> want to have their weak dependencies thrown onto the system as well.
> But if A requires libX.so and libY.so, and package X requires G and
> that has weak dependency on K, I might not care about K.
> 
> If I explicitly say I want G, then again, sure, give me K as well.

Boy, I don't know about you but I sure am looking forward to taking a
degree in math to understand why packages are or are not installed!

(you know, as opposed to the whole thing with the rubber chicken and
the pulley that I do right now)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel

[Adam Williamson]

On Tue, 2020-04-07 at 14:01 +0200, Nicolas Mailhot via devel wrote:
> Le mardi 07 avril 2020 à 06:31 -0400, Paul Dufresne via devel a écrit :
> > Le 20-04-06 à 21 h 01, Paul Dufresne a écrit :
> > > BTW, thanks I was searching for an example of package using a git
> > version rather than a released archive!
> > Just for the record, *I think* the current package is a bad example
> > of a package using a forge like git.
> > 
> > Current 
> > https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/f32/f/xorg-x11-drv-intel.spec
> > does not seems to use the %forgemeta or %forgesetup macros as
> > suggested in 
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
> > (that I just read)
> 
> While documented and official %forge macro use is not mandatory in
> Fedora (of course, if you do things some other way, and the result
> breaks, you ’ve no excuse for the breakage)

Remember, xorg-x11-drv-intel is (obviously) quite an old package. New
packaging stuff gets invented in Fedora *all the time*, and if you're a
maintainer of existing packages you're not necessarily going to want to
spend large chunks of time reading up on the latest FPC deliberations
and updating all your spec files to implement the Cool New Shiny.
Especially if the package works just fine as-is.

None of my packages use this stuff either, because I hadn't heard of it
until right now, it didn't exist when I started packaging stuff from
Github and so on, and I tend to just cargo cult the basic frameworks of
packages around from package to package for stuff I maintain (as I
think many packagers do). I might use it now, because it looks helpful,
but if this thread hadn't happened I might not have noticed it for
another year or two.

So: you can't really accuse any package that doesn't use something
*optional* in the guidelines of being "bad" for that reason. You even
have to accept that older packages may miss some stuff that is now
*mandatory* in the guidelines if no-one took the trouble to go out and
file mass bug reports and so on, because when the guidelines change
there isn't always a process put in place to require or help packagers
to adjust their packages to the change.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updated review trackers pages

[Mattia Verga via devel]

Il 07/04/20 16:01, Ankur Sinha ha scritto:
>
> The list says that there aren't any trivial tickets, but easyfix does
> show one (only one):
> https://fedoraproject.org/PackageReviewStatus/trivial.html
> vs
> https://fedoraproject.org/easyfix/
>
> Could you check this please?
>
Yeah, that's because it's listed in the "in progress" page... that 
ticket has the review flag set and the assignee field is populated, but 
it's state is NEW.

I will add a page to list all tickets in inconsistent state like that one.

Thanks

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

env inside .desktop file

[Ian McInerney]

The Audacity package is currently getting desktop lint errors on x86_64 and 
armv7hl saying:

"diag" : "Exec file /usr/bin/env not found, even in noarch",

when it uses the exec line:

"Exec=env UBUNTU_MENUPROXY=0 audacity %F"

inside its .desktop file.

To me, I don't see anything wrong with this syntax, and it works on user 
machines. Is there something else that needs to be included in the package to 
make the linter not throw an error on this line?

Here is the full desktop linter log: 
https://taskotron.fedoraproject.org/artifacts/all/dba65002-7821-11ea-97e5-525400364adf/tests.yml/rpmgrill.json
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Justin Forbes]

On Tue, Apr 7, 2020 at 3:10 AM Tom Hughes via devel
 wrote:
>
> On 06/04/2020 22:53, Stephen Gallagher wrote:
>
> > Changes in this version of the proposal[2]:
> >
> > * Improve our explanation of why we are doing ELN in the first place
>
> I agree that the proposal is now a lot clearer and I certainly see
> how it furthers the first goral of seeing how Fedora trunk comes
> together asn an EL build, modulo one concern below.
>
> I don't understand how it helps evaluate something like a new
> higher CPU baseline - nobody disputes that packages can be built
> to a new baseline which is what this would prove. The argument
> is about the effect on consumers of such a baseline and about
> what proportion of users/machines would be cut off from further
> upgrades and this proposal does nothing to help with that.

As to what proportion of users/machines would be cut off, we don't
care about the exact number.   It was already established that the
number is an unacceptable amount.  The real question is, how much of a
performance advantage do modern machines get from running things built
for such a baseline.  If there is a significant advantage, then it
becomes worthwhile to explore methods to make relevant packages built
to such a baseline available in standard Fedora.  There have been
various ideas on how to make them available without making them a
required minimum, but all of them involve a non-trivial amount of
work.  It would be a waste of time and energy if the real world
advantage turns out to be minimal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Open NeuroFedora Meeting: 1600 UTC on Tuesday, 7th February

[Aniket Pradhan]

Hello there

We would be starting the meeting in about 2 hours. Would love to see
you all there. ;D

On Mon, Apr 6, 2020 at 2:45 PM Aniket Pradhan
 wrote:
>
> Hello world
>
> You are invited to attend the next Open NeuroFedora team meeting this
> week on Tuesday at 1600UTC in #fedora-neuro on IRC (Freenode):
>
> https://webchat.freenode.net/?channels=#fedora-neuro
>
> You can convert the meeting time to your local time using:
> $ date --date='TZ="UTC" 1600 next Tue'
>
> or use this link:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Team+Meeting&iso=20200407T16&p1=%3A
>
> The meeting will be chaired by @major. The agenda for the meeting is:
>
> - Introductions and roll call.
> - Tasks from last week's meeting: NA
> - Pagure tickets:
> https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
> - Neuroscience query of the week.
> - Next meeting day, and chair.
> - Open floor.
>
> In the "Neuroscience query of the week" section, attendees can ask
> about/discuss a neuroscience topic that they are curious about.
>
>
> We hope to see you there! :D
>
> --
> Thanks
> Regards
>
> Aniket Pradhan
> http://home.iiitd.edu.in/~aniket17133/
> Aliases: MeWjOr/major
>
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments



-- 
Thanks
Regards

Aniket Pradhan
http://home.iiitd.edu.in/~aniket17133/
Aliases: MeWjOr/major

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updated review trackers pages

[Ankur Sinha]

On Tue, Apr 07, 2020 07:21:14 +, Mattia Verga via devel wrote:
> Hi all,

Hi Mattia,

Thanks very much for this!

>
> 
> BTW, since we have a 'trivial' ticket list for new reviewers, it would 
> be nice to have this populated: just add the 'trivial' tag in the ticket 
> whiteboard field on bugzilla.

The list says that there aren't any trivial tickets, but easyfix does
show one (only one):
https://fedoraproject.org/PackageReviewStatus/trivial.html
vs
https://fedoraproject.org/easyfix/

Could you check this please?

+1 to marking more package reviews as trivial. It'll really help the
newcomers coming to us in the Join SIG to get started with packaging :)

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

Fedora-IoT-32-20200407.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

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

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

Passed openQA tests: 7/8 (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: Rawhide update from side tag pending for 2 days

[Rex Dieter]

Richard W.M. Jones wrote:

> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> 
> This one is a Rawhide update from a side tag, submitted on Sunday
> morning which has been in pending for 2 days.  (As it's Rawhide it's
> supposed to spend 0 days in testing.)  Is there any problem with it,
> or do we just have to wait longer?  It is blocking builds of other
> packages.

I saw the same thing, and submitted a infra ticket about it,
https://pagure.io/fedora-infrastructure/issue/8819

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

Re: Rawhide update from side tag pending for 2 days

[Stephen John Smoogen]

For each of these stuck builds could you open up tickets in
https://pagure.io/releng/new_issue so we can track them down and fix them.
Currently there are 1.5 sysadmins and 1.5 release engineer and we are not
going to be able to track what and where we are doing things from mailing
list posts.

On Tue, 7 Apr 2020 at 08:41, Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

> There is a problem right now with the part of koji that tags builds and
> adds them to the various repos koji uses for new builds. So you can
> build new packages, but can not rely on further builds seeing your
> just-built packages.
>
> --
> 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
>


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

Re: @core install picking up desktop packages

[Kalev Lember]

On 4/4/20 09:21, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote:

I added the libsecret -> gnome-keyring recommends due to
https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best
to revert this change


Yes, please.


OK, I went ahead and did that: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-bec4522056


Thanks everybody!

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

Re: Qt 5.14.2 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> On Mon, Apr 6, 2020 at 11:13 PM Rex Dieter  wrote:
> 
>> Rex Dieter wrote:
>>
>> > FYI, Started work on importing Qt 5.14.2 into rawhide today, with
>> work-in-
>> > progress being done in side tag f33-build-side-21031
>> >
>> > I figure it'll take at least a few days to get the core bits and all
>> > dependencies rebuilt.  Will provide status updates as warranted.
>>
>> Fist batch of builds completed, bodhi update:
>> https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c
> 
> 
> Ahh, wish I had known, I would have built python-PySide2 into the side
> tag. I suppose I still can but it wouldn't be in the update.

You still can, the side tag still exists... or just wait until it gets 
pushed.

If python-PySide2 uses Qt private api's so that it requires rebuilding for 
every Qt5 point release, make sure that it includes:
BuildRequires: qt5-qtbase-private-devel
that's the set of packages I always include in these sort of Qt mass 
updates.

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

Re: Rawhide update from side tag pending for 2 days

[Nicolas Mailhot via devel]

There is a problem right now with the part of koji that tags builds and
adds them to the various repos koji uses for new builds. So you can
build new packages, but can not rely on further builds seeing your
just-built packages.

-- 
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: Rawhide update from side tag pending for 2 days

[Fabio Valentini]

On Tue, Apr 7, 2020 at 8:56 AM Richard W.M. Jones  wrote:
>
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
>
> This one is a Rawhide update from a side tag, submitted on Sunday
> morning which has been in pending for 2 days.  (As it's Rawhide it's
> supposed to spend 0 days in testing.)  Is there any problem with it,
> or do we just have to wait longer?  It is blocking builds of other
> packages.

Yeah, this update looks stuck ... the koji builds aren't even tagged
into the right tags yet, neither are they signed (from what I can
see).

I seem to have the same - or at least a similar - issue with three
updates that are also stuck in pending for two days already (and the
builds are not even signed yet, either):

- https://bodhi.fedoraproject.org/updates/FEDORA-2020-460f0f4d48
- https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ea279079e
- https://bodhi.fedoraproject.org/updates/FEDORA-2020-755f442b4c

Those three were also made from side tags, but for stable releases, so
I'm not sure whether it's the same issue or not.

Fabio

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Neal Gompa]

On Tue, Apr 7, 2020 at 7:33 AM Petr Pisar  wrote:
>
> On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
> > On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher  
> > wrote:
> > > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa  wrote:
> > >> I've personally been burned enough times by not having versioned
> > >> DistTags for personal rebuilds that I would strongly suggest you
> > >> reconsider having unversioned ones.
> > >
> > > Would you mind explaining some of the situations in which you were burned?
> > > I’m not ruling this out, but I’d like a clear justification if we were to
> > > change something.
> > >
> > So, prior to me building my packages in OBS and getting auto-bumping
> > Releases, I used to bump into issues all the time with building openSUSE
> > packages in an environment like Koji's, where the NVR is the key for
> > a unique package. openSUSE does *not* define a DistTag or the %dist
> > variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
> > packages with no source changes from one release of openSUSE to the next, or
> > rebuilding for new Tumbleweed snapshots, you're going to get collisions all
> > the time, and builds will just fail because the NVR already exists.
> >
> I think ELN won't have this problem (at large scale) because it will inherit
> sources from Fedora where any new Fedora build has a bumped release for the
> reason you described. It will resemble more a shadow Koji for the secondary
> architectures.
>
> But you are right that funny times can come when an ELN build screws things 
> and
> ELN people will have to not only untag it but also delete it from the NVR 
> index so
> that it can be rebuilt again with the same NVR. Fedora people weren't happy if
> they had to add a dummy release bumps just only because of ELN.
>

If the goal is to minimize impact on everyone else by ELN work, having
this versioned makes sense because it prevents very annoying
disruptions later on.

> > This is utter chaos and you *really* don't want that problem on your
> > hands. Having the freedom to do a rebuild cycle for ELN whenever you
> > want to rebootstrap to a new major without changing sources is a
> > hugely valuable thing to be able to do.
> >
> I think they will just throw it away and start from the scratch. At the end
> they would like to rebuild all the packages with the new configuration.
>

I'm pretty sure that nobody is going to let them delete everything
from Koji to redo it. Unless they were spinning this up in a shadow
Koji rather than the main one, which I don't think is the intent here.



-- 
真実はいつも一つ！/ 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: Updated review trackers pages

[Richard Shaw]

On Tue, Apr 7, 2020 at 2:22 AM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Hi all,
>
> we have updated the script which provides the cached review trackers
> pages at https://fedoraproject.org/PackageReviewStatus/ (thanks to
> cverna for the assistance).
>

Can we assume the one from 2006 is stale? :)

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 3:46 AM Vít Ondruch  wrote:
...
> > * Added a section explaining how we will deal with side-tags
>
>
> Thank you for addressing this.
>
> However, could you please elaborate what will be the actual trigger to
> do rebuild of some package in ELN? It can't be `git push` if you take
> side-tags into account. So will it be tagging into 'rawhide' (f33 ATM)?
> Will it be mixture? How are you going to determine what is the
> appropriate commit hash? You possibly don't know yet ...

I need to investigate how much of it will be net-new work, but we
intend to rely on fedora-messaging notifications to trigger the
rebuilds. Tagging into F33 is probably our best bet; we do actually
have the ability to query Koji for which commit hash was used to run
the build, so we can rely on that. The exact mechanism here is TBD,
but I wanted to make sure the intent of the design was covered in the
Change Proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14.2 coming to rawhide

[Richard Shaw]

On Mon, Apr 6, 2020 at 11:13 PM Rex Dieter  wrote:

> Rex Dieter wrote:
>
> > FYI, Started work on importing Qt 5.14.2 into rawhide today, with
> work-in-
> > progress being done in side tag f33-build-side-21031
> >
> > I figure it'll take at least a few days to get the core bits and all
> > dependencies rebuilt.  Will provide status updates as warranted.
>
> Fist batch of builds completed, bodhi update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c


Ahh, wish I had known, I would have built python-PySide2 into the side tag.
I suppose I still can but it wouldn't be in the update.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel

[Nicolas Mailhot via devel]

Le mardi 07 avril 2020 à 06:31 -0400, Paul Dufresne via devel a écrit :
> Le 20-04-06 à 21 h 01, Paul Dufresne a écrit :
> > BTW, thanks I was searching for an example of package using a git
> version rather than a released archive!
> Just for the record, *I think* the current package is a bad example
> of a package using a forge like git.
> 
> Current 
> https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/f32/f/xorg-x11-drv-intel.spec
> does not seems to use the %forgemeta or %forgesetup macros as
> suggested in 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
> (that I just read)

While documented and official %forge macro use is not mandatory in
Fedora (of course, if you do things some other way, and the result
breaks, you ’ve no excuse for the breakage)

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: Updating MUMPS/Sundials/PETSc

[Antonio Trande]

On 06/04/20 16:19, David Schwörer wrote:
> On 4/5/20 6:06 PM, Antonio Trande wrote:
>> On 04/04/20 19:23, David S wrote:
>>> On 4/4/20 4:38 PM, Antonio Trande wrote:
 Hi all.

 `MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming
 on Rawhide; these updates will need rebuilds of dependent packages:

>>> [:snip:]
>>>
>>>
>>> Thanks a lot for updating PETSc, I know PETSc is quite challenging to
>>> package.
>>>
>>> I tried to build BOUT++ against PETSc, using pkg-config.
>>> the pkg-config files are installed to petsc/ subdirectory, but it seems
>>> the pc files are not adjusted for this.
>>>
>>> Further, I have been using petsc --with superludist without issues, can
>>> you tell why this was disabled, so I can test whether this was fixed in
>>> the mean time?
>>
>> `superludist` support is reactivated; please, test petsc-3.13.0 again:
>> https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1328023/
>>
> 
> In the PETSc.pc files, the $MPI_INCLUDE are not expanded, which also
> doesn't happen at evaluation time:
> pkg-config PETSc --cflags
> -I$MPI_INCLUDE/petsc
> 
> which isn't further evaluated. I guess replacing the ' with " in the
> spec should ensure it gets evaluated.
> 
> PETSc is injecting -L/usr/lib which will cause linking issues if there
> is e.g. a libhdf5.so in /usr/lib because the MPI lib is needed.
> 
> Besides these two issues, everything seems to be fine.

Last build on Copr should fix these issues. Please, test it again:
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1329534/

> 
> Thanks,
> David
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



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: F32: System hangs when using mock

[Ankur Sinha]

On Tue, Apr 07, 2020 09:53:18 +0100, Ankur Sinha wrote:
> 
> On Mon, Apr 06, 2020 09:37:01 +0200, Pavel Raiskup wrote:
> > On Sunday, April 5, 2020 12:44:38 PM CEST Ankur Sinha wrote:
> > > On Sat, Apr 04, 2020 21:37:05 -, Artem Tim wrote:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1754807
> > > 
> > > That does look like it. I'll go through the comments and see if I can
> > > help with more info.
> > 
> > Note also this bug [1] where's kernel traceback in bfq kernel code.
> > I have never reproduced the problem on my box (ssd nvme disk), so I can't
> > tell.. but those are possible workarounds for those who use bfq scheduler:
> > 
> > - per Zbyszek, switching back to deadline
> > - per Vitaly, systemd.unified_cgroup_hierarchy=0 kernel parameter
> 
> Thanks Pavel,
> 
> Would someone have instructions on how to make these changes? I can test
> both of these out.

For the scheduler, the steps here work:
https://wiki.archlinux.org/index.php/improving_performance#Input/output_schedulers

Testing it out now.


-- 
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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Petr Pisar]

On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher  wrote:
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa  wrote:
> >> I've personally been burned enough times by not having versioned
> >> DistTags for personal rebuilds that I would strongly suggest you
> >> reconsider having unversioned ones.
> >
> > Would you mind explaining some of the situations in which you were burned?
> > I’m not ruling this out, but I’d like a clear justification if we were to
> > change something.
> >
> So, prior to me building my packages in OBS and getting auto-bumping
> Releases, I used to bump into issues all the time with building openSUSE
> packages in an environment like Koji's, where the NVR is the key for
> a unique package. openSUSE does *not* define a DistTag or the %dist
> variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
> packages with no source changes from one release of openSUSE to the next, or
> rebuilding for new Tumbleweed snapshots, you're going to get collisions all
> the time, and builds will just fail because the NVR already exists.
> 
I think ELN won't have this problem (at large scale) because it will inherit
sources from Fedora where any new Fedora build has a bumped release for the
reason you described. It will resemble more a shadow Koji for the secondary
architectures.

But you are right that funny times can come when an ELN build screws things and
ELN people will have to not only untag it but also delete it from the NVR index 
so
that it can be rebuilt again with the same NVR. Fedora people weren't happy if
they had to add a dummy release bumps just only because of ELN.

> This is utter chaos and you *really* don't want that problem on your
> hands. Having the freedom to do a rebuild cycle for ELN whenever you
> want to rebootstrap to a new major without changing sources is a
> hugely valuable thing to be able to do.
>
I think they will just throw it away and start from the scratch. At the end
they would like to rebuild all the packages with the new configuration.

-- Petr



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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Miro Hrončok]

On 07. 04. 20 12:18, Aleksandra Fedorova wrote:

What I'm confused about is the hangup with versioning the ELN tree.
Why is this a problem?

I explained it in one of the previous threads:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/

But I guess we need to extend this conversion by answering:
1) versioning of what exactly?
2) versioning by which number?

 From the problem you describe, it looks like the solution for it is to
have %{?dist} resolved to a versioned data. But the versioning here
should be independent from both RHEL and Fedora versioning. It should
be based on changes in eln buildroot configuration itself: As soon as
we want to have a non-disruptive rebuild in eln buildroot, we
increment the number in %{?dist} for eln, and rebuild the same srpm.
And this action is not linked to Fedora or RHEL releases. This number
may as well be the date, or a simple counter.

If we do versioning in this way, then it resolves both concerns I had
in my reply there:
1) we don't try to link to particular RHEL release;
2) we don't version the koji tag and target, and we don't need to
update Koji configuration every time Fedora creates a branch. Thus the
pipelines we create for building eln packages can still be
unversioned.



What you say here is very inconsistent with %{eln} and %{rhel} value. In 
particular "the versioning here should be independent from RHEL" and "we don't 
try to link to particular RHEL release" is very weird considering that %{eln} 
and %{rhel} will evaluate to "next RHEL version".


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

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
> The majority here is telling you to hold off execution of that
> "decision" and revisit it, but you're ignoring those voices entirely and
> offering useless "apologies" instead. You cannot pretend to be part of a
> community if you just ignore its other members and do your own thing.
[…]
> You cannot wish for meaningful engagement in the future if you don't fix
> your past mistakes and reverse bad decisions.

+1

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

Fedora-Cloud-31-20200407.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

bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel

[Paul Dufresne via devel]

|Le 20-04-06 à 21 h 01, Paul Dufresne a écrit :> BTW, thanks I was 
searching for an example of package using a git||version rather than a 
released archive!||

|

|Just for the record, *I think* the current package is a bad example of 
a package using a forge like git.|||


||

|Current 
https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/f32/f/xorg-x11-drv-intel.spec 
does not seems to use the %forgemeta or %forgesetup macros as suggested 
in https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ 
(that I just read)

|

||

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

Re: Modularity Survey

[Kevin Kofler]

Adam Williamson wrote:
> Well. Uh. Clearly it's being provided to *Google*.

Indeed. Once again, Fedora is depending on third-party, proprietary, 
privacy-invading SaaS.

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

Re: Fedora 32 FTBFS packages to be orphaned in 1 week

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
> I'll take it and try to fix it. It's required for the proprietary
> Acrobat Reader for Linux. And yes, I know the last version is from 2013
> and full of security holes, but it's the only software that can read
> PDFs with forms on Linux. Co-maintainers welcome.

FYI, both Okular and Evince have some support for PDF forms. It might not 
work for all forms though – in particular, XFA forms are not supported by 
Okular.

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Aleksandra Fedorova]

Hi, Neal,

On Tue, Apr 7, 2020 at 12:49 AM Neal Gompa  wrote:
>
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher  wrote:
> >
> >
> >
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa  wrote:
> >>
> >> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
> >> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
> >> * Likewise, I think the Koji tags should be versioned too.
> >>
> >> I've personally been burned enough times by not having versioned
> >> DistTags for personal rebuilds that I would strongly suggest you
> >> reconsider having unversioned ones.
> >
> > Would you mind explaining some of the situations in which you were burned? 
> > I’m not ruling this out, but I’d like a clear justification if we were to 
> > change something.
> >
>
> So, prior to me building my packages in OBS and getting auto-bumping
> Releases, I used to bump into issues all the time with building
> openSUSE packages in an environment like Koji's, where the NVR is the
> key for a unique package. openSUSE does *not* define a DistTag or the
> %dist variable, so %{?dist} evaluates to nothing. If you're doing
> rebuilds of your packages with no source changes from one release of
> openSUSE to the next, or rebuilding for new Tumbleweed snapshots,
> you're going to get collisions all the time, and builds will just fail
> because the NVR already exists.
>
> This is utter chaos and you *really* don't want that problem on your
> hands. Having the freedom to do a rebuild cycle for ELN whenever you
> want to rebootstrap to a new major without changing sources is a
> hugely valuable thing to be able to do.
>
> And honestly, I expect the ELN tree to exist for a long time once it's
> in Fedora. So some of this is also planning for a future where we
> always have Fedora ELN along with Rawhide and regular Fedora stable
> releases.
>
> What I'm confused about is the hangup with versioning the ELN tree.
> Why is this a problem?

I explained it in one of the previous threads:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/

But I guess we need to extend this conversion by answering:
1) versioning of what exactly?
2) versioning by which number?

From the problem you describe, it looks like the solution for it is to
have %{?dist} resolved to a versioned data. But the versioning here
should be independent from both RHEL and Fedora versioning. It should
be based on changes in eln buildroot configuration itself: As soon as
we want to have a non-disruptive rebuild in eln buildroot, we
increment the number in %{?dist} for eln, and rebuild the same srpm.
And this action is not linked to Fedora or RHEL releases. This number
may as well be the date, or a simple counter.

If we do versioning in this way, then it resolves both concerns I had
in my reply there:
1) we don't try to link to particular RHEL release;
2) we don't version the koji tag and target, and we don't need to
update Koji configuration every time Fedora creates a branch. Thus the
pipelines we create for building eln packages can still be
unversioned.

> >
> >>
> >> Finally, there is no adequate explanation for why ELN content can't go
> >> out to the mirrors like Rawhide content does. I'd vastly prefer that
> >> simply to have similar levels of availability as consumers of ELN
> >> content. I would prefer seeing it go to the mirror network like
> >> everything else.
> >
> >
> >
> > It’s not so much that it *cannot* as that we are trying not to overload the 
> > mirror network with content not useful to non-developers.
> >
>
> Unless you plan to get Red Hat to do CDN delivery of ELN, I think
> you're going to want it on the mirror network anyway. Ultimately,
> contributors like myself need to be able to *use* the content, and not
> having it delivered via the mirror network means that it's going to be
> painful for a large cross-section of contributors and developers.
>

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Q: is a missing info URL for a package a problem?

[Petr Pisar]

On Tue, Apr 07, 2020 at 11:38:55AM +0200, Marius Schwarz wrote:
> Description of problem:
> 
> the Info URL of the package "clamsmtp" seems to be offline ...
> 
> 
> $  dnf info clamsmtp | grep -i url
> URL  : http://memberwebs.com/stef/software/clamsmtp/
> 
> $ host  memberwebs.com
> Host memberwebs.com not found: 2(SERVFAIL)
> 
> it does not look like a temporary error. Is there any guideline for this?
> 
In my opinion, if there is no better URL, it's better to keep the old
unreachable one.

-- Petr


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

[Iñaki Ucar]

On Tue, 7 Apr 2020 at 03:08, Randy Barlow  wrote:
>
> On 4/6/20 6:37 AM, Leigh Griffin wrote:
> > I'm sorry if you took my mail up as implying a lack of value from how
> > the team historically worked. As a team we are being tasked more and
> > more with adding what I call real value which is at a new app / service
> > level that has scale, quality and requirements that historically a
> > single developer could not call on. We had some superhuman developers in
> > the past in the team that were able to do every single thing an
> > application needed and produced some wonderful applications that in
> > truth would have taken 10 or more developers to replicate. That team has
> > moved on now and the old style of working was not going to meet the
> > needs and wants of our stakeholders (in this case Fedora Council) and a
> > repurposing of the team to make visible impacts was undertaken. So while
> > we cannot have multiple commits across a plethora of services, we are
> > not focusing our efforts on singular services at a time to generate a
> > value proposition for the community. Sorry once again if you took my
> > comment up as being a sleight, it was most definitely not intended and
> > you have my sincere apologies.
>
> There's more wrong with the above than I already pointed out. In this
> paragraph, you:
>
> * Double down the message of implying the the work done in the past
>didn't add real value,
> * Insult your current team, implying that they haven't reached the
>apparently "superhuman" standards of the past,
> * Triple down on disparaging the efforts of past developers by implying
>that only now is the work of the CPE team having "visible impacts".

C'mon, he didn't imply anything or insult anyone, you are just
twisting his message for sport. He apologised several times already
about this. Move on.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: v4l2loopback kernel module in Fedora?

[Iñaki Ucar]

On Tue, 7 Apr 2020 at 05:58, Christopher  wrote:
>
> If I get the motivation, I'll file a bug against the RPMFusion package.

Here's the bug tracker: https://bugzilla.rpmfusion.org/

> As for the original issue regarding packaging: there is a ticket being
> tracked to get it upstream into the kernel:
> https://github.com/umlaeute/v4l2loopback/issues/268

Yeap, I saw this, and that's why I said that upstream doesn't seem to
be willing to push this forward, because the maintainer's message is
basically "I'm totally open, but I'm not going to move a finger
besides merging PRs".

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

Re: CPE Weekly: 2020-04-04

[Mark Wielaard]

Hi,

On Mon, 2020-04-06 at 09:49 -0400, Ben Rosser wrote:
> > Not everyone is inclined to loudly argue their positions on the
> > mailing
> > list. There have only been 12 unique participants to this thread and 57
> > to the other thread.
> > 
> > That isn't indicative of the entire Fedora packager ecosystem. A lot of
> > people are staying silent.
> > [...]
> 
> I'm a packager who has been staying silent, but I generally strongly
> agree with the points that Adam, Miro, Neal, and others have been
> making with a few caveats:

This is also why I am staying silent. I believe the points I would make
have already been made, and probably much better than I could have
formulated them. Including what Ben just said.

> * I don't _really_ mind if we wind up using Gitlab over Pagure, but if
> we do, I do feel pretty strongly that we should use Gitlab CE and
> self-host it-- I don't think it would be right for Fedora to use an
> externally hosted solution and I don't think we should use the
> enterprise edition.
> 
> * I don't like how this process has been conducted, and I think that
> official responses from CPE thus far haven't really made things
> better-- if anything, the "we apologize, but this is the decision
> we've made" attitude is making things worse.
> 
> * I fear that, once again, we haven't adequately understood the
> consequences of replacing pagure and some of the features that were
> recently-- finally!-- added to it in order to replace missing pkgdb2
> functionality will again be lost for a long period of time... and
> nothing I've read in any of these threads so far has helped reassure
> me that's not the case.

It seems to me that nobody is happy with the process that was followed.
Reading back it is clear that people feel that what they perceive as
the Fedora goals and mission were not taken into account. Or at least
not formulated correctly, or strongly enough, during this process. And
that the process wasn't transparent, because various steps were not
visible enough. So a large part of the community was surprised by the
decision and believe that their input wasn't heard or simply ignored.
Including the input of some of who will have to do part of the
(integration) work.

I am sure that wasn't what was intended. And that there were just a few
communication accidents that caused things to break down. But
recognizing that some mistakes were made and trying to correct them so
that a real community can be build up around these kind of decisions is
important.

Cheers,

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

Q: is a missing info URL for a package a problem?

[Marius Schwarz]

Description of problem:

the Info URL of the package "clamsmtp" seems to be offline ...


$  dnf info clamsmtp | grep -i url
URL  : http://memberwebs.com/stef/software/clamsmtp/

$ host  memberwebs.com
Host memberwebs.com not found: 2(SERVFAIL)

it does not look like a temporary error. Is there any guideline for this?

Best regards,
Marius



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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Miro Hrončok]

On 07. 04. 20 10:09, Tom Hughes via devel wrote:

That will mean that most %fedora conditions will need to be
extended with a %rhel condition and that in many cases new
features may silently not be enabled in ELN builds until that
is manually discovered and the condition is amended which seems
to be the exact opposite of what is required if the goal is to
see how "Fedora Future" builds in an EL environment.

To take just one example hundreds of nodejs packages would build
as if they are on Fedora 18 or earlier because they contain this:

%if 0%{?fedora} >= 19
ExclusiveArch:  %{nodejs_arches} noarch
%else
ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
%endif

Now that is no longer required, and happens to be mostly harmless
because it just means they will hard code the arch list instead of
using the macro, but it's the kind of thing where ELN will wind
up building as if it's an ancient version of Fedora rather than as
if it is rawhide.


The idea is that if such package indeed is built in ELN, such conditionals 
should be fixed. If we define %fedora in ELN, the problems will only arise in 
RHEL and the conditionals will likely remain unfixed in Fedora.


This particular example might remain unfixed because it "works" as is.

Anyway, when introducing conditionals like this initially, I highly recommend to 
do this instead:


  %if %{defined nodejs_arches}
  ExclusiveArch:  %{nodejs_arches} noarch
  %else
  ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
  %endif

To avoid this kind of bad conditional.

--
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: F32: System hangs when using mock

[Ankur Sinha]

On Mon, Apr 06, 2020 09:37:01 +0200, Pavel Raiskup wrote:
> On Sunday, April 5, 2020 12:44:38 PM CEST Ankur Sinha wrote:
> > On Sat, Apr 04, 2020 21:37:05 -, Artem Tim wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1754807
> > 
> > That does look like it. I'll go through the comments and see if I can
> > help with more info.
> 
> Note also this bug [1] where's kernel traceback in bfq kernel code.
> I have never reproduced the problem on my box (ssd nvme disk), so I can't
> tell.. but those are possible workarounds for those who use bfq scheduler:
> 
> - per Zbyszek, switching back to deadline
> - per Vitaly, systemd.unified_cgroup_hierarchy=0 kernel parameter

Thanks Pavel,

Would someone have instructions on how to make these changes? I can test
both of these out.

I also have kernel hangs while trying rooted Podman commands, so perhaps
that's also the same issue. The system had hung and I hadn't been able
to get any more information there either.


> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1767097

-- 
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: Orphaning package procedure. (icewm, spring, springlobby)

[Artem Tim]

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

Fedora-Cloud-30-20200407.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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Tom Hughes via devel]

On 06/04/2020 22:53, Stephen Gallagher wrote:


Changes in this version of the proposal[2]:

* Improve our explanation of why we are doing ELN in the first place


I agree that the proposal is now a lot clearer and I certainly see
how it furthers the first goral of seeing how Fedora trunk comes
together asn an EL build, modulo one concern below.

I don't understand how it helps evaluate something like a new
higher CPU baseline - nobody disputes that packages can be built
to a new baseline which is what this would prove. The argument
is about the effect on consumers of such a baseline and about
what proportion of users/machines would be cut off from further
upgrades and this proposal does nothing to help with that.


* Better describe what happens if packages don't build on ELN
* Explain our plan for when to use conditionals (this was getting a
larger share of the conversation than it warranted because we didn't
do a good job of explaining that they should be the exception and not
the rule)


As far as conditionals are concerned I think not defining %fedora
is a key mistake that will both lead to extra conditionals being
needed and also lead to ongoing undetected failures to build
packages in ELN with the latest features of the corresponding
Fedora packages.

Essentially packages will build as if they are on the oldest
possible Fedora rather than the newest possible Fedora because
spec files with a condition on %fedora will typically treat it
as zero when it is not defined.

That will mean that most %fedora conditions will need to be
extended with a %rhel condition and that in many cases new
features may silently not be enabled in ELN builds until that
is manually discovered and the condition is amended which seems
to be the exact opposite of what is required if the goal is to
see how "Fedora Future" builds in an EL environment.

To take just one example hundreds of nodejs packages would build
as if they are on Fedora 18 or earlier because they contain this:

%if 0%{?fedora} >= 19
ExclusiveArch:  %{nodejs_arches} noarch
%else
ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
%endif

Now that is no longer required, and happens to be mostly harmless
because it just means they will hard code the arch list instead of
using the macro, but it's the kind of thing where ELN will wind
up building as if it's an ancient version of Fedora rather than as
if it is rawhide.


* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.


It might be better to give some idea of what sort of time limit is
envisioned - as it stands the proposal would allow PRs to demand a
response within a day, or an hour or any other ludicrously short
time period. Presumably if it's about looking for inactive maintainers
then something akin to the non-responsive maintainer timelines would
be appropriate?

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

Re: Orphaning package procedure. (icewm, spring, springlobby)

[Gilboa Davara]

> Hello. Gilboa, i would like to continue maintaining IceWM. And i interesting 
> in 'springlobby' package. Please add me as co-maintainer. FAS: atim.

Hello,

Done. Please verify.

- Gilboa
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaning package procedure. (icewm, spring, springlobby)

[Gilboa Davara]

On Mon, Apr 6, 2020 at 9:49 PM Kevin Fenzi  wrote:
>
> On Mon, Apr 06, 2020 at 04:59:14PM +0300, Gilboa Davara wrote:
> > Hello,
> >
> > Due to the extreme time constraints that I'm forced to orphan most of my
> > remaining packages.
> > Namely icewm (which has an active co-maintainer), spring and springlobby.
> > Following the procedure in wiki [1], I should use Pagure to orphan both
> > packages.
> > However, the list of projects in the Pagure is empty, and I can only view
>
> What exact URL are you going to?
>
> it should be:
>
> https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings
>
> where PACKAGE_NAME is one of the packages...
>

That worked. Thanks!

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Vít Ondruch]

Dne 06. 04. 20 v 23:53 Stephen Gallagher napsal(a):
> I've just published a fourth version[1] of the ELN proposal. With a
> lot of input from Miro Hrončok, I think I've finally been able to
> clarify some of the points that we were getting hung up on.
>
> Changes in this version of the proposal[2]:
>

Thank you. I don't have any real concerns ATM. Just a few remarks bellow.


> * Clarify the relationship with Rawhide


To my taste, there are quite a lot of remarks such as "If the package
will never build in ELN, then the Rawhide version of it will simply be
present." I think I don't see how it will turn out in practice.

So to say, this is not showstopper and I am fine with that.


> * Better describe what happens if packages don't build on ELN


Thank you for this paragraph:


~~~

If it would require conditionals to build in ELN and you do not wish to
put them there, but you want to see how changes appear in RHEL, there
will eventually be a way to maintain a fork of your package that will go
into RHEL, but the details on this are still being worked out.

~~~


I think you will soon appreciate it.


> * Added a section explaining how we will deal with side-tags


Thank you for addressing this.

However, could you please elaborate what will be the actual trigger to
do rebuild of some package in ELN? It can't be `git push` if you take
side-tags into account. So will it be tagging into 'rawhide' (f33 ATM)?
Will it be mixture? How are you going to determine what is the
appropriate commit hash? You possibly don't know yet ...



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

Updated review trackers pages

[Mattia Verga via devel]

Hi all,

we have updated the script which provides the cached review trackers 
pages at https://fedoraproject.org/PackageReviewStatus/ (thanks to 
cverna for the assistance).

Nothing too impressive, the main changes in frontend are:

- A search field in list pages to filter tickets. Since these pages are 
static HTML, the search is performed client side, so you will need to 
have javascript enabled on your browser.
- Some new colors highlighting to strike problematic tickets (for 
example, if a new package review ticket depends on some other ticket 
that was rejected)
- A list of "top blockers" tickets
- A more permissive hideout filter.

Let us know if you have any more improvement request.

BTW, since we have a 'trivial' ticket list for new reviewers, it would 
be nice to have this populated: just add the 'trivial' tag in the ticket 
whiteboard field on bugzilla.
Other useful whiteboard tags recognized by the script are (already used 
by the old script):
- 'buildfails': A flag for tickets which fail build.
- 'notready': A flag for tickets not yet ready for being reviewed.
- 'stalledsubmitter' and 'awaitingsubmitter': A flag for tickets which 
are stalled.

Cheers,
Mattia

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