date:20200305

On Thu, Mar 5, 2020 at 8:51 PM Luya Tshimbalanga  wrote:
>
> > We've managed to drop a lot of redundant code across the whole DNF stack
> > in the past years, but we have reached a point when it's nearly
> > impossible to consolidate the code any further without breaking the
> > API/ABI. Especially with PackageKit being dead[1], we can't move with
> > the old "libhif" API in libdnf, because making any bigger changes to
> > PackageKit is clearly out of scope.
> >
> > [1]
> > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-w...
> >
>
> *Ahem* See the comments on the above links an the github is still active 
> https://github.com/hughsie/PackageKit
>
> The main issue related to PackageKit linked libdnf was the lack of 
> synchronization of the database. PackageKit was made to be cross-platform for 
> distributions with minimum reliance on specific distribution command, Losing 
> PackageKit would lead to yet another step back with multiple commands 
> difficult to remember thus another fragmentation.

The database has been synchronized since Fedora 24. However, the
caches are not, and that *does* need to be fixed. The library
interface for DNF already has APIs for this, PackageKit doesn't use
them.



-- 
真実はいつも一つ！/ 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: Announcing start of DNF 5 development

2020-03-05 Thread Luya Tshimbalanga

> We've managed to drop a lot of redundant code across the whole DNF stack 
> in the past years, but we have reached a point when it's nearly 
> impossible to consolidate the code any further without breaking the 
> API/ABI. Especially with PackageKit being dead[1], we can't move with 
> the old "libhif" API in libdnf, because making any bigger changes to 
> PackageKit is clearly out of scope.
> 
> [1] 
> https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-w...
> 

*Ahem* See the comments on the above links an the github is still active 
https://github.com/hughsie/PackageKit

The main issue related to PackageKit linked libdnf was the lack of 
synchronization of the database. PackageKit was made to be cross-platform for 
distributions with minimum reliance on specific distribution command, Losing 
PackageKit would lead to yet another step back with multiple commands difficult 
to remember thus another fragmentation. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: 4 packages still requiring Python 3.7 in Fedora 32: Retire mailman3 and python-subunit2sql

On Thu, Mar 5, 2020 at 6:34 PM Miro Hrončok  wrote:
>
> On 05. 02. 20 12:32, Miro Hrončok wrote:
> > In Fedora 32, we have updated Python to 3.8:
> >
> > https://fedoraproject.org/wiki/Changes/Python3.8
> >
> > There are last 13 packages that were still not successfully rebuilt with 
> > Python
> > 3.8 and they require Python 3.7 at run-time, causing broken dependencies. 
> > The
> > packages are not installable. I don't think the bugzillas are moving 
> > anywhere.
> >
> >
> > Technically, such noninstallable packages should be retired one week before 
> > the
> > beta freeze. I'm writing this e-mail to raise awareness about the problem. 
> > Some
> > of the packages are awaiting upstream fixes.
>
> The last four are:
>
> mailman3   https://bugzilla.redhat.com/show_bug.cgi?id=1715598
> mraa   https://bugzilla.redhat.com/show_bug.cgi?id=1721671
> python-subunit2sql https://bugzilla.redhat.com/show_bug.cgi?id=1746853
> upmhttps://bugzilla.redhat.com/show_bug.cgi?id=1736936
>
> mailman3   abompard
> mraa   pbrobinson
> python-subunit2sql chandankumar
> upmpbrobinson
>
> Since Peter replied that mraa and upm are on his todo list, I suggest we 
> retire
> mailman3 and python-subunit2sql for now, so we don't have it in the GA repo 
> with
> broken depndndencies (and we obsolete via fedora-obsoelte-packages to prevent
> upgrade to Fedora 32 problems). Later we can unretire any time during the 
> Fedora
> 32 life cycle.

There's a PR open to update mailman3 and fix things:
https://src.fedoraproject.org/rpms/mailman3/pull-request/2

I'm not sure why, but both Duck and myself are supposed to be
co-maintainers of this and we're not...


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

4 packages still requiring Python 3.7 in Fedora 32: Retire mailman3 and python-subunit2sql


On 05. 02. 20 12:32, Miro Hrončok wrote:

In Fedora 32, we have updated Python to 3.8:

https://fedoraproject.org/wiki/Changes/Python3.8

There are last 13 packages that were still not successfully rebuilt with Python 
3.8 and they require Python 3.7 at run-time, causing broken dependencies. The 
packages are not installable. I don't think the bugzillas are moving anywhere.



Technically, such noninstallable packages should be retired one week before the 
beta freeze. I'm writing this e-mail to raise awareness about the problem. Some 
of the packages are awaiting upstream fixes.


The last four are:

mailman3   https://bugzilla.redhat.com/show_bug.cgi?id=1715598
mraa   https://bugzilla.redhat.com/show_bug.cgi?id=1721671
python-subunit2sql https://bugzilla.redhat.com/show_bug.cgi?id=1746853
upmhttps://bugzilla.redhat.com/show_bug.cgi?id=1736936

mailman3   abompard
mraa   pbrobinson
python-subunit2sql chandankumar
upmpbrobinson

Since Peter replied that mraa and upm are on his todo list, I suggest we retire 
mailman3 and python-subunit2sql for now, so we don't have it in the GA repo with 
broken depndndencies (and we obsolete via fedora-obsoelte-packages to prevent 
upgrade to Fedora 32 problems). Later we can unretire any time during the Fedora 
32 life cycle.


--
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: 2 Kernel related quick-docs need review

2020-03-05 Thread Jeremy Cline

On Thu, 2020-03-05 at 18:33 +, Ankur Sinha wrote:
> Two more quick docs need specialist knowledge:
> 
> - Building a custom kernel:
>   https://pagure.io/fedora-docs/quick-docs/issue/210
> - Kernel troubleshooting:
>   https://pagure.io/fedora-docs/quick-docs/issue/209
> 
> Could someone with sufficient kernel building/troubleshooting
> knowledge
> please take a look at these?
> 
> 

I'm pretty sure I fixed those up at some point, but these documents
are going to need some changes in any case in the next few weeks so
I'll take these on.

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

No missing expected images.

Failed openQA tests: 26/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200304.n.0):

ID: 533797  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/533797
ID: 533804  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/533804
ID: 533853  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/533853
ID: 533860  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/533860
ID: 533886  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/533886
ID: 533898  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/533898

Old failures (same test failed in Fedora-32-20200304.n.0):

ID: 533817  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/533817
ID: 533819  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/533819
ID: 533850  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/533850
ID: 533867  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/533867
ID: 533874  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/533874
ID: 533883  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/533883
ID: 533897  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/533897
ID: 533900  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/533900
ID: 533902  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/533902
ID: 533903  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/533903
ID: 533912  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/533912
ID: 533913  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/533913
ID: 533920  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/533920
ID: 533925  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/533925
ID: 533928  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/533928
ID: 533941  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/533941
ID: 533953  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/533953
ID: 533960  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/533960
ID: 533961  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/533961
ID: 533966  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/533966
ID: 533967  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/533967

Soft failed openQA tests: 14/171 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-32-20200304.n.0):

ID: 533833  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/533833

Old soft failures (same test soft failed in Fedora-32-20200304.n.0):

ID: 533795  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/533795
ID: 533796  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/533796
ID: 533798  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/533798
ID: 533800  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/533800
ID: 533803  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/533803
ID: 533824  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/533824
ID: 533855  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/533855
ID: 533887  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/533887
ID: 533896  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/533896
ID: 533914  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/533914
ID: 533949  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fed

Re: Announcing start of DNF 5 development

2020-03-05 Thread Adam Williamson

On Thu, 2020-03-05 at 18:38 +, J. Randall Owens wrote:
> On 04/03/2020 18:03, Daniel Mach wrote:
> > Hello everyone,
> > I'm pleased to announce start of DNF 5 development. We are planning to
> > deliver a module stream or a COPR repo during Fedora 33 development for
> > early adopters and tool developers and we're hoping in getting a stable
> > version into Fedora 34.
> > 
> > 
> > More details follow.
> > 
> > 
> > We've managed to drop a lot of redundant code across the whole DNF stack
> > in the past years, but we have reached a point when it's nearly
> > impossible to consolidate the code any further without breaking the
> > API/ABI. Especially with PackageKit being dead[1], we can't move with
> > the old "libhif" API in libdnf, because making any bigger changes to
> > PackageKit is clearly out of scope.
> > 
> > [1]
> > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
> > 
> > 
> > 
> > That's why we decided to start working on a new version of the DNF
> > stack: DNF 5. And this is the plan:
> > 
> > 
> > Priorities
> > --
> > 1. Consistency, documentation and user experience is the top priority.
> > 2. Compatibility on the command line level.
> > 3. Compatibility on the API level.
> 
> 
> In favour of 1., but going against 2., I've wanted since the YUM days to
> see more consistency in the compound-word* options. E.g., --enablerepo
> but --skip-broken, and I have a hard time remembering which ones get the
> hyphen inbetween*, and which ones don't. Could we settle on one way or
> the other, right now quite the majority are without hyphen, and
> deprecate the other (but presumably enable both spellings for a good
> long while, perhaps with a warning if someone spells it the old way)?
> Probably not take away the old spellings as soon as DNF 5, but it might
> be a good time to add the more consistent spellings.

I mean, it shouldn't be too hard to standardize on having them all work
both ways, even.
-- 
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

Fedora-IoT-32-20200305.0 compose check report

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Soft failed openQA tests: 2/8 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 534129  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/534129
ID: 534130  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/534130

Passed openQA tests: 6/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
2 services(s) added since previous compose:   chronyd.service,   
systemd-fsck@dev-disk-by\x2duuid-8e916a09\x2d4038\x2d4d25\x2d95d8\x2daa4b13c7aa36.service
1 services(s) removed since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-2bd4fff9\x2db889\x2d4130\x2d9e22\x2d3968c7b2fd48.service
Previous test data: https://openqa.fedoraproject.org/tests/533027#downloads
Current test data: https://openqa.fedoraproject.org/tests/534129#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
3 services(s) added since previous compose:   chronyd.service,   
systemd-fsck@dev-disk-by\x2duuid-2A03\x2d2E88.service,   
systemd-fsck@dev-disk-by\x2duuid-64652b23\x2d26fe\x2d44c9\x2d8916\x2df7a6ca6979b1.service
2 services(s) removed since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-68cc2c90\x2dd933\x2d48c2\x2d83cc\x2d2fba7253f565.service,
   systemd-fsck@dev-disk-by\x2duuid-B629\x2dF21E.service
Previous test data: https://openqa.fedoraproject.org/tests/533028#downloads
Current test data: https://openqa.fedoraproject.org/tests/534130#downloads
-- 
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: Announcing start of DNF 5 development

2020-03-05 Thread Adam Williamson

On Thu, 2020-03-05 at 14:08 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > > (OK, it's a single library with other parts included, but the sd-bus
> > > part is the biggest by far, and also sd-bus uses sd-event and sd-128
> > > internally, so they'd be required anyway. The other parts are smaller,
> > > and matter more because of dependencies they pull in than because of
> > > the code size itself. But it is possible to compile libsystemd w/o
> > > some features, notably without encryption, to save size and deps.
> > > I don't think there's any significant barrier to using libsystemd
> > > on non-systemd systems, except for psychological issues.)
> > > 
> > 
> > Don't discount psychological issues. The original reason for DNF not
> > being named YUM was so that the project would be free to do better
> > without the YUM baggage. That had the added effect of making it easier
> > to propose for other distributions to adopt because YUM has a very
> > negative reputation outside of the RHEL space.
> 
> ;]]] Let's just hope that the underlying ipc library is something that
> is not visible to users ;)

pull-request: s/libsystemd/libvoldemort/g/
-- 
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

Fedora 32 compose report: 20200305.n.0 changes

2020-03-05 Thread Fedora Branched Report

OLD: Fedora-32-20200304.n.0
NEW: Fedora-32-20200305.n.0

= SUMMARY =
Added images:0
Dropped images:  8
Added packages:  0
Dropped packages:1
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:197.15 KiB
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-32-20200304.n.0.s390x.tar.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-32-20200304.n.0.iso
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-32-20200304.n.0.s390x.tar.xz
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-32-20200304.n.0.s390x.vmdk
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-32-20200304.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-32-20200304.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-32-20200304.n.0.s390x.raw.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-32-20200304.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: cerbere-2.5.0-4.fc32
Summary: Pantheon session watchdog
RPMs:cerbere
Size:197.15 KiB


= UPGRADED PACKAGES =

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

Re: Non-responsive maintainer: pocock

2020-03-05 Thread Julian Sikorski

W dniu 05.03.2020 o 21:01, Daniel Pocock pisze:
> 
> 
> On 03/03/2020 23:23, Dakota Williams wrote:
>> On 3/3/20 4:10 AM, Daniel Pocock wrote:
> 
>>>
>>> But based on what you say, I'm happy to give access to Dakota and I'd
>>> also like to know if anybody else can help with the reSIProcate
>>> packages.  There is a new release in the pipeline and if somebody wants
>>> to get involved, now is the time.  We already made all the upstream
>>> fixes required for it to work with the latest dependencies on Fedora.
>>
>> Great, my FAS id is "raineforest". Where would you like me to start?
> 
> I added you with commit access.
> 
> If you would like admin access can you please try to reach one of the
> other two admins (uwog and fale) to confirm?  If the rest of the
> community is OK with this way of granting access then I have no
> objections.  Welcome to asio.  It means something else in Australia.
> 
> Here you can see the version of asio we are testing with reSIProcate,
> the Windows devs use the 1.12.2 snapshot in the contrib tree:
> https://github.com/resiprocate/resiprocate/tree/master/contrib
> 
> and travis-ci builds use whatever version is fetched by this script:
> https://github.com/resiprocate/resiprocate/blob/master/.travis.yml
> 
> Debian and Ubuntu only have 1.12.2
> https://packages.qa.debian.org/a/asio.html
> 
> and that is what upstream travis-ci and my own upstream builds are based on.
> 
> Markus Wanner (the other Debian maintainer) is also in Switzerland, I'm
> either in Switzerland or Ireland.  If you are nearby I'm happy to meet you.
> 
> Debian politics are preventing an upload of 1.14.0 to Debian otherwise I
> would have done it already.  Due to the way the API changes from time to
> time it will be inconvenient for upstream devs like myself if there are
> different versions in Fedora and Debian.
> 
> In fact, I had started preparing the upstream release on 20 September 2018:
> https://github.com/resiprocate/resiprocate/commits/master?after=349d76b99fa7e99e4c4e7e5052e53115a64dcb45+174
> 
> and just minutes later somebody else in Debian decided to attack me.  In
> my entire career I've never received such ungrateful and spiteful
> communications after making a commit.
> 
> Regards,
> 
> Daniel
> 
Thank you for granting access to Dakota!

I would like to take this opportunity to remind about the PR that I have
prepared - let us not duplicate the work:
https://src.fedoraproject.org/rpms/asio/pull-request/1
I have rebuilt all asio's dependencies and only encountered issues with
abiword and OpenSceneGraph - both were complaining about error not being
a member of asio::placeholders. Same issues were found by gentoo, I have
linked the relevant bug reports in the PR. Is this something you would
be able to advise about? I am happy to share full build logs if needed.

Please also note that I have checked both fale and uwog's recent
activity with fedora-active-user and neither seem to have been active
lately.

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

Re: Non-responsive maintainer: pocock

2020-03-05 Thread Daniel Pocock

On 03/03/2020 23:23, Dakota Williams wrote:
> On 3/3/20 4:10 AM, Daniel Pocock wrote:

>>
>> But based on what you say, I'm happy to give access to Dakota and I'd
>> also like to know if anybody else can help with the reSIProcate
>> packages.  There is a new release in the pipeline and if somebody wants
>> to get involved, now is the time.  We already made all the upstream
>> fixes required for it to work with the latest dependencies on Fedora.
> 
> Great, my FAS id is "raineforest". Where would you like me to start?

I added you with commit access.

If you would like admin access can you please try to reach one of the
other two admins (uwog and fale) to confirm?  If the rest of the
community is OK with this way of granting access then I have no
objections.  Welcome to asio.  It means something else in Australia.

Here you can see the version of asio we are testing with reSIProcate,
the Windows devs use the 1.12.2 snapshot in the contrib tree:
https://github.com/resiprocate/resiprocate/tree/master/contrib

and travis-ci builds use whatever version is fetched by this script:
https://github.com/resiprocate/resiprocate/blob/master/.travis.yml

Debian and Ubuntu only have 1.12.2
https://packages.qa.debian.org/a/asio.html

and that is what upstream travis-ci and my own upstream builds are based on.

Markus Wanner (the other Debian maintainer) is also in Switzerland, I'm
either in Switzerland or Ireland.  If you are nearby I'm happy to meet you.

Debian politics are preventing an upload of 1.14.0 to Debian otherwise I
would have done it already.  Due to the way the API changes from time to
time it will be inconvenient for upstream devs like myself if there are
different versions in Fedora and Debian.

In fact, I had started preparing the upstream release on 20 September 2018:
https://github.com/resiprocate/resiprocate/commits/master?after=349d76b99fa7e99e4c4e7e5052e53115a64dcb45+174

and just minutes later somebody else in Debian decided to attack me.  In
my entire career I've never received such ungrateful and spiteful
communications after making a commit.

Regards,

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

Re: mock inside docker

2020-03-05 Thread Daniel Walsh

On 3/5/20 11:40, Miro Hrončok wrote:
> On 05. 03. 20 15:09, Christoph Junghans wrote:
>> Hi,
>>
>> if I am trying to run mock inside docker, I am getting the following
>> error:
>> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
>> ERROR: Command failed:
>>   # /bin/mount -n --bind
>> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>>
>> In the past I usually added --old-chroot to workaround that, but now
>> this yields:
>> ERROR: Command failed:
>>   # /bin/mount -n -t tmpfs -o rprivate tmpfs
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>>
>> This mock 2.0 inside the f31 ("fedora:latest") container from this
>> morning.
>>
>> Any idea how get mock working again?
>
> We run mock in docker with:
>
> $ docker run --cap-add=SYS_ADMIN
>
> And it seems to still work (on Travis CI at least).
>
Using Podman we might be able to get this to work in a user namespace,
without requiring root at all.


If you setup a user inside of the container to run with a user
namespace/mount namespace then create one and mount the proc and tmpfs

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

Re: mock inside docker

2020-03-05 Thread Daniel Walsh

Would like to know if this works with Podman.

On 3/5/20 11:22, Frantisek Zatloukal wrote:
> Hi,
>
> adding "--no-bootstrap-chroot" wouldn't help?
>
> On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans  > wrote:
>
> Hi,
>
> if I am trying to run mock inside docker, I am getting the
> following error:
> INFO: Results and/or logs in:
> /var/lib/mock/fedora-rawhide-x86_64/result
> ERROR: Command failed:
>  # /bin/mount -n --bind
> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>
> In the past I usually added --old-chroot to workaround that, but now
> this yields:
> ERROR: Command failed:
>  # /bin/mount -n -t tmpfs -o rprivate tmpfs
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>
> This mock 2.0 inside the f31 ("fedora:latest") container from this
> morning.
>
> Any idea how get mock working again?
>
> Christoph
>
> -- 
> Christoph Junghans
> Web: http://www.compphys.de
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> -- 
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Quality Engineer
> Red Hat
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Announcing start of DNF 5 development

2020-03-05 Thread Daniel Mach

Dne 05. 03. 20 v 19:38 J. Randall Owens napsal(a):

On 04/03/2020 18:03, Daniel Mach wrote:

Hello everyone,
I'm pleased to announce start of DNF 5 development. We are planning to
deliver a module stream or a COPR repo during Fedora 33 development for
early adopters and tool developers and we're hoping in getting a stable
version into Fedora 34.

More details follow.

We've managed to drop a lot of redundant code across the whole DNF stack
in the past years, but we have reached a point when it's nearly
impossible to consolidate the code any further without breaking the
API/ABI. Especially with PackageKit being dead[1], we can't move with
the old "libhif" API in libdnf, because making any bigger changes to
PackageKit is clearly out of scope.

[1]
https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/

That's why we decided to start working on a new version of the DNF
stack: DNF 5. And this is the plan:

Priorities
--
1. Consistency, documentation and user experience is the top priority.
2. Compatibility on the command line level.
3. Compatibility on the API level.

In favour of 1., but going against 2., I've wanted since the YUM days to
see more consistency in the compound-word* options. E.g., --enablerepo
but --skip-broken, and I have a hard time remembering which ones get the
hyphen inbetween*, and which ones don't. Could we settle on one way or
the other, right now quite the majority are without hyphen, and
deprecate the other (but presumably enable both spellings for a good
long while, perhaps with a warning if someone spells it the old way)?
Probably not take away the old spellings as soon as DNF 5, but it might
be a good time to add the more consistent spellings.

* Yes, I did that on purpose.

I'll definitely put this on the list.

We're primarily aiming at even worse stuff:
$ dnf list bash -> displays bash package
$ dnf list available -> displays all available packages
$ dnf list installed -> displays all installed packages
$ dnf list all -> displays all packages
What if there were packages named 'all', 'available' or 'installed'?
These are yum compatibility quirks which should be replaced with proper
--options. There's definitely much more than this example.

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

Re: Announcing start of DNF 5 development

2020-03-05 Thread Daniel Mach




Dne 05. 03. 20 v 13:02 Marcin Juszkiewicz napsal(a):

W dniu 04.03.2020 o 19:03, Daniel Mach pisze:

Hello everyone, I'm pleased to announce start of DNF 5 development.



microdnf

  > Microdnf is becoming important because it's part of

many containers due to its small footprint.


[root@puchatek hrw]# ldd /bin/microdnf |wc -l
70Following deps should be going away:

libglib-2.0.so.0
libgobject-2.0.so.0
libffi.so.6
libpeas-1.0.so.0
libgmodule-2.0.so.0
libgirepository-1.0.so.1
libgio-2.0.so.0



hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l
20

Are there plans for picodnf then? Or cutting amount of
libraries used by microdnf?


I don't think we can drop more without losing functionality.
If you take a closer look, libdnf links to libcurl which pulls most of 
the dependencies.




My problem with DNF is Python. There is a huge amount of
packages which need to be in proper state to be able to use
dnf. I remember when I did some experiments with RHEL7 and
managed to get to the point where 'yum' was unable to help
as Python was broken.


This probably makes you one of the users we're improving microdnf for.
I hope that someday we'll get microdnf close to 100% feature parity with 
DNF (Python plugins excluding obviously). But that's going to take a 
while...

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

Re: Announcing start of DNF 5 development

2020-03-05 Thread Michael Catanzaro



Also: builddep vs. build-dep

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

Re: Announcing start of DNF 5 development

2020-03-05 Thread J. Randall Owens

On 04/03/2020 18:03, Daniel Mach wrote:
> Hello everyone,
> I'm pleased to announce start of DNF 5 development. We are planning to
> deliver a module stream or a COPR repo during Fedora 33 development for
> early adopters and tool developers and we're hoping in getting a stable
> version into Fedora 34.
> 
> 
> More details follow.
> 
> 
> We've managed to drop a lot of redundant code across the whole DNF stack
> in the past years, but we have reached a point when it's nearly
> impossible to consolidate the code any further without breaking the
> API/ABI. Especially with PackageKit being dead[1], we can't move with
> the old "libhif" API in libdnf, because making any bigger changes to
> PackageKit is clearly out of scope.
> 
> [1]
> https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
> 
> 
> 
> That's why we decided to start working on a new version of the DNF
> stack: DNF 5. And this is the plan:
> 
> 
> Priorities
> --
> 1. Consistency, documentation and user experience is the top priority.
> 2. Compatibility on the command line level.
> 3. Compatibility on the API level.


In favour of 1., but going against 2., I've wanted since the YUM days to
see more consistency in the compound-word* options. E.g., --enablerepo
but --skip-broken, and I have a hard time remembering which ones get the
hyphen inbetween*, and which ones don't. Could we settle on one way or
the other, right now quite the majority are without hyphen, and
deprecate the other (but presumably enable both spellings for a good
long while, perhaps with a warning if someone spells it the old way)?
Probably not take away the old spellings as soon as DNF 5, but it might
be a good time to add the more consistent spellings.

* Yes, I did that on purpose.

-- 
J. Randall Owens | http://www.GhiaPet.net/



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

2 Kernel related quick-docs need review

2020-03-05 Thread Ankur Sinha

Two more quick docs need specialist knowledge:

- Building a custom kernel:
  https://pagure.io/fedora-docs/quick-docs/issue/210
- Kernel troubleshooting:
  https://pagure.io/fedora-docs/quick-docs/issue/209

Could someone with sufficient kernel building/troubleshooting knowledge
please take a look at these?

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

Anaconda quick-docs need review

2020-03-05 Thread Ankur Sinha

Hi,

There are some quick-docs related to Anaconda that need review but
require specialist Anaconda knowledge.

Could someone that knows Anaconda well (the devs?) please look at these?

- Creating a product image:
  https://pagure.io/fedora-docs/quick-docs/issue/218
- Anaconda logging: https://pagure.io/fedora-docs/quick-docs/issue/217
- Anaconda updates: https://pagure.io/fedora-docs/quick-docs/issue/216

and the Anaconda page in general:
https://docs.fedoraproject.org/en-US/quick-docs/anaconda/anaconda/

Should these reside in the quick-docs at all? If not please let us know
and we'll remove them.

-- 
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: How to add i686 package availabe for download on x86_64 system?

2020-03-05 Thread Artem Tim

Filed a bug. @Kamil, many 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

Re: rawhide broken due to recent glibc update?

2020-03-05 Thread Fabio Valentini

On Thu, Mar 5, 2020 at 3:48 PM Florian Weimer  wrote:
>
> * Florian Weimer:
>
> > * Fabio Valentini:
> >
> >> I'm starting to see many packages fail to build in koschei, possibly
> >> related to the latest glibc update. All packages I looked at fail in
> >> %prep when running unzip, for example:
> >>
> >> + /usr/bin/unzip -qq /builddir/build/SOURCES/osgi.core-7.0.0.jar
> >> warning:  cannot set modif./access times for META-INF/MANIFEST.MF
> >>   Not a directory
> >
> > utimensat(0, "META-INF/maven/", [{tv_sec=1517497582, tv_nsec=0} /* 
> > 2018-02-01T16:06:22+0100 */, {tv_sec=1517497582, tv_nsec=0} /* 
> > 2018-02-01T16:06:22+0100 */], 0) = -1 ENOTDIR (Not a directory)
> >
> > I see what's going on.  The argument is 0, not AT_FDCWD. 8-(
> >
> > I'll fix this ASAP.
>
> My testing shows that it is fixed in glibc-2.31.9000-3.fc33.  Sorry for
> the incovenience.

Can confirm, it looks fixed now. Thank you!

Fabio

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

[Test-Announce] Fedora 32 Beta Go/No-Go meeting

2020-03-05 Thread Ben Cotton

Dear all,

The Go/No-Go meeting for the Fedora 32 Beta release will be held on
Thursday, 2020-03-12 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting

View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/meeting/9716/

As usual, we will have the Release Readiness meeting following at
19:00 UTC. This time, I'm asking teams to do their homework in
advance. Please update your team's status at:
https://fedoraproject.org/wiki/Release_Readiness

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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: mock inside docker


On 05. 03. 20 15:09, Christoph Junghans wrote:

Hi,

if I am trying to run mock inside docker, I am getting the following error:
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed:
  # /bin/mount -n --bind
/var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum

In the past I usually added --old-chroot to workaround that, but now
this yields:
ERROR: Command failed:
  # /bin/mount -n -t tmpfs -o rprivate tmpfs
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc

This mock 2.0 inside the f31 ("fedora:latest") container from this morning.

Any idea how get mock working again?


We run mock in docker with:

$ docker run --cap-add=SYS_ADMIN

And it seems to still work (on Travis CI at least).

--
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: mock inside docker

2020-03-05 Thread Christoph Junghans

On Thu, Mar 5, 2020 at 9:23 AM Frantisek Zatloukal  wrote:
>
> Hi,
>
> adding "--no-bootstrap-chroot" wouldn't help?
Nope, still getting:
ERROR: Command failed:
 # /bin/mount -n --bind
/var/cache/mock/fedora-rawhide-x86_64/yum_cache
/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/yum

Christoph
>
> On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans  wrote:
>>
>> Hi,
>>
>> if I am trying to run mock inside docker, I am getting the following error:
>> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
>> ERROR: Command failed:
>>  # /bin/mount -n --bind
>> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>>
>> In the past I usually added --old-chroot to workaround that, but now
>> this yields:
>> ERROR: Command failed:
>>  # /bin/mount -n -t tmpfs -o rprivate tmpfs
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>>
>> This mock 2.0 inside the f31 ("fedora:latest") container from this morning.
>>
>> Any idea how get mock working again?
>>
>> Christoph
>>
>> --
>> Christoph Junghans
>> Web: http://www.compphys.de
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Quality Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



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

Re: mock inside docker

2020-03-05 Thread Frantisek Zatloukal

Hi,

adding "--no-bootstrap-chroot" wouldn't help?

On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans 
wrote:

> Hi,
>
> if I am trying to run mock inside docker, I am getting the following error:
> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
> ERROR: Command failed:
>  # /bin/mount -n --bind
> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>
> In the past I usually added --old-chroot to workaround that, but now
> this yields:
> ERROR: Command failed:
>  # /bin/mount -n -t tmpfs -o rprivate tmpfs
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>
> This mock 2.0 inside the f31 ("fedora:latest") container from this morning.
>
> Any idea how get mock working again?
>
> Christoph
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Best regards / S pozdravem,

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

Fedora-Cloud-31-20200305.0 compose check report

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

Directory hierarchy in icon-theme packages

2020-03-05 Thread Artur Iwicki

I couldn't find an answer in the Packaging Guidelines, so I'm writing here.

My question is as follows: looking at the various icon-theme packages in 
Fedora, they seem to adhere to the following directory hierarchy:
- 16x16
| - apps
| - emblems
| - (other categories)
- 32x32
| - (categories)
- (other sizes)

However, looking through some icon packs on the Internet, many authors use the 
following hierarchy instead:
- apps
| - 16px
| - 32px
| - (other sizes)
- mimetypes
| - (sizes)
- (other categories)

Is there any kind of preference in Fedora for the first option, so that one 
should move the files around to match it, or should the directory hierarchy be 
left they way upstream does it? I guess since the "index.theme" file lists all 
the paths, it doesn't matter from a technical standpoint, but I still thought 
it'd be better to ask.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 broken due to recent glibc update?

2020-03-05 Thread Florian Weimer

* Florian Weimer:

> * Fabio Valentini:
>
>> I'm starting to see many packages fail to build in koschei, possibly
>> related to the latest glibc update. All packages I looked at fail in
>> %prep when running unzip, for example:
>>
>> + /usr/bin/unzip -qq /builddir/build/SOURCES/osgi.core-7.0.0.jar
>> warning:  cannot set modif./access times for META-INF/MANIFEST.MF
>>   Not a directory
>
> utimensat(0, "META-INF/maven/", [{tv_sec=1517497582, tv_nsec=0} /* 
> 2018-02-01T16:06:22+0100 */, {tv_sec=1517497582, tv_nsec=0} /* 
> 2018-02-01T16:06:22+0100 */], 0) = -1 ENOTDIR (Not a directory)
>
> I see what's going on.  The argument is 0, not AT_FDCWD. 8-(
>
> I'll fix this ASAP.

My testing shows that it is fixed in glibc-2.31.9000-3.fc33.  Sorry for
the incovenience.

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

Re: GCC-10 is blocking tests on my package

Thanks a lot for clarification!

On Thu, 2020-03-05 at 15:26 +0100, Miro Hrončok wrote:
> On 05. 03. 20 15:21, jkone...@redhat.com wrote:
> > Thanks for reply, see my answers inline.
> > 
> > On Thu, 2020-03-05 at 10:26 +0100, Miro Hrončok wrote:
> > > On 05. 03. 20 9:12, jkone...@redhat.com wrote:
> > > > Hello everyone,
> > > > 
> > > > I'm co-maintaining package of kakoune and this package have
> > > > failing
> > > > build on F32 and Rawhide because of tests.
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1799560
> > > > 
> > > > As you can see in the last comment there is an upstream bug on
> > > > gcc-
> > > > 10
> > > > which is blocking the package tests.
> > > > 
> > > > What I want to know is what should be my next steps right now.
> > > > 
> > > > - Should I create bugzilla on Fedora side on gcc and block my
> > > > bug
> > > > on
> > > > this bug?
> > > 
> > > You can. You don't need to.
> > 
> > I'll follow Daniels answer so I'll create the bug that Fedora
> > maintainer of gcc, so they can look on that and know that it's
> > blocking
> > my package.
> 
> That was good advice.
> 
> > > > - Should I disable those tests?
> > > 
> > > You can. You don't need to, unless you need to rebuild the
> > > package
> > > for some reason.
> > 
> > Isn't new gcc version requirement for rebuild?
> 
> Strictly speaking, no. Evetually, you'll need to rebuild this once.
> But you 
> don't need to make it a top priority at this moment, unless it is
> blocking some 
> other packages or an update you want or a security fix, etc...
> 
> > > > - Should I wait if gcc-10 upstream will solve this issue in
> > > > time
> > > > for
> > > > F32?
> > > 
> > > You can. Or they can solve it later.
> > 
> > Wouldn't that mean that kakoune package won't be present in F32?
> > Maybe
> > I'm miss-understanding the issue here but if it won't compile with
> > new
> > gcc it will have different ABI than rest of the F32 apps so it
> > basically can't be used there?
> 
> It is present in Fedora 32. It should work, unless the executables
> and shared 
> object files produced by gcc 10 cannot work with stuff compiled by
> gcc 9 (that 
> would be very bad).
> 
> > > > - Should I propose Fedora 32 blocker because of the bug in gcc?
> > > 
> > > Why would you do that? How is Fedora 32 broken if we release it
> > > with
> > > kakoune not
> > > rebuilt yet? Is this FTBFS blocking other libraries from being
> > > updated as
> > > planned for Fedora 32?
> > 
> > If this is not that serious issue and it's affecting only my
> > package
> > than it's fine I guess.
> 
> It is fine.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GCC-10 is blocking tests on my package


On 05. 03. 20 15:21, jkone...@redhat.com wrote:

Thanks for reply, see my answers inline.

On Thu, 2020-03-05 at 10:26 +0100, Miro Hrončok wrote:

On 05. 03. 20 9:12, jkone...@redhat.com wrote:

Hello everyone,

I'm co-maintaining package of kakoune and this package have failing
build on F32 and Rawhide because of tests.

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

As you can see in the last comment there is an upstream bug on gcc-
10
which is blocking the package tests.

What I want to know is what should be my next steps right now.

- Should I create bugzilla on Fedora side on gcc and block my bug
on
this bug?


You can. You don't need to.


I'll follow Daniels answer so I'll create the bug that Fedora
maintainer of gcc, so they can look on that and know that it's blocking
my package.


That was good advice.


- Should I disable those tests?


You can. You don't need to, unless you need to rebuild the package
for some reason.


Isn't new gcc version requirement for rebuild?


Strictly speaking, no. Evetually, you'll need to rebuild this once. But you 
don't need to make it a top priority at this moment, unless it is blocking some 
other packages or an update you want or a security fix, etc...



- Should I wait if gcc-10 upstream will solve this issue in time
for
F32?


You can. Or they can solve it later.


Wouldn't that mean that kakoune package won't be present in F32? Maybe
I'm miss-understanding the issue here but if it won't compile with new
gcc it will have different ABI than rest of the F32 apps so it
basically can't be used there?


It is present in Fedora 32. It should work, unless the executables and shared 
object files produced by gcc 10 cannot work with stuff compiled by gcc 9 (that 
would be very bad).



- Should I propose Fedora 32 blocker because of the bug in gcc?


Why would you do that? How is Fedora 32 broken if we release it with
kakoune not
rebuilt yet? Is this FTBFS blocking other libraries from being
updated as
planned for Fedora 32?


If this is not that serious issue and it's affecting only my package
than it's fine I guess.


It is fine.

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

Re: Announcing start of DNF 5 development

On Thu, Mar 5, 2020 at 9:09 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Mar 05, 2020 at 09:02:47AM -0500, Neal Gompa wrote:
> > On Thu, Mar 5, 2020 at 9:00 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote:
> > > >
> > > >
> > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> > > > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > > > > wrote:
> > > > >>Are you going to use sd-bus for the dbus library?
> > > > >>
> > > > >
> > > > >I'd hope not, given that we have cross-distro usage of DNF now, and a
> > > > >couple of them don't have systemd.
> > > > >
> > > > Do you know which distros do not have systemd?
> > > >
> > > > We have evaluated sd-bus to be the best dbus client available, but
> > > > we may have underestimated it's adoption.
> > > >
> > > > Couldn't systemd team split it into a separate library independent
> > > > on the rest of the systemd eco-system? :)
> > >
> > > It's already a separate library independent from the rest of the
> > > systemd eco-system ;)
> > >
> > > (OK, it's a single library with other parts included, but the sd-bus
> > > part is the biggest by far, and also sd-bus uses sd-event and sd-128
> > > internally, so they'd be required anyway. The other parts are smaller,
> > > and matter more because of dependencies they pull in than because of
> > > the code size itself. But it is possible to compile libsystemd w/o
> > > some features, notably without encryption, to save size and deps.
> > > I don't think there's any significant barrier to using libsystemd
> > > on non-systemd systems, except for psychological issues.)
> > >
> >
> > Don't discount psychological issues. The original reason for DNF not
> > being named YUM was so that the project would be free to do better
> > without the YUM baggage. That had the added effect of making it easier
> > to propose for other distributions to adopt because YUM has a very
> > negative reputation outside of the RHEL space.
>
> ;]]] Let's just hope that the underlying ipc library is something that
> is not visible to users ;)
>

The BuildRequires: systemd-devel generally gives it away, and the
failure to build because of that missing dependency is usually a
problem.



-- 
真実はいつも一つ！/ 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: GCC-10 is blocking tests on my package

Thanks for reply, see my answers inline.

On Thu, 2020-03-05 at 10:26 +0100, Miro Hrončok wrote:
> On 05. 03. 20 9:12, jkone...@redhat.com wrote:
> > Hello everyone,
> > 
> > I'm co-maintaining package of kakoune and this package have failing
> > build on F32 and Rawhide because of tests.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1799560
> > 
> > As you can see in the last comment there is an upstream bug on gcc-
> > 10
> > which is blocking the package tests.
> > 
> > What I want to know is what should be my next steps right now.
> > 
> > - Should I create bugzilla on Fedora side on gcc and block my bug
> > on
> > this bug?
> 
> You can. You don't need to.

I'll follow Daniels answer so I'll create the bug that Fedora
maintainer of gcc, so they can look on that and know that it's blocking
my package.

> 
> > - Should I disable those tests?
> 
> You can. You don't need to, unless you need to rebuild the package
> for some reason.

Isn't new gcc version requirement for rebuild?

> 
> > - Should I wait if gcc-10 upstream will solve this issue in time
> > for
> > F32?
> 
> You can. Or they can solve it later.

Wouldn't that mean that kakoune package won't be present in F32? Maybe
I'm miss-understanding the issue here but if it won't compile with new
gcc it will have different ABI than rest of the F32 apps so it
basically can't be used there?

> 
> > - Should I propose Fedora 32 blocker because of the bug in gcc?
> 
> Why would you do that? How is Fedora 32 broken if we release it with
> kakoune not 
> rebuilt yet? Is this FTBFS blocking other libraries from being
> updated as 
> planned for Fedora 32?

If this is not that serious issue and it's affecting only my package
than it's fine I guess.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GCC-10 is blocking tests on my package

Great advice. Thanks Daniel!

On Thu, 2020-03-05 at 10:08 +, Daniel P. Berrangé wrote:
> On Thu, Mar 05, 2020 at 10:26:56AM +0100, Miro Hrončok wrote:
> > On 05. 03. 20 9:12, jkone...@redhat.com wrote:
> > > Hello everyone,
> > > 
> > > I'm co-maintaining package of kakoune and this package have
> > > failing
> > > build on F32 and Rawhide because of tests.
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1799560
> > > 
> > > As you can see in the last comment there is an upstream bug on
> > > gcc-10
> > > which is blocking the package tests.
> > > 
> > > What I want to know is what should be my next steps right now.
> > > 
> > > - Should I create bugzilla on Fedora side on gcc and block my bug
> > > on
> > > this bug?
> > 
> > You can. You don't need to.
> > 
> > > - Should I disable those tests?
> > 
> > You can. You don't need to, unless you need to rebuild the package
> > for some reason.
> 
> I would *not* disable the tests, as IIUC, the tests are demonstrating
> that code is mis-compiled & thus not going to be reliable at runtime.
> The broken tests correctly detected the compilation problem,
> preventing
> a bad build getting into rawhide repos.
> 
> 
> > > - Should I wait if gcc-10 upstream will solve this issue in time
> > > for
> > > F32?
> > 
> > You can. Or they can solve it later.
> > 
> > > - Should I propose Fedora 32 blocker because of the bug in gcc?
> > 
> > Why would you do that? How is Fedora 32 broken if we release it
> > with kakoune
> > not rebuilt yet? Is this FTBFS blocking other libraries from being
> > updated
> > as planned for Fedora 32?
> 
> The linked GCC bug indicates this is a case that GCC 10 is mis-
> compiling
> the code. We were lucky in this case that kakoune has a test suite
> that
> detected the mis-compiled code by seeing incorrect test behaviour,
> and
> thus failed the build. So we still have the previous correctly
> compiled
> kakoune RPM in the repos.
> 
> The risk here is that there might be other packages in Fedora now
> built
> with GCC 10 that suffer the same mis-compilation, but which have not 
> got a test suite to catch the issue. These incorrectly build apps may
> then suffer runtime crashes for users.
> 
> I don't know enough about the GCC 10 to say whether this particular
> issue
> is likely to be a serious widespread issue. In the most serious cases
> these
> kind of bugs can require a mass rebuild of affected packages to solve
> it. 
> 
> I'd suggest we file a BZ against GCC in Fedora, linking to the GCC 10
> upstream bug, and then let GCC maintainers give their opinion on
> whether
> it is bad enough to warrant blocker status.
> 
> Regards,
> Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

mock inside docker

2020-03-05 Thread Christoph Junghans

Hi,

if I am trying to run mock inside docker, I am getting the following error:
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed:
 # /bin/mount -n --bind
/var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum

In the past I usually added --old-chroot to workaround that, but now
this yields:
ERROR: Command failed:
 # /bin/mount -n -t tmpfs -o rprivate tmpfs
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc

This mock 2.0 inside the f31 ("fedora:latest") container from this morning.

Any idea how get mock working again?

Christoph

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

Re: Announcing start of DNF 5 development

2020-03-05 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Mar 05, 2020 at 09:02:47AM -0500, Neal Gompa wrote:
> On Thu, Mar 5, 2020 at 9:00 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote:
> > >
> > >
> > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> > > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > > > wrote:
> > > >>Are you going to use sd-bus for the dbus library?
> > > >>
> > > >
> > > >I'd hope not, given that we have cross-distro usage of DNF now, and a
> > > >couple of them don't have systemd.
> > > >
> > > Do you know which distros do not have systemd?
> > >
> > > We have evaluated sd-bus to be the best dbus client available, but
> > > we may have underestimated it's adoption.
> > >
> > > Couldn't systemd team split it into a separate library independent
> > > on the rest of the systemd eco-system? :)
> >
> > It's already a separate library independent from the rest of the
> > systemd eco-system ;)
> >
> > (OK, it's a single library with other parts included, but the sd-bus
> > part is the biggest by far, and also sd-bus uses sd-event and sd-128
> > internally, so they'd be required anyway. The other parts are smaller,
> > and matter more because of dependencies they pull in than because of
> > the code size itself. But it is possible to compile libsystemd w/o
> > some features, notably without encryption, to save size and deps.
> > I don't think there's any significant barrier to using libsystemd
> > on non-systemd systems, except for psychological issues.)
> >
> 
> Don't discount psychological issues. The original reason for DNF not
> being named YUM was so that the project would be free to do better
> without the YUM baggage. That had the added effect of making it easier
> to propose for other distributions to adopt because YUM has a very
> negative reputation outside of the RHEL space.

;]]] Let's just hope that the underlying ipc library is something that
is not visible to users ;)

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: Announcing start of DNF 5 development

On Thu, Mar 5, 2020 at 9:02 AM Josh Boyer  wrote:
>
> On Thu, Mar 5, 2020 at 8:35 AM Neal Gompa  wrote:
> >
> > On Thu, Mar 5, 2020 at 8:29 AM Daniel Mach  wrote:
> > >
> > >
> > >
> > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > > >  wrote:
> > > >> Are you going to use sd-bus for the dbus library?
> > > >>
> > > >
> > > > I'd hope not, given that we have cross-distro usage of DNF now, and a
> > > > couple of them don't have systemd.
> > > >
> > > Do you know which distros do not have systemd?
> > >
> > > We have evaluated sd-bus to be the best dbus client available, but we
> > > may have underestimated it's adoption.
> > >
> > > Couldn't systemd team split it into a separate library independent on
> > > the rest of the systemd eco-system? :)
> > >
> >
> > Off the top of my head: PLD and ALT do not mandate systemd usage, and
> > their default setup is still sysvinit.
> >
> > PCLinuxOS also does not have systemd and does not currently intend on
> > including it.
>
> If I were weighing the value of having dnf work on those distributions
> vs. building out a more robust and maintainable dnf for *most*
> distributions, I would choose the later.  My point here is that
> cross-distro compatibility is important, but it is not the most
> important thing.
>

Perhaps, but no code has been written yet, so this decision isn't set
in stone. This is the perfect time to make sure we don't trap
ourselves.

And I also forgot all about Yocto, which switched to DNF back in Yocto
2.3. They do not use systemd by default in a lot of cases, and having
DNF work there without systemd is valuable because of all the
configurations they offer that systemd does not support.



-- 
真実はいつも一つ！/ 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: Announcing start of DNF 5 development

On Thu, Mar 5, 2020 at 9:00 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote:
> >
> >
> > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > >>Are you going to use sd-bus for the dbus library?
> > >>
> > >
> > >I'd hope not, given that we have cross-distro usage of DNF now, and a
> > >couple of them don't have systemd.
> > >
> > Do you know which distros do not have systemd?
> >
> > We have evaluated sd-bus to be the best dbus client available, but
> > we may have underestimated it's adoption.
> >
> > Couldn't systemd team split it into a separate library independent
> > on the rest of the systemd eco-system? :)
>
> It's already a separate library independent from the rest of the
> systemd eco-system ;)
>
> (OK, it's a single library with other parts included, but the sd-bus
> part is the biggest by far, and also sd-bus uses sd-event and sd-128
> internally, so they'd be required anyway. The other parts are smaller,
> and matter more because of dependencies they pull in than because of
> the code size itself. But it is possible to compile libsystemd w/o
> some features, notably without encryption, to save size and deps.
> I don't think there's any significant barrier to using libsystemd
> on non-systemd systems, except for psychological issues.)
>

Don't discount psychological issues. The original reason for DNF not
being named YUM was so that the project would be free to do better
without the YUM baggage. That had the added effect of making it easier
to propose for other distributions to adopt because YUM has a very
negative reputation outside of the RHEL space.


-- 
真実はいつも一つ！/ 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: Announcing start of DNF 5 development

2020-03-05 Thread Josh Boyer

On Thu, Mar 5, 2020 at 8:35 AM Neal Gompa  wrote:
>
> On Thu, Mar 5, 2020 at 8:29 AM Daniel Mach  wrote:
> >
> >
> >
> > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > >> Are you going to use sd-bus for the dbus library?
> > >>
> > >
> > > I'd hope not, given that we have cross-distro usage of DNF now, and a
> > > couple of them don't have systemd.
> > >
> > Do you know which distros do not have systemd?
> >
> > We have evaluated sd-bus to be the best dbus client available, but we
> > may have underestimated it's adoption.
> >
> > Couldn't systemd team split it into a separate library independent on
> > the rest of the systemd eco-system? :)
> >
>
> Off the top of my head: PLD and ALT do not mandate systemd usage, and
> their default setup is still sysvinit.
>
> PCLinuxOS also does not have systemd and does not currently intend on
> including it.

If I were weighing the value of having dnf work on those distributions
vs. building out a more robust and maintainable dnf for *most*
distributions, I would choose the later.  My point here is that
cross-distro compatibility is important, but it is not the most
important thing.

josh

> Also, I can't use systemd stuff on darwin-based systems (macOS and
> PureDarwin), even though that may not matter to you. :)
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing start of DNF 5 development

2020-03-05 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote:
> 
> 
> Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> >>Are you going to use sd-bus for the dbus library?
> >>
> >
> >I'd hope not, given that we have cross-distro usage of DNF now, and a
> >couple of them don't have systemd.
> >
> Do you know which distros do not have systemd?
> 
> We have evaluated sd-bus to be the best dbus client available, but
> we may have underestimated it's adoption.
> 
> Couldn't systemd team split it into a separate library independent
> on the rest of the systemd eco-system? :)

It's already a separate library independent from the rest of the
systemd eco-system ;)

(OK, it's a single library with other parts included, but the sd-bus
part is the biggest by far, and also sd-bus uses sd-event and sd-128
internally, so they'd be required anyway. The other parts are smaller,
and matter more because of dependencies they pull in than because of
the code size itself. But it is possible to compile libsystemd w/o
some features, notably without encryption, to save size and deps.
I don't think there's any significant barrier to using libsystemd
on non-systemd systems, except for psychological issues.)

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: Announcing start of DNF 5 development

On Thu, Mar 5, 2020 at 8:29 AM Daniel Mach  wrote:
>
>
>
> Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
> > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> >> Are you going to use sd-bus for the dbus library?
> >>
> >
> > I'd hope not, given that we have cross-distro usage of DNF now, and a
> > couple of them don't have systemd.
> >
> Do you know which distros do not have systemd?
>
> We have evaluated sd-bus to be the best dbus client available, but we
> may have underestimated it's adoption.
>
> Couldn't systemd team split it into a separate library independent on
> the rest of the systemd eco-system? :)
>

Off the top of my head: PLD and ALT do not mandate systemd usage, and
their default setup is still sysvinit.

PCLinuxOS also does not have systemd and does not currently intend on
including it.

Also, I can't use systemd stuff on darwin-based systems (macOS and
PureDarwin), even though that may not matter to you. :)


-- 
真実はいつも一つ！/ 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: Announcing start of DNF 5 development

2020-03-05 Thread Daniel Mach




Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):

On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
 wrote:

Are you going to use sd-bus for the dbus library?



I'd hope not, given that we have cross-distro usage of DNF now, and a
couple of them don't have systemd.


Do you know which distros do not have systemd?

We have evaluated sd-bus to be the best dbus client available, but we 
may have underestimated it's adoption.


Couldn't systemd team split it into a separate library independent on 
the rest of the systemd eco-system? :)

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

2020-03-05 Thread Alejandro Álvarez Ayllón

Hi,

Sergio, sourcextractor++ is also affected by this. Could you CC me in the
future, please, just in case I overlook the email to the dev list?

El jue., 5 mar. 2020 a las 13:20, Sergio Pascual ()
escribió:

> Hello, I'm going to update (one week from now) wcslib to from 6.4 to 7.1.
> There is an API break, the changes are here;
> https://www.atnf.csiro.au/people/mcalabre/WCS/CHANGES
>
> I'm CCing affected package owners (astrometry, cpl, kstars and
> python-astropy).
>
> Regards, Sergio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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

Updating wcslib in Rawhide to 7.1

2020-03-05 Thread Sergio Pascual

Hello, I'm going to update (one week from now) wcslib to from 6.4 to 7.1.
There is an API break, the changes are here;
https://www.atnf.csiro.au/people/mcalabre/WCS/CHANGES

I'm CCing affected package owners (astrometry, cpl, kstars and
python-astropy).

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

Re: Announcing start of DNF 5 development

On Thu, Mar 5, 2020 at 7:06 AM Marcin Juszkiewicz
 wrote:
>
> W dniu 04.03.2020 o 19:03, Daniel Mach pisze:
> > Hello everyone, I'm pleased to announce start of DNF 5 development.
>
> > microdnf
>  > Microdnf is becoming important because it's part of
> > many containers due to its small footprint.
>
> [root@puchatek hrw]# ldd /bin/microdnf |wc -l
> 70
>
> hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l
> 20
>

Apt's library dependencies are a lie if you look just at /usr/bin/apt,
as it relies very heavily on subprocessing for core functionality.
You'd need to check and add the dependencies of the helper binaries
that are required for apt functionality. Last I checked with 1.9.10,
it's fairly comparable.

> Are there plans for picodnf then? Or cutting amount of
> libraries used by microdnf?
>
> My problem with DNF is Python. There is a huge amount of
> packages which need to be in proper state to be able to use
> dnf. I remember when I did some experiments with RHEL7 and
> managed to get to the point where 'yum' was unable to help
> as Python was broken.

Micro DNF is in C (using glib/gobject) today and would be in C++ in
the future. The transition from C to C++ will allow the GNOME library
ecosystem to be fully dropped as a dependency from the DNF stack. That
is substantial baggage that will finally go away.

-- 
真実はいつも一つ！/ 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: Announcing start of DNF 5 development

2020-03-05 Thread Marcin Juszkiewicz

W dniu 04.03.2020 o 19:03, Daniel Mach pisze:
> Hello everyone, I'm pleased to announce start of DNF 5 development.

> microdnf
 > Microdnf is becoming important because it's part of
> many containers due to its small footprint.

[root@puchatek hrw]# ldd /bin/microdnf |wc -l
70

hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l
20

Are there plans for picodnf then? Or cutting amount of 
libraries used by microdnf?

My problem with DNF is Python. There is a huge amount of
packages which need to be in proper state to be able to use
dnf. I remember when I did some experiments with RHEL7 and
managed to get to the point where 'yum' was unable to help
as Python was broken.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 broken due to recent glibc update?

2020-03-05 Thread Florian Weimer

* Fabio Valentini:

> I'm starting to see many packages fail to build in koschei, possibly
> related to the latest glibc update. All packages I looked at fail in
> %prep when running unzip, for example:
>
> + /usr/bin/unzip -qq /builddir/build/SOURCES/osgi.core-7.0.0.jar
> warning:  cannot set modif./access times for META-INF/MANIFEST.MF
>   Not a directory

utimensat(0, "META-INF/maven/", [{tv_sec=1517497582, tv_nsec=0} /* 
2018-02-01T16:06:22+0100 */, {tv_sec=1517497582, tv_nsec=0} /* 
2018-02-01T16:06:22+0100 */], 0) = -1 ENOTDIR (Not a directory)

I see what's going on.  The argument is 0, not AT_FDCWD. 8-(

I'll fix this ASAP.

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

Re: Announcing start of DNF 5 development

On Thu, Mar 5, 2020 at 5:58 AM Martin Kolman  wrote:
>
> On Thu, 2020-03-05 at 08:56 +0100, jkone...@redhat.com wrote:
>
> On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote:
>
> On Thu, Mar 5, 2020, 00:55 Martin Kolman  wrote:
>
>
>
> - Original Message -
> > From: "Neal Gompa" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Wednesday, March 4, 2020 11:01:43 PM
> > Subject: Re: Announcing start of DNF 5 development
> >
> > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote:
> > > > Hello everyone,
> > > > I'm pleased to announce start of DNF 5 development. We are planning
> > > > to deliver a module stream or a COPR repo during Fedora 33
> > > > development for early adopters and tool developers and we're hoping
> > > > in getting a stable version into Fedora 34.
> > > >
> > > >
> > > > More details follow.
> > > >
> > > >
> > > > We've managed to drop a lot of redundant code across the whole DNF
> > > > stack in the past years, but we have reached a point when it's
> > > > nearly impossible to consolidate the code any further without
> > > > breaking the API/ABI. Especially with PackageKit being dead[1], we
> > > > can't move with the old "libhif" API in libdnf, because making any
> > > > bigger changes to PackageKit is clearly out of scope.
> > > >
> > > > [1]
> > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
> > > >
> > > >
> > > > That's why we decided to start working on a new version of the DNF
> > > > stack: DNF 5. And this is the plan:
> > > >
> > > >
> > > > Priorities
> > > > --
> > > > 1. Consistency, documentation and user experience is the top priority.
> > > > 2. Compatibility on the command line level.
> > > > 3. Compatibility on the API level.
> > > >
> > > >
> > > > Maintenance
> > > > ---
> > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat
> > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master
> > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf
> > > > from the DNF 4 stack.
> > > >
> > > >
> > > > The existing Python API in DNF
> > > > --
> > > > The Python API in DNF stays. We'll do our best to keep it working.
> > > > If there is an incompatible change, we'll communicate and document
> > > > it properly.
> > > >
> > > >
> > > > The new API in libdnf
> > > > -
> > > > All business logic will move from DNF (Python) to libdnf (C++). This
> > > > is the only way to ensure that package managers work identically
> > > > across the whole distribution. We'll start with C++ API and
> > > > auto-generated Python bindings via SWIG. We'll focus on the Python
> > > > bindings which are required by DNF and we will do our best to
> > > > provide bindings for Go, Perl5 and Ruby as well. C API will be
> > > > created later when the C++ API is stable. At that moment rpm-ostree
> > > > will be ported to the new C API.
> > > >
> > > >
> > > > hawkey
> > > > --
> > > > Hawkey Python API is going away and will be replaced with libdnf Python
> > > > API.
> > > >
> > > >
> > > > DNF
> > > > ---
> > > > DNF stays as the primary command-line package manager. The overall
> > > > functionality remains. We don't anticipate any negative impact of
> > > > the API rewrite on the end-users. We have built an extensive test
> > > > suite (over 1400 scenarios) that will help us to ensure that. The
> > > > argument parser and outputs may slightly change in some cases to
> > > > provide a more consistent user-experience. All such cases will be
> > > > properly documented.
> > > >
> > > >
> > > > microdnf
> > > > 
> > > > Microdnf is becoming important because it's part of many containers
> > > > due to its small footprint. We're getting feedback that users would
> > > > appreciate something closer to DNF. We'll focus on implementing a
> > > > subset of DNF's functionality and improving the user experience.
> > > > 100% feature parity with DNF is currently out of scope.
> > > >
> > > >
> > > Hi,
> > >
> > > the roadmap is ambitious, but not impossible. Good luck!
> > >
> > > > Roadmap (tentative)
> > > > ---
> > > > * Mar 2020 - making the bigger API changes, upstream code barely 
> > > > compiles
> > > > * May 2020 - COPR repo with first development snapshots
> > > > * Jun 2020 - F33 module available for early adopters and tool developers
> > > > * Oct 2020 - DNF 5 landing in F34 Rawhide
> > > > * Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora
> > >
> > > > DBus service
> > > > 
> > > > DNF team has decided to create a new DBus service replacing
> > > > PackageKit to provide an interface to GUI applications. It's
> > > > probably going to take a while because we're planning to start from
> > > > scratch.
> > >
> > > Do you plan to make normal 'dnf' calls go through the dbus api?
> >
>

Re: Announcing start of DNF 5 development

2020-03-05 Thread Martin Kolman

On Thu, 2020-03-05 at 08:56 +0100, jkone...@redhat.com wrote:
> On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote:
> > On Thu, Mar 5, 2020, 00:55 Martin Kolman  wrote:
> > > 
> > > 
> > > - Original Message -
> > > 
> > > > From: "Neal Gompa" 
> > > 
> > > > To: "Development discussions related to Fedora" 
> > > > 
> > > 
> > > > Sent: Wednesday, March 4, 2020 11:01:43 PM
> > > 
> > > > Subject: Re: Announcing start of DNF 5 development
> > > 
> > > > 
> > > 
> > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > > 
> > > >  wrote:
> > > 
> > > > >
> > > 
> > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote:
> > > 
> > > > > > Hello everyone,
> > > 
> > > > > > I'm pleased to announce start of DNF 5 development. We are planning
> > > 
> > > > > > to deliver a module stream or a COPR repo during Fedora 33
> > > 
> > > > > > development for early adopters and tool developers and we're hoping
> > > 
> > > > > > in getting a stable version into Fedora 34.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > More details follow.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > We've managed to drop a lot of redundant code across the whole DNF
> > > 
> > > > > > stack in the past years, but we have reached a point when it's
> > > 
> > > > > > nearly impossible to consolidate the code any further without
> > > 
> > > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we
> > > 
> > > > > > can't move with the old "libhif" API in libdnf, because making any
> > > 
> > > > > > bigger changes to PackageKit is clearly out of scope.
> > > 
> > > > > >
> > > 
> > > > > > [1]
> > > 
> > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > That's why we decided to start working on a new version of the DNF
> > > 
> > > > > > stack: DNF 5. And this is the plan:
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > Priorities
> > > 
> > > > > > --
> > > 
> > > > > > 1. Consistency, documentation and user experience is the top 
> > > > > > priority.
> > > 
> > > > > > 2. Compatibility on the command line level.
> > > 
> > > > > > 3. Compatibility on the API level.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > Maintenance
> > > 
> > > > > > ---
> > > 
> > > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat
> > > 
> > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master
> > > 
> > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf
> > > 
> > > > > > from the DNF 4 stack.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > The existing Python API in DNF
> > > 
> > > > > > --
> > > 
> > > > > > The Python API in DNF stays. We'll do our best to keep it working.
> > > 
> > > > > > If there is an incompatible change, we'll communicate and document
> > > 
> > > > > > it properly.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > The new API in libdnf
> > > 
> > > > > > -
> > > 
> > > > > > All business logic will move from DNF (Python) to libdnf (C++). This
> > > 
> > > > > > is the only way to ensure that package managers work identically
> > > 
> > > > > > across the whole distribution. We'll start with C++ API and
> > > 
> > > > > > auto-generated Python bindings via SWIG. We'll focus on the Python
> > > 
> > > > > > bindings which are required by DNF and we will do our best to
> > > 
> > > > > > provide bindings for Go, Perl5 and Ruby as well. C API will be
> > > 
> > > > > > created later when the C++ API is stable. At that moment rpm-ostree
> > > 
> > > > > > will be ported to the new C API.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > hawkey
> > > 
> > > > > > --
> > > 
> > > > > > Hawkey Python API is going away and will be replaced with libdnf 
> > > > > > Python
> > > 
> > > > > > API.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > DNF
> > > 
> > > > > > ---
> > > 
> > > > > > DNF stays as the primary command-line package manager. The overall
> > > 
> > > > > > functionality remains. We don't anticipate any negative impact of
> > > 
> > > > > > the API rewrite on the end-users. We have built an extensive test
> > > 
> > > > > > suite (over 1400 scenarios) that will help us to ensure that. The
> > > 
> > > > > > argument parser and outputs may slightly change in some cases to
> > > 
> > > > > > provide a more consistent user-experience. All such cases will be
> > > 
> > > > > > properly documented.
> > > 
> > > > > >
> > > 
> > > > > >
> > > 
> > > > > > microdnf
> > > 
> > > > > > 
> > > 
> > > > > > Microdnf is becoming important because it's part of many containers
> > > 
> > > > > > due to its small footprint. We're getting feedback that users would
> > > 
> > > > > > appreciate something closer to DNF. We'll focus on implementing a
> > > 
> > > > > > subset

Re: Announcing start of DNF 5 development

2020-03-05 Thread Martin Kolman

On Thu, 2020-03-05 at 09:11 +0100, Fabio Valentini wrote:
> On Thu, Mar 5, 2020, 08:56   wrote:
> > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote:
> > > On Thu, Mar 5, 2020, 00:55 Martin Kolman  wrote:
> > > > 
> > > > 
> > > > - Original Message -
> > > > 
> > > > > From: "Neal Gompa" 
> > > > 
> > > > > To: "Development discussions related to Fedora" 
> > > > > 
> > > > 
> > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM
> > > > 
> > > > > Subject: Re: Announcing start of DNF 5 development
> > > > 
> > > > > 
> > > > 
> > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
> > > > 
> > > > >  wrote:
> > > > 
> > > > > >
> > > > 
> > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote:
> > > > 
> > > > > > > Hello everyone,
> > > > 
> > > > > > > I'm pleased to announce start of DNF 5 development. We are 
> > > > > > > planning
> > > > 
> > > > > > > to deliver a module stream or a COPR repo during Fedora 33
> > > > 
> > > > > > > development for early adopters and tool developers and we're 
> > > > > > > hoping
> > > > 
> > > > > > > in getting a stable version into Fedora 34.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > More details follow.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > We've managed to drop a lot of redundant code across the whole DNF
> > > > 
> > > > > > > stack in the past years, but we have reached a point when it's
> > > > 
> > > > > > > nearly impossible to consolidate the code any further without
> > > > 
> > > > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we
> > > > 
> > > > > > > can't move with the old "libhif" API in libdnf, because making any
> > > > 
> > > > > > > bigger changes to PackageKit is clearly out of scope.
> > > > 
> > > > > > >
> > > > 
> > > > > > > [1]
> > > > 
> > > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > That's why we decided to start working on a new version of the DNF
> > > > 
> > > > > > > stack: DNF 5. And this is the plan:
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > Priorities
> > > > 
> > > > > > > --
> > > > 
> > > > > > > 1. Consistency, documentation and user experience is the top 
> > > > > > > priority.
> > > > 
> > > > > > > 2. Compatibility on the command line level.
> > > > 
> > > > > > > 3. Compatibility on the API level.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > Maintenance
> > > > 
> > > > > > > ---
> > > > 
> > > > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat
> > > > 
> > > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master
> > > > 
> > > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf
> > > > 
> > > > > > > from the DNF 4 stack.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > The existing Python API in DNF
> > > > 
> > > > > > > --
> > > > 
> > > > > > > The Python API in DNF stays. We'll do our best to keep it working.
> > > > 
> > > > > > > If there is an incompatible change, we'll communicate and document
> > > > 
> > > > > > > it properly.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > The new API in libdnf
> > > > 
> > > > > > > -
> > > > 
> > > > > > > All business logic will move from DNF (Python) to libdnf (C++). 
> > > > > > > This
> > > > 
> > > > > > > is the only way to ensure that package managers work identically
> > > > 
> > > > > > > across the whole distribution. We'll start with C++ API and
> > > > 
> > > > > > > auto-generated Python bindings via SWIG. We'll focus on the Python
> > > > 
> > > > > > > bindings which are required by DNF and we will do our best to
> > > > 
> > > > > > > provide bindings for Go, Perl5 and Ruby as well. C API will be
> > > > 
> > > > > > > created later when the C++ API is stable. At that moment 
> > > > > > > rpm-ostree
> > > > 
> > > > > > > will be ported to the new C API.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > hawkey
> > > > 
> > > > > > > --
> > > > 
> > > > > > > Hawkey Python API is going away and will be replaced with libdnf 
> > > > > > > Python
> > > > 
> > > > > > > API.
> > > > 
> > > > > > >
> > > > 
> > > > > > >
> > > > 
> > > > > > > DNF
> > > > 
> > > > > > > ---
> > > > 
> > > > > > > DNF stays as the primary command-line package manager. The overall
> > > > 
> > > > > > > functionality remains. We don't anticipate any negative impact of
> > > > 
> > > > > > > the API rewrite on the end-users. We have built an extensive test
> > > > 
> > > > > > > suite (over 1400 scenarios) that will help us to ensure that. The
> > > > 
> > > > > > > argument parser and outputs may slightly change in some cases to
> > > > 
> > > > > > > provide a more consistent user-experience. All

Re: GCC-10 is blocking tests on my package

2020-03-05 Thread Daniel P . Berrangé

On Thu, Mar 05, 2020 at 10:26:56AM +0100, Miro Hrončok wrote:
> On 05. 03. 20 9:12, jkone...@redhat.com wrote:
> > Hello everyone,
> > 
> > I'm co-maintaining package of kakoune and this package have failing
> > build on F32 and Rawhide because of tests.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1799560
> > 
> > As you can see in the last comment there is an upstream bug on gcc-10
> > which is blocking the package tests.
> > 
> > What I want to know is what should be my next steps right now.
> > 
> > - Should I create bugzilla on Fedora side on gcc and block my bug on
> > this bug?
> 
> You can. You don't need to.
> 
> > - Should I disable those tests?
> 
> You can. You don't need to, unless you need to rebuild the package for some 
> reason.

I would *not* disable the tests, as IIUC, the tests are demonstrating
that code is mis-compiled & thus not going to be reliable at runtime.
The broken tests correctly detected the compilation problem, preventing
a bad build getting into rawhide repos.

> > - Should I wait if gcc-10 upstream will solve this issue in time for
> > F32?
> 
> You can. Or they can solve it later.
> 
> > - Should I propose Fedora 32 blocker because of the bug in gcc?
> 
> Why would you do that? How is Fedora 32 broken if we release it with kakoune
> not rebuilt yet? Is this FTBFS blocking other libraries from being updated
> as planned for Fedora 32?

The linked GCC bug indicates this is a case that GCC 10 is mis-compiling
the code. We were lucky in this case that kakoune has a test suite that
detected the mis-compiled code by seeing incorrect test behaviour, and
thus failed the build. So we still have the previous correctly compiled
kakoune RPM in the repos.

The risk here is that there might be other packages in Fedora now built
with GCC 10 that suffer the same mis-compilation, but which have not 
got a test suite to catch the issue. These incorrectly build apps may
then suffer runtime crashes for users.

I don't know enough about the GCC 10 to say whether this particular issue
is likely to be a serious widespread issue. In the most serious cases these
kind of bugs can require a mass rebuild of affected packages to solve it. 

I'd suggest we file a BZ against GCC in Fedora, linking to the GCC 10
upstream bug, and then let GCC maintainers give their opinion on whether
it is bad enough to warrant blocker status.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Spend 5 minutes on reviewing a quick-doc!

2020-03-05 Thread Ankur Sinha

Thanks everyone who reviewed a quick-doc already.

We still have a few in queue:

https://pagure.io/fedora-docs/quick-docs/issues?status=Open&tags=help+wanted

A few of these are technical, but most of them only need someone to go
over and verify that the information is correct.

Please take a few minutes out to go over one or two---that'll help us
cover them all.

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

rawhide broken due to recent glibc update?

2020-03-05 Thread Fabio Valentini

Hi all,

I'm starting to see many packages fail to build in koschei, possibly
related to the latest glibc update. All packages I looked at fail in
%prep when running unzip, for example:

+ /usr/bin/unzip -qq /builddir/build/SOURCES/osgi.core-7.0.0.jar
warning:  cannot set modif./access times for META-INF/MANIFEST.MF
  Not a directory

I don't think running unzip on sources should fail :)

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

Re: Stuck qgis i686 build

2020-03-05 Thread Sandro Mani



On 04.03.20 23:02, Kevin Fenzi wrote:

Sure. Note that you can (and should) moving forward file a ticket for
things like this. Infrastructure or releng should work. :)


Ok will do!



Since it's just one thread taking 100%, could it be a multiple thread
issue? try building with smp_mflags 1?


Turns out gcc is hanging: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94045

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

Re: GCC-10 is blocking tests on my package


On 05. 03. 20 9:12, jkone...@redhat.com wrote:

Hello everyone,

I'm co-maintaining package of kakoune and this package have failing
build on F32 and Rawhide because of tests.

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

As you can see in the last comment there is an upstream bug on gcc-10
which is blocking the package tests.

What I want to know is what should be my next steps right now.

- Should I create bugzilla on Fedora side on gcc and block my bug on
this bug?


You can. You don't need to.


- Should I disable those tests?


You can. You don't need to, unless you need to rebuild the package for some 
reason.


- Should I wait if gcc-10 upstream will solve this issue in time for
F32?


You can. Or they can solve it later.


- Should I propose Fedora 32 blocker because of the bug in gcc?


Why would you do that? How is Fedora 32 broken if we release it with kakoune not 
rebuilt yet? Is this FTBFS blocking other libraries from being updated as 
planned for Fedora 32?


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

Re: Announcing start of DNF 5 development

2020-03-05 Thread Kevin Kofler

Kamil Paral wrote:

> On Wed, Mar 4, 2020 at 7:04 PM Daniel Mach  wrote:
> 
>> Hello everyone,
>> I'm pleased to announce start of DNF 5 development. We are planning to
>> deliver a module stream or a COPR repo during Fedora 33 development for
>> early adopters and tool developers and we're hoping in getting a stable
>> version into Fedora 34.
>>
>>
> Thanks for the announcement. I definitely prefer a COPR repo to a module
> stream :-)

+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-30-20200305.0 compose check report

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

GCC-10 is blocking tests on my package