Re: Self Introduction: Sergey Avseyev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2017-09-26 at 21:48 +0300, Sergey Avseyev wrote: > Hi Fedora Community Hey, > > My name is Sergey Avseyev. I live in Minsk, Belarus and work for > Couchbase. > > My main interests are revolving around networking and databases. > At Couchbase I work on libcouchbase (the client library with C > interface) > and PHP extension built atop of libcouchbase. I have build and > currently > maintaining our YUM repository with binary packages for libcouchbase. > And currently I have it submitted for review to become part of > Fedora. Welcome on board! > > https://bugzilla.redhat.com/show_bug.cgi?id=1495985 > > This is my first package and I need a sponsor > I currently have a package submitted for review: > https://bugzilla.redhat.com/show_bug.cgi?id=1495004 (please be > gentle) > and need a sponsor. Quickly checked spec file and gave some notes 😉 > > Once this package will be accepted, I'm going to submit my PHP > extension > too. > > Best regards. > > -- > Sergey Avseyev > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlnKsRAACgkQaVcUvRu8 X0x2yA/+LS0shYRH5a4PP2Yq6jr3X5dvQ8NnaWFFkCoN/uWXg6pUcLP1BLjbHaVD 0FEmjwxXRKFx72R7bywEicUOMteu+KmkiSQ48X6jMaZ9UHbHwrOD1o0+wgTe1wmC lYUWRu9NSDWsEeln34rnn3Qg4P0JfklWDIKjha58R4WO7eTDtWTDCtfOfLQQCDS1 f5Lorg+oLzGAG0hyS80TkUDd/cP1YFD7etvcddx3q65oXA4U1CZ3ju08QY6E6O3s RU1fHP9iGkCBgDoj9XwJbY4cG6jvweGXEshOLk3iOZEPl2kSj1LYZUENUEe+569+ 23vvKVNMZsfXraq3jKnfCjNOqlAVgLHj6HgvMlOjR+LL8yHjiXvKo8V0f3C1Ve1J 33nNNJtse7s+lOM8zjUmEr1AcIzMD7/UWb950ihcjtwqApuAXVn7qx7rFp3YgX5q CTL6s2rP94BRWQjoelzL5KGr6Epq3LGfH6GAZ3j/4uqj3ZflbHr7C9YI52zDftsU XBGzt5O1m2x4Ib7WaRSMJxolHJvUvX/zUiEJFBVvQN8RLOolD8ZUPCUqlnX7fSWY Ad307oCUXT0aBcaXC1F3uBAwzHNGiThFW/NWueJa50nM8jJ0ldDv4B/TAZRbdUU+ pjxn0hTpxGXm6AGnjcoobYh7XZx5afdz0VDU97AiedGCrP2ZGZU= =vpZI -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedrepo-req is complaining about cookies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-09-14 at 13:18 -0400, Jaroslav Skarvada wrote: > Hi, Hi, > > I am trying to add new package to fedora, I did: > > $ fedrepo-req wsjtx -t 1487776 -m monitoring > Error: The Bugzilla ticket could not be verified. The following error > was encountered: valid or have expired. You may login again to get new cookies or a > new token.'> > > My token was valid, but I requested new one and it still doesn't > work. > fedrepo-req-1.6.0-3.fc25.noarch > > Also tried to logout and re-login to Pagure in my browser, but it > still doesn't work I think you need to login to bugzilla.redhat.com.. > > thanks & regards > > Jaroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlm6vGkACgkQaVcUvRu8 X0yf7g/8DGrJhMYG0IUDhrSXVaXbM1ywFY7GI5p0TgB12RXwDRdv4Pp3Xm66T2TJ a4fPG+ueAcLwF2qp4ltKSCQXq5zWh+JfCnrE55I0drZWHL2xG3cKYBBDPx8s/uXG 436Tfpt4C1vU3GB0ygF6rD/Ty4dgB7Xdnn9ntbsgCOR1npHbgSmXxuIsnNwRv4F3 JcYSf0y1HC1zmp56jKZbeU7oL4HSuAYBKtaAGGwQIdcfYN5MmOSvosWTEmxcH6WZ CZM/Cu/LsIFopwFIf+lyHswaMx/lGTVoFGbdrY89Dpo+bCOBKeqmkoDB5GcW39xV fLpEJe9teuWT05XZv/KA9IGL1+YCDt+9TULyfd34w5n2xOpgNxeNEfIcK0co3Nq0 +cEDVPp9uS+50ax25M7WQsoiC04ARTCHuBWKU9iM1x2p/foRMS3Y3T+u0S3XrdSr MQlbmWEzUHw9EzxsCF9lBCi0wWcjbbfOsZb+4aDcvHaWM+okCpf8QLTaQWKu332d ypngn48rVk3/HNoELZDNruZTp6RN5+H0Z2eV9QVXxkpgQ1oquhcyuJWCs05CMm/n GZ5Eo3FVoi9l0wSdHiOjWdeCBMKSFsFbWu2fGTL2MKHbueXystKEjOXm97laS4Y0 LS2xE2yfpAJszEDNyDnZcaz6MjCBIL69auDWobB5XDfuoPjuJ2Y= =I219 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Deleting a fork in src.fedoraproject.org?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-08 at 22:35 +, Christopher wrote: > I was playing around in the new Pagure https://src.fedoraproject.org/ > and I > created a fork of a repo to test. However, I don't need or want this > fork. > How do I delete it? There doesn't appear to be an option. https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedo raproject.org/thread/MPFTHDDRXO6DSGZFA33J4TFHAKQK3LNU/ tl;dr it is possible, but not yet enabled in infrastructure. Hopefully it will be deployed soon. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmzlGEACgkQaVcUvRu8 X0xeJxAAuQGXw6WEQ4LpnW2UXo9srhIdjwUl45Eo5ne4fM/y9Z0JsYFKLR20IdAA 2kMAyluCI9L+WYTL9yhHtBOFyQP6Jh704s17FUQSV+mO0PN5o7gb97Dn73q/Jimj 6QVHprdQ97bM95qAlOvgyvg8wz3fVjWGn+6JlQ3lJLvf0ppPPb4nemF0Y6G5VEmy HVHX/0ODReTtKyZ3IVOhkRl+3Yt5e72EV9JMohYD33CT9Ci/PBewRYF+rXEtyDUd 6I82L96nSMXykzOfqpAq0yx+lbwcx8xk1Yg7We+H6vHm2uJ7BW21MI7Wxi/sS9Vh saB311jjeKkh0I4yCqX8ZuDeN5NnXZBPRv3vxZz3Fl2WImsFHJ1Ee44vioKFOMQG lTRyN2+dJPD61P0+bQB0UKW4ibdMrjgFBbqe3042T5yy5XS5kKWlyehLbtKhekkM k78FM1Z43FGLXG6DR3n0+rOjC+3HaonMlmGGQ6r6g1VJok9w4QNb9wX7vaZ5snLT cR6LwVacEhHeFOjlURUDs/f6HWFQW59bpAJ8fNjcS1Yh7shtkjOE/2sbP4V9nuhb tD9LfdF2ViOJT71CNl6agkckReyeHSdyPEAmj0B6rbibxBvKb5JSDTdqLvXdYhCI HkLtIq49TVHnFqVlCPCZLJZdEvxr0mcK2RKSqsFrp1xA0lvlCHM= =yxLL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Fedora 27 Beta Freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2017-09-06 at 12:17 +0200, Vít Ondruch wrote: > > Dne 5.9.2017 v 16:28 Mohan Boddu napsal(a): > > Hi all, > > Today is an important day on the Fedora 27 schedule[1], with two > > significant cut-offs. > > Today is the Beta freeze[2]. This means that only packages which > > fix > > accepted blocker or freeze exception bugs[3][4] will be marked as > > 'stable' and included in the Beta composes. Other builds will > > remain > > in updates-testing until the Beta release is approved, at which > > point > > the Beta freeze is lifted and packages can move to 'stable' as > > usual > > until the Final freeze. > > May be it would be good to point out that Bodhi was enabled for F27? > I > just checking my yesterday build (done prior this announcement) and > it > is in f27-updates-candidate indeed ... It actually was! See "Fedora 27 Bodhi Activation Point" mail which was sent on "Tue, 29 Aug 2017 11:05:17 -0400 (08/29/2017 05:05:17 PM)" 😉 > > > Vít > > > Today is also '100% code complete deadline' Change Checkpoint[5], > > meaning that Fedora 27 Changes must now be code complete, meaning > > all > > the code required to enable to the new change is finished. The > > level > > of code completeness is reflected as tracker bug state ON_QA. The > > change does not have to be fully tested by this deadline'. > > Finally, Fedora is not doing Alpha releases[6] anymore by keeping > > Rawhide > > at alpha quality. > > Regards > > Mohan Boddu > > > > [1] https://fedoraproject.org/wiki/Releases/27/Schedule > > [2] https://fedoraproject.org/wiki/Milestone_freezes > > [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process > > [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_proc > > ess > > [5] https://fedoraproject.org/wiki/Changes/Policy > > [6] https://fedoraproject.org/wiki/Changes/NoMoreAlpha > > > > > > ___ > > test-announce mailing list -- test-annou...@lists.fedoraproject.org > > To unsubscribe send an email to test-announce-leave@lists.fedorapro > > ject.org > > > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmv0FsACgkQaVcUvRu8 X0yv5BAAkmugft4wQy3Loz8nT3vTe8H6iFUVqmh+hkFZPqxHFhMt96JFBVnuGW3m srAL0u2lvVsDhScMLwbr8JbFB5Poy6uFIB6Htrj/Z+HPuyUHVh4O8vXvy+vNnkax YvOdc0d2LIvBRC90+HkX3EHMFKL/vWHFhkIGGKQXhcbB3FU4I8ztXQtw5wXc8tTN nj0+98CHZYzBquvA8MwYBmxoxXzPGQdzaEgvwzFaCQJ1345enA21sfOpylPZHYHM +N5SVb1ZlqHiY701dsfTcF/qGbvNAmB5t/AW1veH6I2ikNV4n7oNUWjPvxDM4I1I 1P7Ox5E6VHiEG9Z+bmWpip7kzKJFXqmaU4gpT6An8kjmWOgQZIaaTMt6EKzKs2tT rb5oHYAdgE82TUYxbcfkQKQ8yGP1WL0ms17+fQ76gKZ3gEGY2TlHBg+yVFaPg4bu 3/C3DrybWVE3i31lnyvhJmfFgmVe7UTltiRikUy+c4mDfaV3YnHkH38me04TG5ta abfX4xl9G24rGp2WJrkPkVzUgi6kU1/vh7dvQxJhYFZOMFCvFdrn+rePenPWXfNf iaAnZ7tAGIEoWe7X+9UV14d7wiVJK8zIVQKpqjpO+RxSCK7iPHsYUsIMcyna7wLR 56gyyjvi1r0ESv/PE2wjAozHfu76W6cmZRqwAAoIRmLIETP2eow= =c46T -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2017-09-05 at 08:37 +0200, Vít Ondruch wrote: > > Dne 5.9.2017 v 08:31 Nicolas Chauvet napsal(a): > > 2017-09-04 19:20 GMT+02:00 Richard Hughes : > > > On 4 September 2017 at 17:56, Neal Gompa > > > wrote: > > > > It sounds like it would make more sense for createrepo_c to > > > > link to > > > > the AppStream builder library to handle AppStream metadata > > > > processing > > > > as part of the createrepo_c repodata generation, wouldn't it? > > > > > > 100% agree. This does take some time currently (as we have to > > > decompress some files from the lzma archives) but this is > > > currently > > > done using my AMD Athlon Neo Microserver with spinning rust > > > drives. > > > Using something XEONy and SSDy it'd be orders of magnitude > > > faster. Are > > > we sure that we're using createrepo_c for composes? I know we > > > *used* > > > to be the old python one for some reason. > > > > As I understand, the problem with the decompression is that it > > fetches > > the payload. > > And if a rpm weight 100MB, it will downloads (RPMs are often stored > > on > > nfs, so network is involved) and decompress the whole 100MB > > (including > > the header, although this last might be uncompressed). > > On the opposite, storing information on the RPM header means > > grabbing > > only the first KB out of the whole RPM. > > > > As one can see, this might work for few RPMs, but this doesn't > > scale > > at all on a big whole repository with many arches, specially if the > > work from a previous appdata-builder run cannot be cached for a > > later > > updates. > > > > So I wonder if it would be possible to have a "second payload" with > > only the appdata (xml, imgs) that it would be possible to fetch > > along > > the header without having to get the rest of the RPM ? > > On the second tough, with the effort needed to extract this > > information out of the rpm, is it really worth to store them there > > in > > the first step ? Over storing an URL (for xml and/or imgs) in the > > RPM > > header ? > > > > Thx for correcting me where I'm wrong. > > > > Just another idea reading this ... could we move the AppStream data > into > subpackage? It is possible and probably even possible to add something like Provides: metainfo-handler() in appstream consumers (e.g. gnome- software) and automatically generate Recommends: (foo-metainfo if metainfo-handler()).. But I'm not sure if * it's worth it * we can add such things with current RPM (because it involves lookup of subpackage which IIRC is possible only to do in RPM code itself now) And as usual, before trying to do something "new" we should really look how our friends are solving such issues (e.g. openSUSE). Unfortunately we do a lot of things without doing so and then end up in bad situations. > > Vít > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmuWsMACgkQaVcUvRu8 X0w6KxAAiOVFG7f91m+sOPJFkRlmx3Minlv1QJobxymv0bdDVDnAdbrBaTGbvY4b GL8D6FocqSMDUBwMxS/2gM2gstEVis5Ho0g2rLcde/fbDBhG4XKd2kdCm2egqMOd g/PFpCxmG9csrI040EaZ7bRYLeeClJPNyC99W3BTN2NOFbTH5/+Y86fu2wLTzuJI rMw1AiSWQLRzwcDvGoK7c5qOOsHiykLYDUGF68hBB2SvQKWqiIBKuOgxJ5v44X1I sMDo6QZq1h0kaYl3ezyXZ9Ssu7QrOfYxmQk+XPF29zz2PY0hyblmUIht536W5JLZ Km3J3N3ksQlP4GVh8WMRUTOiLnT2fYznD4IWhJqPlFcNavwSCebMq+g4VvT8JHPC A13OhbkbEVvDIO/WupiI+/sNmfjLAL4MzrVZS/lV0BNiwHdQis5+tsrJHLm02O/4 ytf8Jw9NzL99GGpaK9TaqxHs2KIyTNTTE1c2bglWyuf7JHuwNNgcOKlTL20gRiJe qcxs3KqhO2zniWLpxnA0zJPzavV8E+mBkB4ODqYUlPgCJy10jrVAJcrpqJreCUBG zrhWncmLxqDfsKCQsbtG4ZmTw/dtvhu+82BTWFCnWxJ/mVcCYyYWQwG403MqMdB7 yV9WgqSDBtoHZsJZvW2UPgm2mfGV+4ATYHICmBnvPYI08cnAvnw= =Yy6i -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2017-09-05 at 08:31 +0200, Nicolas Chauvet wrote: > 2017-09-04 19:20 GMT+02:00 Richard Hughes : > > On 4 September 2017 at 17:56, Neal Gompa > > wrote: > > > It sounds like it would make more sense for createrepo_c to link > > > to > > > the AppStream builder library to handle AppStream metadata > > > processing > > > as part of the createrepo_c repodata generation, wouldn't it? > > > > 100% agree. This does take some time currently (as we have to > > decompress some files from the lzma archives) but this is currently > > done using my AMD Athlon Neo Microserver with spinning rust drives. > > Using something XEONy and SSDy it'd be orders of magnitude faster. > > Are > > we sure that we're using createrepo_c for composes? I know we > > *used* > > to be the old python one for some reason. > > As I understand, the problem with the decompression is that it > fetches > the payload. > And if a rpm weight 100MB, it will downloads (RPMs are often stored > on > nfs, so network is involved) and decompress the whole 100MB > (including > the header, although this last might be uncompressed). > On the opposite, storing information on the RPM header means grabbing > only the first KB out of the whole RPM. It is in Provides, so it is in primary.xml of repodata. So it should be very trivial to filter such RPMs and download only required ones. > > As one can see, this might work for few RPMs, but this doesn't scale > at all on a big whole repository with many arches, specially if the > work from a previous appdata-builder run cannot be cached for a later > updates. > > So I wonder if it would be possible to have a "second payload" with > only the appdata (xml, imgs) that it would be possible to fetch along > the header without having to get the rest of the RPM ? > On the second tough, with the effort needed to extract this > information out of the rpm, is it really worth to store them there in > the first step ? Over storing an URL (for xml and/or imgs) in the RPM > header ? That's probably something what openSUSE does, but I didn't really check so better to ask Neal.. > > Thx for correcting me where I'm wrong. > > -- > - > > Nicolas (kwizart) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmuRzAACgkQaVcUvRu8 X0zKyg//XnDPz5u1RC6jADUgnh2iZynRCWMKUuUmUvqk4a+6JQE5VkaomXpMs06H Swn7F1OY2rGp52UYDbKy92vitfytH6T/SMIgGkqb0A0EOIYlMwDi4BTdUnq0LNkb sm6lP0GNB4FFcChbKgY68frmBAxwZMwJlHthVkRBtjlMM1jKf/1WhK88gxEar7Lm +a6b8X7mOXaFIFf5zAeik6g3XwAcrp0REGaG/m9is8sV/F7gea6vDI9MRFT4G1dz dfGQxT8eYjBP8ldfWF21/7bUDjmLw6qAGvj8ni7mBHOwAXUfNv/dUDcCaJo19g3p GtDdqBOKjN8BH1Rd/7E/aApfqR8AW9qphqDPd9Dz3gJVnZJegxQkHwsTdI45H5Ij Hk8TmZL6qp5egNHWBKhOWy6CmbDB9ebPFDmJeJVe4m09rWQf7EmGyc1jL2XysXKF gKSVsRA54E6iIDneN7KSqhB90lNMifPN4OsCLORbZANBGUggcYOaAwZKg3to/AiM r0G2zLGN8n/oqFCxTvIfjZbPUEZr70vvK5L5zHxwl1W5cQzMyfJep8J6YbZtMuIs jz9YhRdxG9kqInc2YT6lNoIhrp6NvhSbhd+nhQQCMo+LYKBrAIQ8bIKzrj00f92G iRmoI9QnzdhXzvQQyz3v5WACcE1d5U4UuQnsFMWohrBjtWSrJVo= =17U1 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2017-09-04 at 09:25 -0700, Adam Williamson wrote:
> On Fri, 2017-09-01 at 19:01 +0200, Igor Gnatenko wrote:
> > So I think F28/F29 would be best time for retiring YUM. Right now
> > DNF
> > should be already stable and provide same capabilities (or
> > documented
> > that something will not be supported).
> >
> > Hopefully infrastructure / rel-eng folks will finally add support
> > for
> > rich dependencies[0] which would mean that yum will not work in
> > Fedora
> > anyway, so..
> >
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
> > there are no)!
> >
> > P.S. I didn't wrote any Change Proposal yet, want to get feedback
> > first
>
> Pungi still uses yum:
Definitely it does!
>
> [adamw@adam pungi (master)]$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
>
> nothing to commit, working tree clean
> [adamw@adam pungi (master)]$ grep -R yum pungi/
> pungi/arch.py:def tree_arch_to_yum_arch(tree_arch):
> pungi/arch.py:yum_arch = TREE_ARCH_YUM_ARCH_MAP.get(tree_arch,
> tree_arch)
> pungi/arch.py:return yum_arch
> pungi/arch.py:def get_multilib_arch(yum_arch):
> pungi/arch.py:arch_info =
> rpmUtils.arch.getMultiArchInfo(yum_arch)
> pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
> pungi/arch.py:multilib_arch = get_multilib_arch(yum_arch)
> pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
> pungi/arch.py:for arch in rpmUtils.arch.getArchList(yum_arch):
> pungi/multilib.py:def do_multilib(yum_arch, methods, repos, tmpdir,
> logfile):
> pungi/multilib.py:import yum
> pungi/multilib.py:archlist =
> yum.rpmUtils.arch.getArchList(yum_arch)
> pungi/multilib.py:yumbase = yum.YumBase()
> pungi/multilib.py:yumbase.preconf.init_plugins = False
> pungi/multilib.py:yumbase.preconf.root = tmpdir
> pungi/multilib.py:# must run doConfigSetup() before touching
> yumbase.conf
> pungi/multilib.py:yumbase.doConfigSetup(fn="/dev/null")
> pungi/multilib.py:yumbase.conf.cache = False
> pungi/multilib.py:yumbase.conf.cachedir = tmpdir
> pungi/multilib.py:yumbase.conf.exactarch = True
> pungi/multilib.py:yumbase.conf.gpgcheck = False
> pungi/multilib.py:yumbase.conf.logfile = logfile
> pungi/multilib.py:yumbase.conf.plugins = False
> pungi/multilib.py:yumbase.conf.reposdir = []
> pungi/multilib.py:yumbase.verbose_logger.setLevel(logging.ERROR)
> pungi/multilib.py:yumbase.doRepoSetup()
> pungi/multilib.py:yumbase.doTsSetup()
> pungi/multilib.py:yumbase.doRpmDBSetup()
> pungi/multilib.py:yumbase.ts.pushVSFlags((rpm._RPMVSF_NOSIGNATURE
> S|rpm._RPMVSF_NODIGESTS))
> pungi/multilib.py:for repo in yumbase.repos.findRepos("*"):
> pungi/multilib.py:yumbase.add_enable_repo(repo_id,
> baseurls=[baseurl])
> pungi/multilib.py:yumbase.doSackSetup(archlist=archlist)
> pungi/multilib.py:yumbase.doSackFilelistPopulate()
> pungi/multilib.py:for po in sorted(yumbase.pkgSack):
> pungi/multilib.py:help="path or url to yum repo; can be
> specified multiple times",
> pungi/phases/pkgset/sources/source_repos.py:# populate pkgset
> from yum repos
> pungi/phases/osbs.py:config['yum_repourls'] =
> [self._get_repo(compose, variant)]
> pungi/phases/gather/methods/method_deps.py:from pungi.arch import
> tree_arch_to_yum_arch
> pungi/phases/gather/methods/method_deps.py:yum_arch =
> tree_arch_to_yum_arch(arch)
> pungi/phases/gather/methods/method_deps.py:cmd =
> pungi_wrapper.get_pungi_cmd(pungi_conf, destdir=tmp_dir,
> name=variant.uid, selfhosting=selfhosting, fulltree=fulltree,
> arch=yum_arch, full_archlist=True, greedy=greedy_method,
> cache_dir=cache_dir, lookaside_repos=lookaside_repos,
> multilib_methods=multilib_methods)
> pungi/wrappers/comps.py:import yum.comps
> pungi/wrappers/comps.py:self.comps = yum.comps.Comps()
> pungi/wrappers/kojiwrapper.py:# HACK: remove rpmdb and yum
> cache
> pungi/wrappers/kojiwrapper.py:command = "rm -f
> /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; " + command
> pungi/checks.py:("yum-utils", "/usr/bin/createrepo", None),
> pungi/checks.py:("yum-utils", "/usr/bin/mergerepo", None),
> pungi/checks.py:("yum-utils", "/usr/bin/repoquery", None),
> pungi/config.py:import yum
> pungi/config.py:self.set('pungi', 'arch',
> yum.
Re: GnuPG 2.2.0 and replacement of GnuPG1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-09-04 at 18:15 +0200, Till Maas wrote: > On Sun, Sep 03, 2017 at 01:45:40PM +0200, Igor Gnatenko wrote: > > GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat > > symlink > > from /usr/bin/gpg to /usr/bin/gpg2.. > > > > Is it time to retire gnupg (v1) ? > > It would be great if we could make gpg2 as the default (add symlink > from > /usr/bin/gpg to /usr/bin/gpg2) and move gpg1 to /usr/bin/gpg1. Debian > beat us to this. I was also thinking about proposing this as a new > Systemwide Change. Would you be willing to co-own this feature with > me? Sure! Let's talk over IRC one day and agree on further steps 😉 > > Kind regards > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmtnREACgkQaVcUvRu8 X0xnNg/+KHZn17qIUByj7IJ32llVH/97CdTpp96MNy4UjtBAUuCBoh3sl1m9THZj ZEUNjRV0H3FpgG65DAQf4cUGJLU1S/o1iGeczaiv1vsd1EC7MHwbo3LSnddSeXPh etXzJqwpAR9vCGfICf0/3UnUmep1BJrNlztPWp8v3m4WWwE+/XoCbRRwugTCxxmy NhUV+EHa2TVRCwtWqDwm7bOfh4KiK3XOZiktryUFnySOTBku4i2damU6jpdKiaME 2t5093Os66RtqFTAEh+XaK5gyuTjaQ27qUomMDHj87YFxx6e1jJ7+vJ3nEPxvFqs YNlnSTor7H75IdeXquUwkbViJ90RVi0r9LSS6hmk/THRmWnDvcvDnXgT8+b1RnTd h0rMaaXG/dMtwbdf4QCKZekbT6emzZyCt8HyzkkIkG0KqOwWlT84atOFpazsb7VD ownPplLaeDuCkjwkjaamXfFkrBDuO+C5LVFQ01J0fLdCvzikXHskxlX+JtLLZByg lhGZNBrYhWmyhQIp9o9lEmQRsVdHeOLRke7vMDVHVryD0XgRpb3jAFsvIbJ65RoA SoAT9XHGYEynfLNFizhBMdFWcHfX6b8yNFV7VbODfUHe2TnieMc1oBYLwqEqF1CI IBtChqxsUR8/DjdglFGkjJLNZqnLWpfqb1atvlGym6ImR0FpKg0= =CkjG -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Verifying sources against gpg signature during RPM build ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-09-04 at 11:29 +0100, Daniel P. Berrange wrote: > A number of packages that I maintain have GPG signatures provided > alongside > the sources for new releases. Is there any best pratice approach / > RPM macro > magic for verifying the GPG signature of sources during build, or are > packagers just (re)inventing the wheel each time ? There is some draft[0] available, but I can't find FPC ticket on it. > > 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 :| > [0] https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatures - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmtNhAACgkQaVcUvRu8 X0zULg/+NFtXY54w+MEmkv8OHCyXvHnyMhJWKLYnNIncs7pwBuVWWS6ZbxfcbEXC 7r+lKlhRmMEDbnmW8P4lzSzfNh3njiq8MH23w6DT6m9bbh+UeSYoZ49lFoARM63X ltNtcHd53h8+8CcX7I5WdlWY48wqwZZU/qYU7pE0ZvyPrt0l53IFGujjUw76bDdm H0VyM1F4tVW0Tae+uIwtK1woQEN4uGigHBR3KYatEi/xdKnCEriWL2gS7IZrn3Ek vddr7hXaNWuUid79SxsYvA6Q4gpEBLlRrCpeTVCJgTZhY9bIkghfid4p3ZA022sS TZAVvwYGC94DOePTOvxERZLp1wNZzxQRXBGdxMryVwetZK+d+qHc+Bb+owx7fTVg WBLTnp48G/KCLWiVyV817fq/S8Nn/jqucF3ool3k91DDD4McNFYGqigqflYe41jy 9hLP6Pzb7RCxR2Nk+pZrfe8Zwk6DRO3Y6sZuFQTBVgxyxinIaEQ+kXOreW6wXi7J mgvJ0QD4X8+i5++yMFPBau5PQxdojJm/rzYLm9ePJsUdS/vg0tx2sLUh2YVwsbC9 rRlLN7ziegv7YCJK1uDi60QwOzRLgRWwKUVhj5MNKPlUMXaepOFj3nt66j+jBD/U Be18rCG6vJAR4796Gziy8a+ueu2rN3F+QiIYvm9EtuWz/DZzwP0= =Epz5 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
GnuPG 2.2.0 and replacement of GnuPG1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat symlink from /usr/bin/gpg to /usr/bin/gpg2.. Is it time to retire gnupg (v1) ? - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmr62QACgkQaVcUvRu8 X0wFIhAAtq6sNg1Xi7tL0s6GpMaC12T5iHg6ijRa1a+Mh8dca1yE4MnWYsrdEW9t B6iTRnNgSeMwcBpwfYpzaA+NMDe0DvpK23VKQLPWy7DnO8TZKDODTedMJKZtZ5pf xcUo4LQLZ5P2wMDudzSFyRHU/ZA8CwYHhPL4UL515+z8eCjI3Lcl0jR7QmJnUbtG pUW0wZGe0ToW9shasVm2DAqAK51VI6GDruDd56a/tXSnla7difB9mxJkN1hUAvgo 1HWrjGlhgkL+X/FT6uUbMnel0IClpo8lnmppq0kbfQVygN+jqsXqJ2xlnuUUtmlH FX87iOaDuieTS4qHkCqrH0yerE6CNZLnTKOTdpv6ThzMbtTJaP5+3YLaINgpzVbm o38BTy/SumwbQRd53N8gttKa4KZYvdDcVBKJBLTsYE+KQFpawMn3b17znPqBGMYp Yx5IqWED1uXJ/pT9oHxDG9zN+xaPVAJkChvi6Z0tdvpJoqiNqjjQbypoRRXl/zKj R/ll3ag9MJ2u+2Ah1g9glSoIInx9KCSDHjrT4674PRdms3+1onyK2NkCgzJIfHPa z+kkECbmyDf1BYQWLYohAKhNzi0U6ghaaFcy9iZ2B8PYysVGTSM6kJ4RWks4mG8G RKDHrx+Ebs77My8jH/tqH2Uv8Z9RJFJGaLwJJ2xpIN+qAv5k5Lg= =kUyQ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote: > On 09/01/2017 12:01 PM, Igor Gnatenko wrote: > > Do you still have some critical missing functionality in DNF? And > > let > > us know reasons why would you like to keep YUM available (hopefully > > there are no)! > > AFAIK there is still no way to get dependency information out of DNF. > (There may be a way to do it, but --verbose certainly doesn't.) This is true and we have plans to implement this, but problem is that we don't know how to represent data. When it is about installing some packages -- it's more or less easy to show, but when upgrades / downgrades are involved it becomes way more complicated. If you have some actual suggestions -- feel free to contact me off list or post them here. ☺ > > -- > = > === > Ian Pilcher arequipeno@gmail. > com > "I grew up before Mark Zuckerberg invented friendship" --- > - > = > === > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpsygACgkQaVcUvRu8 X0ylbg//SywF5N1LbGWkWg92QfyIW+0sylYNOOLrFnhtRTOQNy1YGOp+1vmTEtU4 5ocM7EjIjoXjlfOMOuhw5EA1bfozdSRiwgnCxrBpxZGRK1UxBuNGcmvN72jd7v+d jDgKsHpYj5HDNwkN6YvqX5YUaUCO0ij2Btq147nZ2dejfQisxsg4+a6Di6gz2JhX 2nk3rd7BBZ0K9l+pX2qQM1QUW4+YBQAEIDpbX8Vy7Y+HA0GDmiTx2cVhjLUhGLqh DSf01bYsQrrYU/lR0/yuPrQ5bq6r7mxIPo1q31AU4mvL2pcmLsa2ZC33O/cyUg6M DQ8TKglFTvbyKeE5Yt1ocvaIL2rBELq0r7Sr10SWTxz0+Z5HUq6PNSvGsSAV7F2K UOtF/Hy0wvCKEi0fhdeZ7inDLRib7JuyM/O5qPzJU1sW6sO17eHPffxyCMXdiCxj ScrJseCE3XLFLp5Z3kxA33iOpT5jQZW+yFqFWVKPE21r4FwQCECzYyMDShfoNYCy RqKZP6rSJu7yBBApcH9Dv1ri23n7eSC5jF+5dKoWwbQ2mbMbuLXf4gkyY2x8C0ZD 4fGzipentKhZZKgqxWEFSLDy8337tWGwH+eJOx/8adomNLiXev7BSD3wBHfOsjkn kxHq+8Y+PG/HodZKzsvW37g1V+ELcFfIyxmp/2vC1WouG9Xltx8= =rUQv -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 13:56 -0400, Neal Gompa wrote: > On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > So I think F28/F29 would be best time for retiring YUM. Right now > > DNF > > should be already stable and provide same capabilities (or > > documented > > that something will not be supported). > > > > Hopefully infrastructure / rel-eng folks will finally add support > > for > > rich dependencies[0] which would mean that yum will not work in > > Fedora > > anyway, so.. > > > > Do you still have some critical missing functionality in DNF? And > > let > > us know reasons why would you like to keep YUM available (hopefully > > there are no)! > > > > There is still one thing I've noticed we're missing: API and CLI for > getting package changelogs[1]. This exists in yum but doesn't in dnf. While I agree that this is missing functionality, being honest I think we should educate users to use updateinfo which is meant for users while changelogs might be interested only for developers. Updateinfo is coming from what is written in bodhi. > > In addition, don't we still need yum in the repositories for mock to > target EL6 and EL7 for EPEL? I don't think so, but better to ask developers of mock. > > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs > are > blocked by this bug) > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpsrwACgkQaVcUvRu8 X0yZghAAt1HXXwvgEsYMWYBbCv2wXLwt3tRvdet+FfX+qZFnl0ikdg0wtHdXKzay Ruw5ZKxM5zlIQAEwuBOrNnAOtBFceEo+3JOx65h18LitCALPeWcDhB2H8c6/QlrU kaYtgy6vt7JBntN1KnmGpqv1e2ax4R6f6hXQx+9Is+AmlkU30j/d750NNP/bnL4T X1uN6jU0MS5QYaGvCHxF5vhw16IrQXiJGz/r/LEiYw4Djjur23gOnV32mRVvIcmN +NdpqjOSZXylIO0gKZLIt5BFTAowvakERUp8MVLoacR5RQtjTAucaBcFmjyKBMbe Hq2xq21QXVGqZMh+CK+yjVwyjmiYU9Wmy5yvDyXMy292JBuw1wombEr1DdOGE38i pdSS7gaB5YKLyifRST4+yA9fuhi9gMuNkugKvz8bm4+2tKU88II6COYFwoWVOMHT JKY2l6TKJGY+a+6KYr3vQcTS0AiGI9WjsYZIjpNWanAe7e5B/RdBFgyX/S6j6D3a 3pPc7rUI9J2QZkrKyM/1VDn8zlzfV1DumfsNy+LjfHTohSOADuR6FO3th75f2FP6 gRJbl6EBY0V6ynW+GLn4jlxxxofxYzuVX22G/xyPoPHaklHy0/LrH0GbV4y4EnYN vkEr/BEywW/VmkhWHDKPT6gsnANn4r24TzTdmj60jxfAED3bLpI= =qmL2 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So I think F28/F29 would be best time for retiring YUM. Right now DNF should be already stable and provide same capabilities (or documented that something will not be supported). Hopefully infrastructure / rel-eng folks will finally add support for rich dependencies[0] which would mean that yum will not work in Fedora anyway, so.. Do you still have some critical missing functionality in DNF? And let us know reasons why would you like to keep YUM available (hopefully there are no)! P.S. I didn't wrote any Change Proposal yet, want to get feedback first [0] https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_ and_libraries - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpkn0ACgkQaVcUvRu8 X0y2zA/+O5rG2QGHdoZOsQhE5H8Q5MRpdO3jQxgqC9+atQtV0MWNkmkxyPCbY2no smHeOaW8OjqvjhN+JuzaWDpjZY/aFmnVijnpCBLtx5sNKNLuz4VPN66ZK6wVLT5j Nst0BiUglXJxIj32NswyQ+jNl7iFuFUWUrVlUNFYP3YiURvCRd/B/l2XHWDtkH0M GUWTARf5a0LSXPxpbwQ/g+jkstbie3CIQe5nlw7oiCJgYPwoY2VuIvo1l/Uvn2My 6Ip3NiZwlihJ3x5iM3bisdCYW7+c0/rMV6IFGV4J94/3Rl1U3kzGsI5SVW/An2mf s3xNP2EutZsccFrudromFvYE6BeWwMr2BVb+fMzt9S9zEIKZvx9IMQgZMgqR7IPH 3t6P1R5WD3o0q4I+vOc0IPtyqHnqKAVE/6tMr9mqQP4PBswa1uyhLeravDAGTHYC XvyU6Y3ONmZA1I75Pb2tbVNBlpPB2QZGGf46ayTi2i0Jb6/ctoda5Lbpc/2iD3Be /e/f3yxHQHgQFSkwAkz2K4INuSf7lpIB3uQEnVhJRk8+75nvKvxNRwW5vEMOs50Q DVjKI8BRW02K4BjU7FnBNjezv/2A/ygIU4swQ3/0E/CKQ0LG2CWY2sgAqEutEpz2 kmarL+xaZAD1QA7ohqMbQeMFkIdK1hy2JAkxWdYUgWHBeRr7rIo= =ImZb -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Providing ABI/API assurances for the base runtime in Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 09:28 -0500, Carlos O'Donell wrote: > Fedora Developers, > > I am working on a way to provide concrete ABI/API assurances for > parts of the base runtime. Note that Base Runtime is F26-only thing and in F27 it is called Host and Platform[0].. > > I've written up some of the key ideas here: > https://fedoraproject.org/wiki/BaseRuntimeInterface > > Any feedback would be appreciated, including bikeshed on component > name prefix for frozen interface pakcages e.g. base-*. Why do we need separate components? Can't we adjust main packages to install into separate paths? In theory, it should be just setting differeng %_prefix variable for RPM. Another thing to mention is that libabigail currently (as far as I know) doesn't handle python code/python extensions (read DNF). Also I guess it doesn't handle GObject Introspected code. > > -- > Cheers, > Carlos. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org [0]https://fedoraproject.org/wiki/Changes/Host_and_Platform - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpdhIACgkQaVcUvRu8 X0wBoBAApfw/InR9lDuN1uQ3vdU2FlShLUfbUt21PweLrfXHIl4rM6IOh4TpTkce E/A0Uyc4cMdJdROrP3T9yZhaH5D9wo5z0gimM1hF/KeOFRC3yg8iSmhCgeAw4QxV F1wFYjBcinq8bb282BgF6rRLusWSGh03gWn80NImBByZA0F1eYHpPsvBCwOMG6Vg ZfHa0g+mZb8yP5bElgUSyRpSqFGFlp6aRdTwpIafIXUJ+hy2rsrxjPDn95O66TOf OJKSpMR20lCqeWdLPGuGXuJvYbAMkYuKZbQZAowzs+Q4Sc8RYKFty6bYGFNcpMSC oN65nDDNFqWZzhA9UuFWPgCBvbG91WarfwiAix8w2PXygklbSbcFNmjOaedJc3gH RJ83n8i3Yi6+AS0Ru0ZfZ58afq+88jtypy4dW6qRGKgfaHckf61/4cxa8iXS03nY kILkdSmrM7Abcy9Z51cAA5h5jM54+IiYsqZfPhIDeBxrAIaR++K8llVP/6azMIwf fw47Va8t0DkXNgpt4NsKk68Vgx6yAp9W0W449e9xVz5ZDCjOkZtTvsfQABByfPfk cm2ByUhgrfRyp0N/R7MYX2e+C3fC2lbdJmbSTQ5Xmno0RktrWu50GRW2h+CV3AUp Xs2wTyJbn8Aq18wha6/dk3n7EtY7IS+DuYGB1fFibTnKzHAw9p4= =6/Bf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote: > Neal Gompa writes: > > > Implement your AppStream filter at the application level, rather > > than > > messing with appstream-data package. > > Yes, of course. Cockpit will do the right thing even with the full > appstream-data package. This is only about not having 15 MiB of > useless > data installed. Just check how much data you download for repository metadata.. 😉 > > I have no strong opinion either way. Not splitting the package is of > course the easiest and cleanest thing to do. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpXmYACgkQaVcUvRu8 X0zSDA//Si4mA9/0aGRxrM+iHPVEFEjWiIXR8ImGNkBf6oovKR2ED+RZj95HfVxZ EVBZ5qTHe71SW3cjaq0o2RXsoBNN6uhrZ54R5b+MwaYG4Ong2JmvqDW98EbT/Vx0 tiIbW9TMi/7D+s087gthTj2QTsj5CoNM8dwOAaAIW8o8va0kLZXFQg+7A2WmToq5 oFj3yXQJoPYtDkUJ50OK4cvgW71Zpe5TT1Z4aOZggWsZZNJ8+4cU9FicNS9kHAq+ 2bpEnEOyPaKMF8UMKtysXqknDIoAigtwkatpcFNx9VNA0R7z6kIvIyThotxbogyI CHwEFapg+M0YiP7/pFNyNF/uxYqoS3sXlK40g9C4Lw0d8DSpJWiAPUyQSDVSoq2n mKtEcQ+tKwpVssnv+B4sDdGEfsH/IrcFIz5NyIEgzO/kdMdq9R0Vko3Vce2BLPQT Qkjbe+uXuYGTd/nuCuLG63AXVVrK704d1KssP5qZGSY/MyF41eGIihRbkM/tP3gV yD5hbkWM0/PTc8XVqBZcIZuWh+yIqfsUw9qgWkUa/0ABZ+u46f0ubU/5MSHsxq/X HKUg7aaI9g4sWduk5bC4Yl6pYiJKfWMcB61VoJAEfnAPV4RrJq4me6w6cyzDMoGs YZ8cFm+eJ9a0lYaxpn6DkUZuj1v6MW2RYhIkTYOgTb4ox/0QplU= =fmJm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
e (and > it's _way_ faster than it was several years ago). From a contributor > perspective, https://src.fedoraproject.org/ seems adequate if not yet > perfect. The ability to display readme files _alone_ seems like a big > step forward. It'd be nice to have better search and browsing, but > the > original pkgdb web UI wasn't great there _either_. Honestly, I was always impatient on waiting pagure-dist-git deployment! I always wanted to send PRs instead of attaching patches in bugzilla. I think this should bring more contributions from people.. Just my 5 Kč. > > > Modularity > == > > Yes, there's a lot of prototyping and reworking. Some of this may > fail. > But that's how it should be — it's really not possible to have > innovation without trying some unsure paths. If you want to try other > paths that help us solve some of the same problems, I'll support > experimenting with them too. > > On your specific complaint about DNF not distinguishing between rpms > and modules, you're definitely not alone; the Boltron feedback > overwhelming tilted that way. See earlier thread on topic — and as I > said in that thread, I think it makes most sense to treat modules > like > "super comps groups" (with either a superset of existing groups > syntax > and reuse of @, or simply a different syntax). In any case, this > feedback _is_ important and _is_ listened to. Can we finally kill this comps stuff please? > > I do want to _strongly_ stress, though, that the point of modularity > isn't to avoid parallel installability. That's a separate problem. > > Modularity will allowing *us* at the packaging end to separate source > and spec lifecycle from binary and artifact lifecycle. And, it will > also allow those of us working on assembling spins and more options — > for example, we can have different streams for Atomic without needing > to actually duplicate every package. (And we could do the same for > KDE > or whatever other artifacts would benefit from that, if we want.) You could have one branch and buildsystem would build it against all "distributions", why to invent new thing? Which also involves new data format and additional maintenance. I see way bigger problems in Fedora than this, tbh. > > And that's not even with doing arbitrary branching for individual > packages. If everything works out successfully with _that_, it will > eventually make _less_ work for packagers. Right now, I have a > package > which I maintain for F25, F26, Rawhide, EPEL6, and EPEL7. There's no > difference in any of the versions and no real reason to keep them > separated; in the future, I will be able to have just one branch that > goes to all of them. Or I could have a "stable" and "experimental" > branch that people could choose from regardless of the base. This can > benefit *way* more packages than simply leaf desktop applications. > > Will we get there? I don't know! It's new and different and > definitely > scary. But... it's also worth trying. It's definitely worth trying! > > In the meantime, if you're a packager who doesn't care about any of > this, until modularity can demonstrate real success and advantages, > you > can _continue_ to not care. Modules are going to be drawn from f27 > (and > I expect f28) streams which will act as always, and even if Fedora > Modular Server is a success, I expect we'll also provide a minimal > install from which a traditional Fedora-based server can be built for > a > good long time. That's not true 😉 I'm maintainer of gpgme and I've got forced to apply some patches related to Platform Python stack (which is one of modularity changes). You underestimate how Modularity affects distribution. > > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmhhL4ACgkQaVcUvRu8 X0xW1A/+POBWoiTO1XNOLDXxWBfj+v2wa856Yesi4omsHm5duGlXXSYUBwVTZuhQ gYzwETE9hr+DZbdVBnaZp0i36D8ZN6c9JpGlhiqh+XLlQdZwbDbpe4uq0vAAr9tP AwwUWt2Oinz9qDDhswtK5fDNCpQNykRArWmE74KYSddfEaiOdHAOJ/jilAMZynQF bMPuM0k55jAYh4k+3B4tk0SdzSh0PbPQ2E46V9AcYiqiQO19he7gxMVjq6McSTdL 0NQorFPHwTCcej5ntKPpoU5VZF4TQi3jychVec2HRQSJ68jRSe4yPRIDTYw8jwsu ViDnqvGc4V0PsDa/xPLZUoN2imemxYSp9VUnN8kxJHYn3QMAwbHqmPpoFCLFgC+z OsTeHMFAsYHce7x0tYeUr/M3NZWTTnUeUhzvFp9t7e9ti4UNoCOIImbizc9/ZQRy 5A4D/tZP8CvvdKdPeKm11AXy/EhzCoIUeVoqF869SG6nZCg5yIJ3WX6B4ATVZc4Y Mq29VUF+POZKyEzgsIVPgqMyZDHqCg9n0bNtg171oTtocdauGj/mFp9iO8YoBDIx 3gTcfX3Wnb6AezClaOZwASPKWG2STXQgjLXlHOg4fov/fA4IrPW0lUP2mos8DvUl J4VhkRXMZTynKnZ7T9TIJ4T6PmalJcxFvpMAnAHscCKw9Obi69A= =Xj7A -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2017-08-26 at 15:13 +0200, Emmanuel Seyman wrote: > * Matthew Miller [25/08/2017 16:23] : > > > > From a user perspective, > > https://apps.fedoraproject.org/packages/ works very well for me > > (and > > it's _way_ faster than it was several years ago). > > I would agree if it wasn't for packages' issue #286 > > I suspect that packages uses pkgdb to get the information it displays > so arguing that the former can replace the latter after its > retirement > seems misguided. > > > From a > > contributor > > perspective, https://src.fedoraproject.org/ seems adequate if not > > yet > > perfect. The ability to display readme files _alone_ seems like a > > big > > step forward. It'd be nice to have better search and browsing, but > > the > > original pkgdb web UI wasn't great there _either_. > > It's still has a number of critical issues (#6208 is the biggest one > that comes to me). > > I think Neal's point is that we knew this was coming. We knew that > pkgdb retirement would be half-baked before it happenned. We even > discussed it on this very list. Couldn't we have delayed the pkgdb > retirement until it had less issues? Can we learn from this change > and ensure future changes are handled better? I share most of Neal's feelings, I don't particularly think that replacing pkgdb with pagure was bad idea even it was not completely ready. We are not able to predict everything what would break if we change / replace piece X. puiterwijk, pingou and others are very responsive and fixing every issues are coming up, this is awesome! While I don't like how modularity does things and stuff like that, I try to help as much as I can.. What I don't like and get frustrated is that modularity is forced a lot and we get huge changes in infrastructure and a lot of other pieces, but when we ask for way smaller changes (supporting rich dependencies), everyone hides (definitely there are exceptions)... For more than half year we are trying to get answers, Rust Packaging got delayed by 2 releases already .. And only now, something is starting to happen (after Flock). That's my main frustration with modularity (it can be replaced with anything else what would be forced so much in Fedora while ignoring other stuff). What I am trying to say, doing changes (even they are not fully prepared) is fine, but completely ignoring people who want to make some changes which affect infrastructure while doing even bigger and less prepared changes is bad. > > Emmanuel > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmhgPgACgkQaVcUvRu8 X0w3BBAAhSwbCN67O87K6bhmt96Do2hZ7YY6uaue4i+C4g5b2m+2Xf7A8m3XL9C1 xfR/RZMJnar+a1VHhCbbGROZmLTElgKDsWZOAaCFYIdAkOLbuRoUkM/EfMqE0OUr FjjHH7Uyuxye7KrbiUihjETw0yzVeX3tDWWusgla35PA+RqQe1Z5E+VM6DvL4pFY 953LIwfoA+ReMDKKpwFJatVgTyzNHjx+Co1xpMOIgrgnkkCFWwIK5JYkvRQo31uh zkb7c1Li5Up6wh0lW04morvqp8FVq2G6O/cN/RihT1n8jvztCFP7kYFmRaVNtOKW YwqS6hB+xY5ZogjkmdVkZLDApzEAD/NU4pE/IOhwChTmUFqXSktlveKQHSmS4aLa JwJrHjFpVZ3lxHxDu8ctahfmjMV2XpmaeE8H0d/0cq3y/UhI7WwFnAByOFPYWTwe aGJ1zB9spS+JywwGXs1l5KufQ8l0SSbqELHwglUg2LnqQsRoJOJvh72GfcS2rFCm GJn93ZUNkmVvAghcp9GxfUh3x8nzv4e9mFxTHD4D4duOotC/ggaqHulAJ4vQdXOx Vg+rubv0GFt1tYDeR4JyaC05ZjbB5RSgCRnQIdA9M6J3vvEvG7vPaF9cZyyPLugK xBgghEKHhn8ok72nnzHMlY6gCk+czwaruLA9AdOVUmHkmUEsfcg= =240I -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: About "debugsource" package and repo layout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-08-24 at 17:04 +0200, Remi Collet wrote: > Hi, > > Since F27, for each package, we have a "debugsource" package. > > Question is about the repository layout > > For now these packages are available in the standard repository > > Ex: > http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Ever > ything/x86_64/os/Packages/y/ > > yajl-2.1.0-8.fc27.x86_64.rpm > yajl-debugsource-2.1.0-8.fc27.x86_64.rpm > yajl-devel-2.1.0-8.fc27.x86_64.rpm > > Shouldn't these packages be in the "debug" repository > > ie: > http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Ever > ything/x86_64/debug/tree/Packages/y/ > > yajl-debuginfo-2.1.0-8.fc27.x86_64.rpm > > > Definitely you are right and those should be there, check: - - https://pagure.io/pungi/issue/684 - - https://pagure.io/koji/pull-request/524 Unfortunately, I think those fixes are still not deployed.. > > Remi > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlme7sAACgkQaVcUvRu8 X0zOzQ//dk9MEgqEkcyX1qfacjXLUmXyiBdUvpNaUMMAp4NyxYqNWWXuQPHpfboM 3ImqnLCBrac2hupA3PlPtRibFIcUKZIMzWf9IIhmyLEhgb9r8ltSY/zfRnALss6B PgrMHl5y0/9nK/nz7Lb66hpcL6nDmRlna+kfdftbDjcMgwN3TyqFmmGFzykT7tjN ZuIWI5F9QwXNOCvY7OvA8M1zCi+29Fvgo4hzNMDO+dAG+kwRyB+S3ImZ1EQcJXmB PghnuSScDBND22Ys7R8VYm3ZJpspV5g9eH+DERgW13k4GAwHhSzumzVX4raPptco DtPqLqkAp0hG7MnCmk3aR5WiW3DND2qPsCgwlF0ROqeUgFIc4NdNDMixypC58zoQ MciWkgSK9DyEaLlk9V/XoHFfUMUZloLGM4WM9yYUF9gmZWy6x/g9NlqhLd7+A3Vt Rso+KP5wcbzFj8S1UuOhU0lfpatX+wjmQzU6rxgmn91toOYiJ9deQ63DpVlul2cC xFRwebTUBQVz+HNhX15E73rAwpO2aRxrQAlwlYFbXFqdrFbg6Tp7rhlv1Q6xBGcI RH/9JkxqVFlnJWdlxTv+0ao/f1BJKPjtlBRju4lqjjQLpUNA2tV6AI1SFhUDD7Di 7VFeJ1JjVkWk7BrE5RrgdC/8uG81Kmy4z0w/UoNdVB/0QXLE4q0= =r1I4 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cleaning up the test-* namespaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2017-08-23 at 20:43 +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > A while ago we had the question about including tests in dist-git. We > considered > two options: > - Have the tests in the same git repos as the files to generate the > artifact > - Have the tests in a separate namespace test- > > While we weren't quite sure what was the best approach, we put in > place a > mechanism to automatically create the project in the test-* namespace > when it > was created in the regular namespace and using the same ACLs. > > To be more concrete, we had the mechanism that was creating for every > repository > in the `rpms` namespace a corresponding repository in the `test-rpms` > namespace > with the same maintainers and ACLs. > > The recent work going on around CI [1] has led to the decision that > tests stored > in dist-git will be held in the same git repository as the spec files > (for rpms). > > Now some numbers: > * We have currently 43663 repositories in dist-git > grep 'repo ' gitolite.conf |wc -l > 43663 > * 20843 of them correspond to the test-* namespaces > grep 'repo test-' gitolite.conf |wc -l > 20843 > * Leaving 22820 repositories not in the test-* namespaces > grep 'repo ' gitolite.conf |grep -v 'repo test-' |wc -l > 22820 > (I double checked, 20843+22820=43663 so we're good there) > > I would like to get ride of the test-* namespaces. Tim Flink for > which we > originally added this mechanism agrees with it. We also have backups > in case there > is something needed from there sometime in the future. > > Before I do so, I would like to know if anyone is opposed to this > idea of > removing the test-* namespaces from dist-git? I only support this decision! 😉 IMO all tests should live either in rpms/$pkg or module/$module repos, it doesn't make any sense to keep tests out. This also complicates life when you update package and you want to change test at the same time. > > > Thanks in advance for your help, > Pierre > > [1] http://fedoraproject.org/wiki/CI > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-leave@lists.fedoraproj > ect.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmedcsACgkQaVcUvRu8 X0zOURAApOEsrxpY6fM8E9zn8pwayLgGhdYp8YIGOLqcb+whxJbHPazsuX7m2108 YHFC3akTCloMGA8NkgaGYs/2m2XqbPYt5JXZqxV5O75NVKyWORqHac4c8oUDRJ17 PRlq+NqQY3Z6XbY9p76MZnYvyGTmUxWahBbMmLqU8/vVrdVlWJ1k5YcC099OR6GX We1FEI/f/tPEJD5X0tNuO8lBZBzpZDnV30L2hDws/R4m1G6vNc1LF29qREZSzL25 WnGXbHn5FHsF4Iy4+dFV4U2PZ47n9XSTprquAqEsKTw7JwP3Re1+kuE986NTe//a eoJ2dCelSkXwIzyav2alNjznoSsXeTHF8fUiQwK9UlDqVOZZ0zkOUNVEQu/ZyJ+d xXiRV3II95NTplki/Z1iAahzlte/eFmRXC5RTO23mrMMk5oOuVaO+/k3Gl4Pg5Vl pMoUaBuItwOPu/d0daaByhI2IKBsAU2rXfpteP4qRxJWmvFZvIf1IU1882oHOvy9 oPYDSm22omshwSn8NbEtfwUeLBpSCAJlRJBgvIMR3Fnw5Ux+5j8c+vZwqzQRnt6Q IAvXlSQ6nA3SrDtXrke5aVN/tfsfhRJsO6mpe0qGn4iiVK88Ow1DOnwBpbzzhLgm ev//qCjq/8zFX0kzuBmkI/HPGJAq+m+GQKjmqVouJDytF0EMycE= =CqNk -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2017-08-07 at 09:42 +, Artur Iwicki wrote:
> I maintain a package written in Pascal, which uses fpc for compiling.
> I noticed that recently, koji builds started failing on i686 and
> armv7hl due to the find-debuginfo script failing to, well, extract
> the debuginfo.
It is problem of FPC, see
https://bugzilla.redhat.com/show_bug.cgi?id=1475223.
>
> Here's a link to a failed koji build (mass-rebuild by releng):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20981009
>
> On x86_64 and ppc64, the package builds fine. On i686 and armv7hl,
> this happens:
> > extracting debug info from /builddir/build/BUILDROOT/colorful-1.3-
> > 3.fc27.arm/usr/bin/colorful
> > Stabs debuginfo not supported: /builddir/build/BUILDROOT/colorful-
> > 1.3-3.fc27.arm/usr/bin/colorful
> > gdb-add-index: No index was created for
> > /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> > gdb-add-index: [Was there no debuginfo? Was there already an
> > index?]
>
> [ snip ]
> > RPM build errors:
> > error: Empty %files file /builddir/build/BUILD/LD25-
> > e5ecbe39b719f12a1268bcc641eae9ba364221c9/debugsourcefiles.list
>
> I thought this may be a bug with the package, but then I saw that
> koji builds for a new fpc-compiled package that I've been working on
> lately (not yet submitted for review) suffer the same problem. This
> one is worse, even, since find-debuginfo fails with a coredump. https
> ://koji.fedoraproject.org/koji/taskinfo?taskID=21087076
> > extracting debug info from /builddir/build/BUILDROOT/peazip-6.4.1-
> > 3.fc27.i386/usr/bin/peazip-qt
> > extracting debug info from /builddir/build/BUILDROOT/peazip-6.4.1-
> > 3.fc27.i386/usr/bin/peazip-gtk
> > Stabs debuginfo not supported: /builddir/build/BUILDROOT/peazip-
> > 6.4.1-3.fc27.i386/usr/bin/peazip-qt
> > Stabs debuginfo not supported: /builddir/build/BUILDROOT/peazip-
> > 6.4.1-3.fc27.i386/usr/bin/peazip-gtk
> > dwz: dwz.c:1984: checksum_die: Assertion `((!op_multifile &&
> > !rd_multifile && !fi_multifile) || cu != die_cu (ref)) &&
> > (!op_multifile || cu->cu_chunk == die_cu (ref)->cu_chunk)' failed.
> > /usr/lib/rpm/find-debuginfo.sh: line 518: 8822
> > Aborted (core dumped) dwz $dwz_opts ${dwz_files[@]}
>
> I checked the build & updates status for fpc and there haven't been
> any updates to the package lately, so this definitely isn't a
> regression in the compiler.
> Have there been any recent changes to find-debuginfo that may be
> causing this?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
- --
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmIR94ACgkQaVcUvRu8
X0yHixAArM9Gq0tGi5pcCIS7RszqMou571yGeQHSRS4ujEnO4DR9VlBJZJhfn1ko
ldLbX3n5rSAeZ45dCCPtJBmTcJUItMw57cSf1I8sbHDBN/GreDBdhojULySSLAqQ
VaPOoZUrptJqoUNQDECVAoULn0bef7rnCUchONTbvhtza6BjKp6kHJst54uHInxB
HxGjAUJKlpiGV0v0GQx6JgjCLdwUZg+AmSZZ7CiEWHiKCwI2XFgROEIX933gZdet
wTQDqIZ4TkySGKZ0N3yb5h/Sl8lnAvAolmTEUThOVRZgwo5ySyfSYh5yEr8emwjq
H3r6c7O8GCv8gtDrdPYYFhkywa+zN6xY4XWwPJiwU7ClKyxYl9ZcLUnhpBJznTpn
vQwe/a2s5yPxpxvR+GCP86wg1ZqYAK/8Brx/4ohEy6dCYu0T3agH++ah5w3S2qCh
to13zJo8b2M4GfmIwYEmfmt+aL1BEIpOjuU+nncFL+dhYS0uJHw6BClPiLj4BMEY
Kl1tR6P+WK7WOfdAo2iAwXaXCvmqv9idVx06o1b5yFh1CZtq0ivzw1rYHuVv3OBQ
OcmPxJ9OPTNYO806sZ/WmUCbN5lerNfkPBL8la+8FLpOHkLplQvRmpWzWxYVcL8k
DkQvXWtckzykTHvmBJWmR8OBX3sgikvdqJK9yd9toXAYssVFbHM=
=sSy9
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM dependency generator picks up shbang lines in /usr/share/doc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2017-07-30 at 17:07 +0200, Florian Weimer wrote: > highlight-3.36-3.fc27 suddenly has a Requires: /bin/lua: > > $ rpm -qp --requires > https://kojipkgs.fedoraproject.org//packages/highlight/3.39/1.fc27/x8 > 6_64/highlight-3.39-1.fc27.x86_64.rpm > /bin/lua > config(highlight) = 3.39-1.fc27 > libc.so.6()(64bit) > … > > I have verified that this comes from the > /usr/share/doc/highlight/examples/json/theme2json.lua file installed > by > the package. > > The immediate result is that highlight is uninstallable because > nothing > provides /bin/lua. We could patch the example file to use > #!/usr/bin/lua instead, but IMHO it's not reasonable that a mere > example > in the documentation introduces a hard dependency. > > Is this the expected behavior? Shall I file a bug against rpm? This is expected 😉 But if you think it is wrong, you are welcomed t o open a bug. I can't find guidelines about this now, but we have something about removal of executable flag on documentation so no dependencies are generated or something similar.. > > Thanks, > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAll9+QcACgkQaVcUvRu8 X0xDSw//UHhhTq0kbg4H/Nx9ddEupL0vU3fk/R7SAvhx14Ehe2U7qi+qjnGVr6es TzyU1gabtgtJhDvpiNM1vkicCeLgK7g5vcaKvwqRB2kBIWB6PRfOy38lUzk4lMsV lAEUKF8J9uGE99nwPwV1fkhJ9QIf6nKLYURa43YbFvyeYrHxZf6h67kTUGUsWjNr W0zkMHA+cDNf6RBGo99QkNH1t4KM7LSztVqSB7x6BFGdcYWan4DzDpwvBu4HGH4C /cIiBS4bHrCKB7r3ZIvpjtKLmeuNzlpfK1tSY2Qx4hqmUa2L+54dDH1E2g5Hm8/J RcV7NZku+ojM3/r5r0b4ofo0+4PKtHyCTCxLohNa/EsF6Rsdq8O3EfOqqbqJIwI1 LAvZxWUsRF7Y06babB6HDAEisboPJd9+zxGs77hqg0zyCDBna+O3JQ7xBzBbWHjR o6AWkOnxgE7c+5vsOcsAGuOI5D/IrMQVqgD5vrxeAwljP5WSkCTPY9QTmuWU6Xok /E4RNHIO63lx+tH9+kpP7irVfuPBTWY3wwXt/E/D1RD1JgvctEgbTXYmvGabuh/U ZQrym7fWvc1YjPxCAw8p+EN0JDb3edCf3wTWvord9rDXiUYAggBJmyTmiE+YBCjI 5pLoaYPTzHio95rIlVR6ZMpcNnElw3MxO7A38akalvZYi3zW/Y0= =xQ+m -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rpm debuginfo improvements for rawhide/f27
for ELF files.
> > # The following settings are supported:
> > #
> > # - none
> > # No build_id links are generated.
> > #
> > # - alldebug
> > # build_id links are generated only when the __debug_package
> > global is
> > # defined. This will generate build_id links in the -debuginfo
> > package
> > # for both the main file as /usr/lib/debug/.build-id/xx/yyy and
> > for
> > # the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
> > # This is the old style build_id links as generated by the
> > original
> > # find-debuginfo.sh script.
> > #
> > # - separate
> > # build_id links are generate for all binary packages. If this is
> > a
> > # main package (the __debug_package global isn't set) then the
> > # build_id link is generated as /usr/lib/.build-id/xx/yyy. If
> > this is
> > # a -debuginfo package (the __debug_package global is set) then
> > the
> > # build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
> > #
> > # - compat
> > # Same as for "separate" but if the __debug_package global is set
> > then
> > # the -debuginfo package will have a compatibility link for the
> > main
> > # ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-
> > id/xx/yyy
> > %_build_id_links compat
> >
> > # Whether build-ids should be made unique between package
> > version/releases
> > # when generating debuginfo packages. If set to 1 this will pass
> > # --build-id-seed "%{VERSION}-%{RELEASE}" to find-debuginfo.sh
> > which will
> > # pass it onto debugedit --build-id-seed to be used to prime the
> > build-id
> > # note hash.
> > %_unique_build_ids 1
> >
> > # Do not recompute build-ids but keep whatever is in the ELF file
> > already.
> > # Cannot be used together with _unique_build_ids (which forces
> > recomputation).
> > # Defaults to undefined (unset).
> > #%_no_recompute_build_ids 1
> >
> > # Whether .debug files should be made unique between package
> > version,
> > # release and architecture. If set to 1 this will pass
> > # --unique-debug-suffix "-%{VERSION}-%{RELEASE}.%{_arch} find-
> > debuginfo.sh
> > # to create debuginfo files which end in --..debug
> > # Requires _unique_build_ids.
> > %_unique_debug_names1
> >
> > # Whether the /usr/debug/src/ directories should be unique
> > between
> > # package version, release and architecture. If set to 1 this will
> > pass #
> > --unique-debug-src-base "%{name}-%{VERSION}-%{RELEASE}.%{_arch}" to
> > #
> > find-debuginfo.sh to name the directory under /usr/debug/src as #
> > --..
> > %_unique_debug_srcs 1
> >
> > # Whether rpm should put debug source files into its own subpackage
> > #%_debugsource_packages 1
> >
> > # Whether rpm should create extra debuginfo packages for each
> > subpackage
> > #%_debuginfo_subpackages 1
> >
> > # Number of debugging information entries (DIEs) above which
> > # dwz will stop considering file for multifile optimizations
> > # and enter a low memory mode, in which it will optimize
> > # in about half the memory needed otherwise.
> > %_dwz_low_mem_die_limit 1000
> > # Number of DIEs above which dwz will stop processing
> > # a file altogether.
> > %_dwz_max_die_limit 5000
> >
> > %_find_debuginfo_dwz_opts --run-dwz\\\
> >--dwz-low-mem-die-limit %{_dwz_low_mem_die_limit}\\\
> >--dwz-max-die-limit %{_dwz_max_die_limit}
> >
> > If there are settings missing that would be useful, bugs with the
> > default settings or defaults that should be changed please do file
> > a bug
> > report.
> >
> > Thanks,
> >
> > Mark
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
- --
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAll4kUYACgkQaVcUvRu8
X0xOWhAAu5GGfH9ZsXzeZx/lARpVWsWzou+SiQ34ECzIu6wrWJXlc/l8xEXShSFI
Ye5lNtxOlsdACvI+IIsRplLG7NHPLoyX6593yYNS5TquUU6dSVIw2PH8wAy3uk00
mvO65HPlYyMsA9WK/MvcXVhdeCfPAJT9q0VxIrjrwpwa1nJbj4+gi8JEMqQSptPF
mgFEUa/HuE4rBb2kSQQDEfxOlcI7P39/FgmZf6eYqv7JwVWJ8S2vMgNnKU7gZvgP
oPSP7D52MHjZRJWUky3GtpyicNZafikpnt8iCJc1wItBeMl5uRm2zElqxPsEP7Sp
6pr7PKgDp1/B5XELyOfhsvEWCw4rVHzoWiuhyLqRcrGrNXLQbXCas9vKag1GLWDX
n+WutrsyxvMaRf9pGf4q+8RXEdpMlaMKgImigmK1FFCVcELhVkVF5jAs6VDr78Yp
rm82JQQ6OeFi55lj0Hl4aHT0cjYq34birfaJTreJ/VXGDbGb8IfEEvNqDetuX1gM
vl5VWfLZgCdgtX8JYrjxx7pSTZsZurw0UD+0sddvSYQlYAYF4lnRVPqL3wmhv5QK
P7U9xxdfKCM42s7qq20eexbgVPp0PB5/tvJrjL4AGviRQATrXY4NXKN0j7TKy04Q
oXHBmbBG4Co3gDEQt+OUcOIOMTMalkC+IuZpbwjM7hRww0j1qEo=
=UcUg
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Retirement of pygpgme is coming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-07-21 at 15:36 +0300, Alexander Bokovoy wrote: > On pe, 21 heinä 2017, Neal Gompa wrote: > > On Fri, Jul 21, 2017 at 8:08 AM, Igor Gnatenko > > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > Hello, > > > > > > pygpgme is dead since 2013, I've wrote and applied some patches > > > to make > > > it to work with latest gnupg2/gpgme stack, but since March it > > > FTBFS (so > > > I added `|| :` for tests). I'm planning to retire pygpgme from > > > F27 > > > right before branching. So just sending email to tell this to > > > everyone. > > > > > > Affected packages > > > * alot[0] > > > * epylog[1] (no response since March) > > > * fedora-business-cards[2] (no response since March) > > > * sigul-server[3] (puietrwijk responded on June, but no progress > > > so > > > far) > > > * yum (I can't really find BZ ticket, but I'm in contact with yum > > > maintainers/upstream to deal with this problem) > > > > > > For those who care about EL, gpgme might get updated[4] soon, but > > > I > > > can't guarantee anything. > > > > librepo is also affected, as it uses pygpgme in the Python > > bindings. > > That needs to be ported too. > > Samba AD is affected as well as we use both gpgme and python2- > pygpgme. In build-time or runtime? Which exact package? Note that gpgme is staying here and not planned to be removed. > -- > / Alexander Bokovoy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllzJ9sACgkQaVcUvRu8 X0xFhRAAjhkKs5fSJ/Cz/weoZ0hYaoR8mrNiWG2ilHubvxptX2TlLX5v1xNZFvfr G7czzpCeyo+GWapFrb0j6Nij48kzeIhvZFA4tefiKbiVbZUfaf1q2tETCrBqgVzO fE4z399IHuV9YZ9ZzSArgxH4wuTvgBP60tEh0gCf6Rx2EgJj12i4yE73EQemf9xb UxSL+IUo7bfSILEnKjbIzyJAYqnphYcOlkuel8nXgr2S9LohWkL7J9jhQVhj86w1 kGmi58CZi3UWJvVSQ9sC3l20RVMSteviqEN+t8PiQI15G27Sdwgmne//18kP2JVH h68uD4TUfNS1SUYQKeCLLLTNJt4ozqOeU/IcFLcXb8314UDLJSrebY0lX2SxQ9j9 7cPKTA6Z46t/C7WaFAtxmlXnPHAIQjBGm8I2tv0u3M0XMWvt8A3/u21pZpfHGzv8 DWOzny17leWlrbTQF1owQRsOkYDsbrbwb8MlS+uR2T3j6KPT2aiYwcYfWkl0N8Zd cChOd3KwepVRRVC7zZhz2UDn4T86M3n1DUxxuwzcrcR+PZ8HZSzg6it8Act7S7i5 QM+XEyMvTk15lqDoZcUc8oK/Fryu2sdklN2a1YWydKbtzY32JNoxgcuRWCXYni0M MY9u48sozya71soJkNCis1CaWW1StCNg3S1gYIkKxFFFQKSu0EQ= =H8lM -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Retirement of pygpgme is coming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-07-21 at 08:11 -0400, Neal Gompa wrote: > On Fri, Jul 21, 2017 at 8:08 AM, Igor Gnatenko > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Hello, > > > > pygpgme is dead since 2013, I've wrote and applied some patches to > > make > > it to work with latest gnupg2/gpgme stack, but since March it FTBFS > > (so > > I added `|| :` for tests). I'm planning to retire pygpgme from F27 > > right before branching. So just sending email to tell this to > > everyone. > > > > Affected packages > > * alot[0] > > * epylog[1] (no response since March) > > * fedora-business-cards[2] (no response since March) > > * sigul-server[3] (puietrwijk responded on June, but no progress so > > far) > > * yum (I can't really find BZ ticket, but I'm in contact with yum > > maintainers/upstream to deal with this problem) > > > > For those who care about EL, gpgme might get updated[4] soon, but I > > can't guarantee anything. > > librepo is also affected, as it uses pygpgme in the Python bindings. > That needs to be ported too. No, it is build-time dependency. But thanks for pointer, I will make sure to port it. > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllzJ4kACgkQaVcUvRu8 X0zQYRAAldY02AjFV2Dzwh1eHyLpJrV4f6W3PzKAwtrxrlqrUVduAjriNxsAODiV tHsnXAH8dxQYcafaJ2/qgDZZ8KZDSmWoASFQe9oBaKYuzeprC18YrsLvJWGCmliS 3zcNXx+15uyGtD0hElYnH8tICb7cls+HC7daq1mV+X9l9atMVNKyOGacXnXb1yuP fvwXAisSejVfGLD8/Sr1xVeG63sjIqArFvfBQ/X+RYCEYd+4v0HnX+43ebZRLq2a V/DDV+Rcr3jbCPhF17RSImSONWzjiTNKFGN96deKoPF+89S4j4kQ8fG9Vto4dz0f l++C5BJr4eB3bTRDQacSypFWbcgSqajacALTG4lB53zBjb+PR0KPwKP/0JnWYLlb MLigbAflEdEpZRwurEqVZ9KG0dU4MfsHEEnEDV6hV9W6Wk83L542x7CKIGoWUEJI 7GZX4h1Ds2yf+CZqy96zIQTQCEo2b4yp+3p1N/4LRIJJxaP3iCFYprr6xLGQUCEx nX5cYbv5I895KLnWOaV2UWE+mqXJ1Ud59s+uBzwN2d8+NMt5vvNauer8eMc0oJe9 CAgX0CeK3JXf5z/AHbzlR30mHJLCcenJLblIzzfhwJbN0tE8kgAdpjbujCXzuq7C zw06czkprTHBT+YO9Ze/f8sJqmDCx7XjwcqJp4mqbb/YxLysDz8= =SBWt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Retirement of pygpgme is coming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, pygpgme is dead since 2013, I've wrote and applied some patches to make it to work with latest gnupg2/gpgme stack, but since March it FTBFS (so I added `|| :` for tests). I'm planning to retire pygpgme from F27 right before branching. So just sending email to tell this to everyone. Affected packages * alot[0] * epylog[1] (no response since March) * fedora-business-cards[2] (no response since March) * sigul-server[3] (puietrwijk responded on June, but no progress so far) * yum (I can't really find BZ ticket, but I'm in contact with yum maintainers/upstream to deal with this problem) For those who care about EL, gpgme might get updated[4] soon, but I can't guarantee anything. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1473647 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1433369 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1433370 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1433367 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1412310 - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllx7tsACgkQaVcUvRu8 X0z5jQ//YxNsCcQZ72lHrunb50OovNybCMLMS8FxgN9UIVt++In1oOmIPSZaVPrw M0erF/QBK4EfPgFr6nhOcLPaiicMfslURZXCktFSv6LHPtSeMrF1Q/sLk84LpoWz tFQc00O1pw3pJ3DOYCF61wemm7c8cblxFiyXmgQkvnqweFAxqu1t4EzfAh2elAAj 0Nv703IZOufVh2GblYzo300NpokugCaROBQE2edJheLYHowBTPemNul56EZUyavr SDrSx6QxW5vG1WaS7h6VWKtQTmnP5fE6CrYLyX3EIJ1Ck1oO85n/xkkW2PyqBIIA Sm1DKDX5SCpuqqOOODfRbkp+YZ9KdtNIi4M8ddyaHCgim5l4hDwSInFuZ/icGPpD xuBLQ1wp2QT8h8rH1fIhhT4jHjEbBdMPu46/yCvWoW8kFD9A4oIdGPQpa+M2QrIp uejvMxdvMBzlMIC45hEs8U3sjN5kCRIH0sHS7b5kbOAmqgkehxwJs9mxvrcqf8Vr fWidUkO1wtJuIQB4DLXr49emBCdQTqI4yLbdw4FQet4ItS3ZSMjrF4bKr4wMIIcW z6Gqk09xVZ09A8PwGryqx6iUFrB8KnhtL+xJM4yCQrhTVUU2yntX4GVPPNhkr+kC gyK1Gu9uH7+BhXRxezC/07ZerpyUiBFh8OtB6Z+aSWoE6BIzuKM= =UOT9 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: Unified database for DNF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2017-07-16 at 13:27 +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 12, 2017 at 02:17:47PM +0200, Jaroslav Reznik wrote: > > = Proposed Self Contained Change: Unified database for DNF = > > https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF > > > > Change owner(s): > > * Eduard Čuba > > * Igor Gnatenko > > > > Replacing obsoleted YUM/DNF databases (yumdb, historydb, > > groups.json) > > with new unified sqlite database adapted to the current needs of > > DNF. > > > > == Detailed Description == > > Using single unified database with shared interface enhances data > > integrity, safety and performance of package managers in Fedora. > > Database is easily expandable for new features (Modularity support > > in > > DNF will use SWDB). > > That change affects the core functionality of the system, but the > description is missing some useful details that'll help evaluate the > impact for people who are not intimately involved in dnf and > packagekit: > > - Some details about which databases are replaced (e.g. paths in > filesystem to the db), and details where the new database is so > people > can introspect this change more easily. Actually, everything under /var/lib/dnf > > - Does "enhances data integrity, safety" really mean that dnf and > packagekit will show the same history and provenience of packages? > (Or was the old db unsafe?) Both > > - Any numbers of the performance part? Eduard should know > > - Are new deps required in dnf or packagekit? Are any removed? libsqlite3.so, but since it has been required by python (which is used by dnf) and directly by PackageKit is not a problem > > - Will selinux changes be required? Not expected > > > == Scope == > > > > * Proposal owners: Port DNF to SWDB (patches has been already > > sent), > > Link? https://github.com/rpm-software-management/dnf/pull/785 https://github.com/rpm-software-management/libdnf/pull/199 > > > Port PackageKit to SWDB > > Link to WIP patches? Probably only locally on > > Incidentally, that GSOC page has a lot of interesting details, but it > talks about F24, so it's unclear if all of it is up to date, and > anyway > I think this should all be part of the change page, not buried in > links. Thanks a lot for reading carefully and asking such questions. I will make sure that all details will be added to Change Page 😉 > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllshOwACgkQaVcUvRu8 X0zYLw//ZDALaHDpqGQgaYSs3UyMvJ+ApfYi6qvAgiRg1g4JP3WmTNu7O5cdkCo2 8DTRPGhXE3zjr9FgwPEZL6vInn1U87Qzjr80mTBqKcGBofJPY79eBg5L5RT63ibr UtFOTqSslAZGz3raPnxTqb1ARTqzpU+J0y8Ec2zBTo4d6fPOd6Mqhzo4nt/6MpRx fNkZZdXvZvSy4568b3YqaMz5/kMjc7oYMp7vqQscI0LwlLkQVdYt19ugKfZ9X3TW VQqvOJj6ofKyLGMwlhOraTDoHuMY0/q1Ns1baSsbySE9vGFGBZCPIUhTApQ2/LAM eh4iDR8ktc+vwSEdgxwnkY5d2jRS4CkZE1OUr1OtJqcpc228y1vbjaYstUBdr3QQ Dwzdu5dLBKAfTBU8SYKfUuFcb+ek2NCXDi+ONYliF4WTZfVJB093CZyfHHRWOCZe kfHumITw6zmQ72paHt0yaTECUK76qn0avZ3FESH9JVNWOWh11eER1zhQV2cO5Q3W ZebrD0FvnkRpL24O9iReFKR1iLw1u6csMqkG4EdrC9xh7PDXI/UdJrGh+eRc64Oj Lz5C92VG9Jin9beCWWUpN1yJvYKp7Us0WhejjyWU3Odqt4G2V2jZGfczwnfDO4vZ fv+eRkEM/mhTPCe70y3s+v+MkeAD5ATKmrFQ9wvxtZuWG1yBr/4= =HyGR -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] libgit2 0.26.x is coming into Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'll be updating libgit2 stack to 0.26.x this weekend, there is only one breaking change and looks like none from packages are affected. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllhBxQACgkQaVcUvRu8 X0zxAg/+M6luGDR6+XYgnLMI4vatHWJOfJvRWLYZQlW/ggP25IpI/RMVlkNxCD12 NFtkp5jwhzRSZyvuipiI4EXA+c3CmpvAmkpWGSqvg767Fjs9nesqTQzsBxEpqQg/ UrNH4ufTxbttIdjEdjy5/94lDnOxC5bvUoBWijxxb9ZwAePqpv5Z1kIJBy4pJAZv uehT3MrCqCvLjo/CvcTOTQ9rb9MBTTBcrDANNKin91vGKkgLnPR2Dr8qTfKgcO3b KvjcNlzIvaUSyUc9e3HTwUsY0ojUi7G7Outxkp9L96DzvbnjT+iD8JV5Q0nu0y/h 8jAk9L/P65XBRzwIToDpBhIfVVm0h9v7zG/IglhVFNLyhracZtJK4uJNhV57S5j1 3IJ/n6v4cPehlUCzUudPM72XNEfz8kJh0US9exdibiVR+vv1G9021RfF8GNG7j3y CLsL0Plsc5h8kfoYKZdEorx4F71xnqm3vnK/weNBA1nR2uifQDzWOb/MwvjvmS5C oyw5QpSW5fITQIqGfY1QgR+YGIrtk59NPg9pRgFWTgfTOL+QRp6mdsYA5WU2AKMF UdkV+z1YdEhMwopYfr7Y8CC28wt+5yu0WnF0mn5rs+APj3XYdHb6yws6VUZG2GVu A/TjqgrHuKfSfm0XWPtgA0G16M9JcKkmNCcBg24J0dmLxfR8eGY= =f6J8 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rawhide compose failures the last few days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-07-07 at 09:22 +0300, Yanko Kaneti wrote: > On Thu, 2017-07-06 at 10:31 -0600, Kevin Fenzi wrote: > > Greetings. > > > > Rawhide hasnt composed the last few days. The issue is: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1467710 > > > > Somehow the bind99-libs package isn't getting pulled in anymore and > > dhclient breaks. It seems like it would be a change in bind/bind99, > > but > > I can't see anything obvious there. > > > > If anyone has time to dig into this that would be great. > > Just some pointers... don't have much time to chase it further. > > A recent (dunno which specific one) rpm in rawhide changed (either > fixed or broke depending on the viewpoint) the interpretation of some > old ways of doing filtering (%filter_setup , %filter_requires_in...), > while the new ways of filtering (%global __prov) still work. Thanks for pointing out to the issue. We've fixed it in rpm-4.13.0.1- 30.fc27. I've rebuilt all packages using %filter_setup just to be sure that nothing is broken. > > This apparently left some packages with incomplete requires/provides, > specifically missing auto shared lib provides/requires. > I am guessing dhcp was one of them. > > Yesterday, changing a similiar filter setup in samba to the new way > of > doing filtering worked around the rpm issue. > http://pkgs.fedoraproject.org/cgit/rpms/samba.git/commit/?id=bff8742e > dff6e12d9ecc219c0c52623f9419c0bc > > > Regards > Yanko > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllfdEMACgkQaVcUvRu8 X0wpZg//Qqa1ziwvRaeElwcFrhl8hFB2Ixk1s6x6zWmJ/uCWoFZrUe8e+shNOnOI OpcpUPizkvjY3aZW+nBmwLCJaRZMPbxh0Tlqqmy9GCEXnNtUQFFA1IVB2XQQIero ryHRVR0/PggYwYHEFeMpS0yykz+Pa3XahudXfxm7r+zA2kimCkLaz79653mhEyL3 N2AiYW7Jzv9xeiBt+hzCqUu9vtgeegkqzumCnXpE80a7Zpt02EvYS8CNptgygAOQ Ww77JGeMNOf7MlqnZcVIN76v44Nj4D3fZ79Xh4rwsflUmo7BhUaXOU/BTfN+PVJl qe8ftLjjMZqHfed/6wgoFohVD3vHeVBYdlpKK1fsS5z3nt7bIEYoVlPICB2IO+qt QjmkUwdoR1o9N1q1LPbW3qK0CQd7Mf14fKpkekzpf+OF9Cq4uRov9NjsnOMcG+7X O9H1xQnhNX3+EQ9L5Rg9p5joZfaQKckVQsEt68ROKRGiZb8bs0KV8zncYcCWU5KY JwxksSFRbXCczLLw3hqA34+dBnv527ho2pKeNqRRtEKz9tBHyS/Yn5yKq8cqGPQE ZmW5yQJ/pEw38L2SnQyeixjY+dvF4ydNlqpOwoS5YlAjWO88UlbooRMRMTWaChKu p49Vgs9CzV7QeW9HVyfo6VIYSgrsMZah48MysJllwz12f9NNI8A= =ScrP -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Modules & Fedora 27 Server Edition (Changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-06-26 at 14:30 -0400, Matthew Miller wrote: > On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote: > > Apologies, but I was talking about "available in the Fedora Server > > repo". Specifically, we have a lofty goal that everything in that > > repo would have a module wrapped around it. We may not get there > > which triggers the choices above. > > As Fedora stands today, of course, "the Fedora Server repo" means > "all > the stuff Fedora packages at all". At the extreme, even though we > tell > people that it's better to install Workstation or a desktop Spin if > they want to add a GUI, you _can_ install GNOME or KDE on server. > > I don't think we need to support the extreme on Fedora Server (as an > edition) in the future (although I think we should do what we can to > allow community members to compose such a thing of their own if they > want it). But, we should set a goal like 60% of packages > which make sense in a server install available to modular server in > F27, and 95% by F28. (Where those specific numbers are just made up.) > > That can be done by: > > - Every RPM that's not a library (or library-like) becomes a > module. > Like, basically everything in `dnf group info system-tools`, plus > cowsay. > > - Lumping some of these tools logically into "network admin tools", > "file archive/backup/sync", "benchmarking", or whatever. (This > seems... hard to get right.) > > - Bigger split without real attempt to categorize, like "Random CLI > tools" and "Random GUI tools" modules. > > - Gigantic "Everything Else!" module. > > - Allowing package installs from the unmodularized Fedora > repository, > and doing something fancy to avoid trouble. This has been tried by AltLinux, they were using Group tag to organize packages into small repositories and after all they went back for one big repository because of cross-dependencies, questions where to put what and probably other problems. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllRYT8ACgkQaVcUvRu8 X0w6iA/9EeCA2B+I/NaLe+LIdr7gfAshyIsgIBJ6690QRmeqNNgv1RKkVuRfKEy8 NtEbp5NENAa9T5Z7PtcccDoWzkU14KMB/ECyzK5nkVd1La1DdDfpJSHpw8wTwD8+ P5setc4zkwxS0kEPA/Wxp1tw71VBhoHLFBcKBYd3/CW8/E7e/wcqfNW1hhHww1XD lMgBL0ISJynBuJuzRt2y0A9ymP96S7HN1Sy7nu5h+zV6ZS7IvdOviGKdrRgo0iOk Y8eHFmGtzAGLni/95rGVYHyZ0IIY+cLn1HLs23IPvoF8/Hz5FjjJkIkP22fw06No Ljy4SaL589e+dBPYRn+MFR2w1niAFOcOHATvnXqNpwbxlYv7CsjBEPv1o/+3BWQw PX7krNorSHo5wgw7ldA6leqp/aer8xz6Kc6v3MbV0p5ooCOn5kJLxFCLDnFbVOKe ogkfAVlW0RDEMMf/DoF4MfRoRTfGLBF72ALrm3BMtatxPZPpQECffsiAJ8jtjpei Gaps2ULlyrBu1kFbPsFXDe9mo4meLpiOH3ko5ZXHTZzTClaPlLHQMX39UD1YwcY8 N5KFDhXSsjmeSWOh4cVl0I8Gy3XBQ77DV9oTXaKMXgwCtQWPlHkkPhpWc/h/TOIM cb8a2wrRQTDUNem00r1oilDuimdaNO4Hb7RLZBkrOw94QhTXF38= =Hyrm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: coreutils /bin file dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: > On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: > > While playing with Base Runtime container base images we noticed > > that some packages couldn't be installed with coreutils-single > > due to their /bin file dependencies. Unlike the original > > coreutils package, coreutils-single doesn't provide the > > pre-UsrMove paths. > > > > Now there are at least two ways to resolve this. We either > > > > a) change all the packages that depend on /bin/* coreutils > > paths, or > > b) we add the respective /bin provides to coreutils-single. > > > > Reading the packaging guidelines[0], I'd lean towards "fixing" > > the coreutils subpackage, while the coreutils maintainers > > believe we should change packages that depend on obsolete paths. > > > > For the record, there appear to be only 25 binary packages that > > depend on /bin coreutils paths[1]; > > I just took a quick look at the systemtap package. It has: > > # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer > # distributions, /bin/mktemp comes from the 'coreutils' package. To > # avoid a specific RHEL[45] Requires, we'll do a file-based require. > Requires: /bin/mktemp > > On RHEL5 the mktemp package only provides a /bin/mktemp and > no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be > changed for Fedora of course. But it might be that there are other > packages that share a spec file between RHEL and Fedora and have a > /bin > instead of /usr/bin Requires for this reason. RHEL[45] is dead, so feel free to drop this. Also polluting spec file with conditionals (or any other things) for unsupported/unrelated distros just create problems. > > Cheers, > > Mark > > > [1] https://paste.fedoraproject.org/paste/v-SDa5byzWT93OKPWZ~XKQ/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllMzUgACgkQaVcUvRu8 X0yBNw//ZFIdWFuxY3vqQ5dsR30z6sQW1WYpV8tD9IqY1JwD+SVIYlCr0xXFnV3d K2f4a5ix2nqGMLrFharz9n3KqQk7oOSuS/YgPUtywJPmupaYCtPA7LohYqf6uDgI YhDYDhy1qcYgqTVm2twoG17v6HkO+qu4AQDl5AeHG5Tz/NvIhDyiZH9CFXf2JT+G BevsvxllMxOo5H00ohykpIVakc5JKPWSulNsr6jYm5MDQ5qnxDR3tXAB+K3KZj3z VHvVq0Rpakwcqc4gtJI3/iJhSiHxbNgF1b5nz9hK7Wx059Sd+8hMNRMwkUXN4F7u Gf99qWfrgj4L0yUym0tKLFafiBLAzX1lRsAMVwtygSGokNhzMwV34bUR5WcO7wFf cdM8k1LFA8axToBYQfog2z6DJo5jXk95EMoJXZ04Rm98x2U/bLszJVrF/xZRGnQ7 SwgKzPRrS2WTQ3EPuJElPMfvarTJKjrV9pHP2+oMcVZvhFZs5hh2fMSVmRH+IcYa brEmOJ+GiuAUWvg4gZi3e7Pdtf+FPrZl5uZJDPLXWxkNa2IPE4ficQDAufnxp/1l h2PWvaSTbI2UHALIaA5NY9mWAlKPu8GjdF1Tavgzfw6qCjEXcw0IlCSnE06a5+uk zf5GDvz0fGY76sVaDhj43KPDSGHPfJJO9CA8u9hdRFF0k6blX3M= =92b2 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: perl Package to Install Core Modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-06-16 at 02:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 15 June 2017 at 20:05, Stephen Gallagher wrote: > > On 06/15/2017 02:02 PM, Tom Hughes wrote: > > > On 15/06/17 18:27, Stephen Gallagher wrote: > > > > > > > I think you may misunderstand what "Recommends" means. At > > > > install-time, it will > > > > still be pulled into the system as if it was a "Requires:". The > > > > difference is > > > > that if someone later decides to do 'dnf remove perl-foo', it > > > > can be removed > > > > without also removing the main 'perl' package (which is what > > > > would happen if it > > > > is a full "requires"). > > > > > > What does "Recommends" do on upgrade? > > > > > > In other words if Recommends was used and a new perl version had > > > new modules in > > > the core package would an upgrade of perl pull them in as you > > > would expect? > > > > > > I don't see how it can unless it also reinstalls ones the user > > > had chosen to > > > remove? > > > > You are correct, on upgrade it only updates packages currently on > > the system. It > > won't install new ones (except to satisfy new dependencies for > > existing packages). > > No, actually it does try to pull in any missing Recommends:. That's > why > I have to add -x trousers to every dnf update I do. dnf keeps trying > to > install it each time. mlschroe commented on Dec 12, 2016 Ah, it's a feature. Anyway, it's pretty impossible to fix. The problem is that there is no information why bash-completion is not installed. Is it because it was not available in the repos before? Or it was not installable because some other installed packages conflicted with it? Or some dependency could not be met at the time? Or the user installed dnf with weak deps disabled? Or it was installed and got deinstalled? So we simply don't know what the reason is. Just ignoring the Recommends is as wrong as installing it. Add the package to your exclude list if you don't want to have it installed. (Or disfavor list at some point in dnf's future...) This is possible to fix on DNF's end, but it is complicated to implement. So if you really want to have minimal system, set install_weak_deps=false in dnf.conf and use -- setopt=install_weak_deps=true when installing packages. > > Regards, > Dominik > -- > Fedora http://fedoraproject.org/wiki/User:Rathann > RPMFusion http://rpmfusion.org > "Faith manages." > -- Delenn to Lennier in Babylon 5:"Confessions and > Lamentations" > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllD3rIACgkQaVcUvRu8 X0xc+RAAgoMeChN8hTmNwRx5xptPr6HBG37U7EUDTP8xBxkZZ0wVfLDSMTGnXYjG tCQH6yDE4VNlrfurmEwJcOIZKpDmuOyCw7J+F45o6TgWUBhrfrJpENb//KBt4AUG psuiR0UP1pjASGvXhRx3o+9AsPq9wc2oOixjS4b+3WVyRTwzT7KqkVAc2laDyCCL 3s/AtTM9R+grLVZsDQbaNeNLLujGcW71DEh9wb5NXx0XZYAc3VyXzB3+sdo6diOJ Te9VeoPWsQO6My0OT1eiqGxk4b8Mv8or+z8t9c2s3b5KO4NTnL43KPtmiKtA/ZqS m2ub3p2ZpGBPcQBTiJow/x7Hy5Hc9JjGB/jMCr1LHPgsBpuAZkF4VekwZ/3jjC44 8bFdYlX/Ny09u/0Tr6Xzy+RCLGL35MuHrCZ7KajrAUg3PMldR8d5lvTFMPMcmAgI tP5yAUIZTS9jtkfH/VTUC1zPckJiCmc3Vxdfy/DbZ9bhQg1MTkud492pTED8YRax Psp/CYLFaUS4CjdNP6OLMjVp53F6uoTskJS3d2dAOmsw6HsBXlkxdrzhY1w7BmJY bVdoNmMDBYcGCahes3nve9qYnGDEFXxU+dmiL2SfpIWUmdRfI2rmiZJI9lf+y9Jt L/RT91i3oUhU/eyHKcC+K49dCp0WzaZkejIeKw3ENeN9D17xjqc= =vrWe -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Rust SIG is happy to provide tools written in Rust
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everybody, on behalf of Rust SIG[0] I'm happy to announce that recently we migrated our package builds to COPR repository[1] and would like to ask you which tool(s) you would like to see there (obviously, those should be written in Rust). So far we have: - - ripgrep[2] - - rustfilt[3] - - rustfmt[4] [0] https://fedoraproject.org/wiki/SIGs/Rust [1] https://copr.fedorainfracloud.org/coprs/g/rust/playground/ [2] https://github.com/BurntSushi/ripgrep [3] https://github.com/luser/rustfilt [4] https://github.com/rust-lang-nursery/rustfmt - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllDt7EACgkQaVcUvRu8 X0zfIhAArMWpii0y1cXuDPLnc6M1psROV6MulFtSGvVEHPKWXpFr373OKGR5DLym iCdXxdJekkj3u+gXNb5W1rgG220m30VDXpzFlnWheSCrJJeLJtnI30VEtIc0Umkn b8CKUS3KZdPEpD/pJ9EWpSiFTmVUcBFrNl2IoyTkfVCmt3F5hyJngQ8ZnJt2ftPF iK592ngDw9ara6eyp8QPJ5u6ZCDqeBmqqtRSJ4zyRNuerjq5/3JzpTXeZtj9a//u zFrlzLKhPHVSgkULev2B7TVnkqAkv7ejmNM9k5biTIb4S+W+7Cfcn0FnLf9cFKgT L3NodK90xH40AymExtrCGAuOcDzOtJnqqC8SjblIZWmyM9gIB7c4ZZ8dbOoxIq3K g1tCadlVMBCm9bN4J58OKxOirykrxA9BN5mcukvnlyhWXgQK/y0U9UcjeQFDhhIv 8TAxNjbak335MejzGBHN6aYCKmlAkMYRFooJ0iMREQZmm3J1RyyEj2jr02gAo4X3 LLFOnZcrYvVenyveJRpqX4eT9P7/MipJKeBB8GQVed1L0BQ0VFYzg92P5RNzRCwA eakPsXazPXL0xIijBT7SrWbJJZxjGB8VQVUTKbzS3TUeenA9PWuI8YHAb35sIJnO mzSvUAeVHZoEhV1DZnDcz1mrsP7hnvjq+4n52zXsBordYtVu5Qg= =lX5R -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] npth-1.5 is coming to Rawhide and F26 and chaning its license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pretty much nothing interesting (fixes for *BSD, MacOS and just fixes) apart from changing license from "LGPLv3+ or GPLv2+" to "LGPLv2+". """ We relax the license so that the software can be used by more projects. - wk (g10 Code CEO) """ - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlk4/IIACgkQaVcUvRu8 X0xrLBAAqATBHvZOF9YWwam9bnEqVWcr/Lgd4Lnz5oFdEVft+D0Yfb+o5EBhv+15 oI7Mww6SC9oGD/vo12szDGo8pE3Bi804LEwzaxF79k8+3cHzGUwhMSK5O1wQUA4A weslGfw5DW+0PEvXsD7HcuKjcstv0w2C1C0HNLt8zScWTqCzvpi0rIzCebvKgID4 8ABPtTGPuSVsoyIHx7EwMAQOAGUx9Xmo6fmG3xEDu7TllOrmr/vJNIgT6GMXXAwX io/clx1z6rkuNew92iA4hVOibZePUzLgbZYilGssdoFMe43lkv0Tw/+QgJJUOZXT jubkcElXvpXZtcn03HJKWHUYmBNpsUhDz6tUGvfmh0tY3V8FvNY3PsYfV7CEDM0+ s5Nj1jWqLEhHiK2vZ5LbKG+eSMGmDBAvzcJB4rlC/iNcqZcbKxrFLj6D72DjMRdz Lm3vH/nVndhLQY3DFBfjLIm8vHtJ5MBwwjKBll13ioHAse4PNKzvUWl1b2Ve92bq EKe8tT4KvXDfeHMzRJ7MZ4hMYgH7dK8dCredVn7GqQOQlWf0waL0Hj0xZ9xpbigs kWnaaw8Jkf75z6FGKGbVmwmmQtVi8Ma4gGCT9rLSGj+6I9VnH5COlgCz0S0ucyAi VlMAIhnqkPiIWTrVhjZydfd2VNnJTUNjt1RmTZGf/9IGCoQaCwQ= =tXgp -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] PythonQt 3.2 in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm going to update PythonQt to 3.2 which includes soname changes: libPythonQt.so.1 -> libPythonQt-Qt5-Python3.6.so.3 This is mostly done in upstream to support py2/py3 and qt4/qt5, although for now we will be building only py3/qt5 version. If you want to support more than that -- patches are welcomed! P.S. looks like nothing depends on pythonqt, so this announce is just FYI. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlk4+NwACgkQaVcUvRu8 X0xzog//VJIXq7QUM3I7e9d5w/cktXnOb4LMyz8b550UEqN+0pSrYYy7yYv8njXr RbTbfN0craiTEQ7BteZx5E4h5gMoGayC1tvtQGxFePDq4GDgcVR7M06//1u2Vp5h 5ZivOcEyYG+JP38TygQyDo2N22asDW1/aZQ3YNaG47N7KUL6SbGYrMg+ecLzoLQe K9TqUXKS0nlZXYF6BccQ5va6ZBtNwTzxACR5LiuuuA/FSBLAyg8+Fw9zngtCxlcR h3DQ1C+TEEmJH+NSykCXBqvw5jNP1lTpDOg1dISvYi3t6/SGUaZedNQhlaHqv6mv H75EY5pKTIgAmtqRosKlCcf+hpv5wcha4osS2tvr2LccKOgRDUw2iVLxtfqLQ+12 eIlPCWo66Zsv6OUgOMAw7UWRFe0evfSw+qomdbIWXzUp8inGBrujxt1LU5hf1O1d I81rQL68H6BWB6LswobcSgnOAzSTMZ4KntEK097RGMV0Ds8iiXYCRRT+6fEaMkWK qheb8uq935XaoKjplTnIGqIKoKfAZIodTFXpIXaQpCw0kcnP/ID3og1suYG0nMy1 +n3cW/5eUWL2O/vHtECfSQyUCRR3DZXU0otCUizvqnZjd0BKUk/rHwHlqp3Et4L5 LgJq2Q27xL3fGknxPY746U0qMIHRP+XeMmDbM/V4RrdYUk4ncYY= =qh6C -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: python-dnf questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-06-02 at 12:50 -0500, Ian Pilcher wrote: > Does anyone know of a mailing list/forum/etc. for DNF Python API > questions? #yum on freenode, rpm-ecosys...@lists.rpm.org > > -- > = > === > Ian Pilcher arequipeno@gmail. > com > "I grew up before Mark Zuckerberg invented friendship" --- > - > = > === > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkyf3kACgkQaVcUvRu8 X0wYtA/9Hw7uv56Z9aqXZbTT2n1iUvO/SdyC1Bul5dqaRpEVzzWG/RWMPE0eg94D /eZi/GSNQnsYN7zRbJ7oDWTW3IsctAr2c+N6C9b8MCvZMU9ziFHOLGNE0o2YAaT7 BAMOiwXWP5GVMJBii8Ru36BxEUi92UUgcEqMz68NvuGFlC+UUXXDBbeyA6YoytdS jfuBz23Sk6IP4Zowmp45slp5EUtJTDYzPx4fUOCK5JTTVXcnLzeH/uhGLUiwOpD7 o/aQGSAkilK2TMyF9hbL7X9l4qyrHWnbWXnvDCcIx9MVZK9rhpuxWPEJ5rn2gpF2 atDXNmyDD5tzw/1iD9ZcTDo91shZLbOdKzoqaTlCpwOgwE1svDN3d5MyRyq5hiY2 6aJqghgiKxZMau6A9v2A7KQRgiA+IBeOddPoiqpMYVg+PailNvVqqw4eFPd8wig4 1SbvUnFl3CQkbeViOzcb1NqaQvCalq5E5M6dUR1VbbzuKoYNABMSingzIfM4Hx0u VNiVe/1571Xa66DLhesLGqoX8LCPVD9v4sOzMJ7b6uybYYaxPSK9yJHWrguYZtGD rJh4kTmROyQO4CrM3RpWteUH/Fvrn8Asum9kkwX7iRnBHckZiUGAlgTTo8FH66hf eW7tYN2SpHiC/lJNuCMD8mVgB23lJQV8j4ehgJcZBkV4woX9/TU= =ENQ/ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 26 Beta blocker status mail #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-05-12 at 17:13 -0700, Adam Williamson wrote: > Hi folks! The Fedora 26 Beta freeze is fast approaching (it's 2017- > 05- > 16), so it's time for a blocker status mail. > > tl;dr action summary > > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1448923 > ACTION: Preferably, Firefox maintainer (mstransky) to fix build on > ARM > > 2. https://bugzilla.redhat.com/show_bug.cgi?id=1443415 > ACTION: dnf team to investigate problem and come up with a fix That's quite not for DNF, this is bug in libdb (not even in RPM). I'm not sure what's the procedure of moving acceptedblocker tag to different bug, but that doesn't matter much (we will close that bug once libdb is fixed, refereced through "depends on" bugs). [...] - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkcGRYACgkQaVcUvRu8 X0wDEA/9E+WbBgLthZPYZSAovNDmfWbjl7QCcfTAhv9MWTV1WIXIc6tJTLUuh18L kZ68Hg6CuunS2MNeNixMe8OB43wFhbsRL6+fu2/yT2t+59pxuqjAqT3fBTOX/Ote yjUjpeYVtVJcwYS0X39j/2WHCB0HC5rCRMi3X6oFHiIU+mXwHxsIT9AH8FPmektY G0wlma9wncbfDg8PxtFQrle1zzihTGH4nElTJdS1ExxTkm32fP4EKrVMkKXRw9Jk 8ENyDAOlj+lLCQYmo4cAwh2AaqMiDKwiarkiKAEDmb26xe+Cb19iyGNK/L7yIHbt 4hkowUo9RAo7blzSORI7qhc6Lk0AFGtE0LAybSV0bGaOZ92TGa1/WbmkBgiH3Ar/ p5+oocYtgPOF33rNgJD8hb4Ab+7PKUSUu934NLbFi394RJPllJMDz49hwsJc+O94 J1QsxEqyxmFeuXXOZ3oBiCu9BAaVHCodlJP3vJOAZKZDfzLt+YPw5gQhbQ+bvi5p 63xFZGwrvOUUvXqfoop1o+tr/u2Kz3wuo8O7j2oOIllXOHpjiU7SY68s6XHspeiT 38iaM379NOMcOl3yQy9RLx5qUBN4Vb201wI0D2qwOgGxMH90yKLo1P6axiCJJrbh 4Xfmey2NsDc9tpr714Z7iSC6TT/01UXWdPBBand9hg0zDR2FLaE= =DrKA -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[RFC] delta-repository-metadata
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello users and developers, We had presented deltametadata project at DevConf.CZ 2017[0], goal of this project is to minimize bandwidth required on clients to update repository metadata (repomd.xml, primary.xml, etc.) which would improve user experience with DNF. So, we have DNF plugin which acts How to try it? 1. dnf -y copr enable @rpm-software-management/deltamd 2. dnf -y install dnf-plugin-zsync If something doesn't work, look into /var/log/dnf.log. We would like you to try it out and give feedback, it is very important for us! Just send it as reply to this message.. P.S. F25 and above are supported [0] https://www.youtube.com/watch?v=l6uWxg3yMmw - -- Regards, lab-q Red Hat -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkCJAoACgkQaVcUvRu8 X0wrGg/+Lvb/up8swQR6Nd9BacvrubhgELvOcOIsv/69aMPqe9cDqmAKUr33AWik zUWbAwpkS79BLLKjoxHTxR379Ubmj5mCWyuufg/HCgeCHOZwIBEQzqrBjwKMsIN+ ts6Qk7mo1bsgS3xozx/tRH+N1xhx1O+UInsDxS1qKQ5KIBntf/e8ZrgFL/fbjHYx /JVlz2p44tZxMHCsZP/hJv+DKV+AaY9/NcvLh2KBvpj75h8cVA3RkSE85YgNFNyD GJRjkzv+swmwWXVZMd0XNiCKKXn+qGooMsrrjAmbousG/Gd/DmTQekuO/hIkGZ+g rjSCPRjLXe+utD2lnqK5aWm1nJvaEUTjTAWKYAhV0mAAT/Y4Y8S2XcsdY6EXxiW6 iSYmXa4Rz4rTYiZ+K2XXYoEIGDVSN8C5lQyYy4Qqg2lnAyKDZ1567s/4fCz/IYpB rpDv+4jX1o3C8RY0XUuCYkt+/IpVH+1/DfkhWJCG2rNLDpnq5R7N4cryJg0MClW1 PUw24GJFbIwWnl6he0n+ShJ6wzZvd2jHwFBVj5a/718wech3YnIfSHf/xJeIE6Nn dK716wgmHUPyjCwk/cWQWdj5x99lMiDZJIXXFTu0zGLxXcHzz9MnZjDCv219u6XU Vj0dCKWa3SoLml+zmRkqb+T4acyyXlwPBahRFXN3qBhFpqoA/MY= =5ar8 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM boolean dependencies in Requires
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-04-06 at 12:04 +, Vascom wrote: > As maintainer you should make your choice between this two variants. Not for runtime requires. I have good example from DNF: Since some version of DNF it can disable "makecache service" if you are connected through "metered" connection. Way how it finds out is via dbus accessing NetworkManager objects. Which turns out that if NM is not installed, installing python-dbus is useless. So, we have Recommends: (python-dbus if NetworkManager) > > For example: if some program can be compiled with Qt4 or Qt5 and you > add > BR: (Qt4 or Qt5) then this program will compiled with old version of > Qt. 1. Don't mix BuildRequires and Requires 2. Don't use qt4 vs qt5 as example, it is very bad one P.S. is top-posting + HTML standard nowadays in this mailing list? > > чт, 6 апр. 2017 г. в 14:44, Richard W.M. Jones : > > > I have a package which needs GNU Privacy Guard (GPG) at > > runtime. It > > can either run gpg (v1) or gpg2, as it uses a subset of the > > features > > supported by both, and the program searches for both binaries. > > > > The natural way to express this as an RPM dependency would be: > > > > Requires: (gnupg or gnupg2) > > > > Unfortunately this is forbidden by the packaging rules: > > > > > > https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_ > > dependencies > > > > (BTW the link in that section is wrong - it should go to: > > http://rpm.org/user_doc/boolean_dependencies.html ) > > > > This admonition was added in: > > > > > > https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&di > > ff=prev&oldid=441810 > > > > What's not explained is why, except that it "causes issues with the > > package updates process". It seems as if the or-rule above would > > be > > simple enough, so what's the exact problem? > > > > Rich. > > > > -- > > Richard Jones, Virtualization Group, Red Hat > > http://people.redhat.com/~rjones > > Read my programming and virtualization blog: http://rwmj.wordpress. > > com > > virt-df lists disk usage of guests without needing to install any > > software inside the virtual machine. Supports Linux and Windows. > > http://people.redhat.com/~rjones/virt-df/ > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljmM+QACgkQaVcUvRu8 X0xp9w/+Oc3PIQNJ9FOvf25EVVwzRhze9zvjw0fAdQ13YRz/5dC5B34swd7ZpHgJ +9vwJCqGg1+g56JElYe/haRPAqG1/bL85Rl6QUInwJs6yoXbIFCkKRQZReX8HYiy oILmcszZ2b3D/59vUuxaIbTTykQYnAd3joeJCdD82+ZWPs8OlePkFnxm8gZOhByw 8FbWH6+T1VGzCNuyjIcjP0KdhbqTI/ELJVj6C79QEezpMtRVvvilsIEQdi3euUZ1 8lv+U3MlZMBwUosd/1eC8sUdG/Qb1457ieO9ontCG+jtorLvCj9m6nV7ZUGkgR+x kuDcrC7RQMpVpMdeQqljHnuSloEsecY4fvvPF1v4wdVHto/ihDezQE080zfnT3AH eTX1ixxAWCPuqDQxe/gYVOLswCQOSwG207lxfbvz5YhP1hSLHWmBY/+iIo/1jgeO 7VcDJzr1+K4HwuCMsCA5sp2yV2VK7UfHmzjZO5i+GIR59g7p9mjwCbZR5ddSypkL Pj10xrBGjbAX1dMOGQ+jKrrGP5uYgA8QyGo6blwJ+5rUsq/uCDdRHyQb9+YTk6Uw 7i78NihnkffJ7KagA163J+wPMUv7JJqAHVaANm5zdBYPiNFDpWJOYxzrtnaZ0POn a+etsdAy8sjAx4hpNvaF7sQbr46Xz6jwE2HlLxYtIl10UoEgWik= =tVuf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM boolean dependencies in Requires
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-04-06 at 14:07 +0200, Florian Weimer wrote: > On 04/06/2017 02:00 PM, Igor Gnatenko wrote: > > On Thu, 2017-04-06 at 12:40 +0100, Richard W.M. Jones wrote: > > > What's not explained is why, except that it "causes issues with > > > the > > > package updates process". It seems as if the or-rule above would > > > be > > > simple enough, so what's the exact problem? > > None (or almost none) of rel-eng (and probably some other critical > > tools) are not supporting them. For example, "mash" uses yum which > > just > > Isn't mash dead? Some people tell me it is, some other says no. And after some time, someone starts porting it to DNF. So it is hard to say. Anyhow, it *is* used right now. > > > crashes when finds out rich dependency. Other tools are doing their > > own > > depsolving which leads to the wrong results or non-solvable > > dependencies. > > But the tooling does not support weak dependencies, either. Weak > dependencies *are* allowed, and you can't really install current > Fedora > using yum. Yes, this is also true. Yum just ignores weak deps, but I thought anaconda/pungi/whatsoever disables weak deps anyway.. So distribution *MUST* be installable even weak deps are disabled. > > So maybe the tools issues have been addressed? No, they have not been addressed. =( Speaking on behalf of Rust SIG, it is important to support rich dependencies for "version range" support, but I can't do much without support from rel-eng. > > Thanks, > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljmMpwACgkQaVcUvRu8 X0yBtA//dV+EWj4NF/L7qZR0zxOSwSDyFsqoNnYjBNbD+iQA6sE4VtnlKAsiAcyh XCN1XcZ2KTOzHJkzJwTgb4gD+LVBv4M3HnWCbZGnZpzcFOtQkAx0yvbj0VFtkmxY hW41mJq+1VlfUic79oWVbI2YmNUdKIGxkR65IPJG20OOwwbknwE4aCQqetcJ6gny QbXMJlCtzKg/ZKUZdohKGmY84gYA2w0Oq9TKqYdhbPUpJutl+K3GX8XB1ynC/jPY fTJ/wbTFNV0+B6KAweWDftOaQR+P7nt8qAvg53p6NrFAJtVpy/y19ZDXhvu9V3AH 6U6nXHvfWmIQpMNKkj+sEpQpFXVFpey8g3beSQbOwve3qwTXCv9cOJxnlB5hkYup RhO9FdycwYZB3FoJIfHPYev0xurSmIJ9lBPD/R+oI8fXA/iCLK07VmBhCtUSrd59 cvIZrXepArlAliHtMLRAIpK7GepQRhNxWTKobJnfXrtjYk7XDGp2YHM2brXUO3Ut bYPcGtQiCQqKvohQSQ6csA2lqPQmGHeL6MoY3TUC0u9fkjL5aFm7NQVBaU3iLOmj EPnfD8CDZMP3+o2EiYNI3k2z7DVK0uOWypziyPRzVeJ1XLIrUxQG1LdqPnXS6T+/ eedcIM2Q1xBA7qjvNAIo9HWdudlTZWJj4cpo9nRJ7p9FKoWi/TU= =LEli -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM boolean dependencies in Requires
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-04-06 at 12:40 +0100, Richard W.M. Jones wrote: > I have a package which needs GNU Privacy Guard (GPG) at runtime. It > can either run gpg (v1) or gpg2, as it uses a subset of the features > supported by both, and the program searches for both binaries. > > The natural way to express this as an RPM dependency would be: > > Requires: (gnupg or gnupg2) > > Unfortunately this is forbidden by the packaging rules: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_ > dependencies > > (BTW the link in that section is wrong - it should go to: > http://rpm.org/user_doc/boolean_dependencies.html ) > > This admonition was added in: > > https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&di > ff=prev&oldid=441810 > > What's not explained is why, except that it "causes issues with the > package updates process". It seems as if the or-rule above would be > simple enough, so what's the exact problem? None (or almost none) of rel-eng (and probably some other critical tools) are not supporting them. For example, "mash" uses yum which just crashes when finds out rich dependency. Other tools are doing their own depsolving which leads to the wrong results or non-solvable dependencies. I've heard somewhere that rel-eng are planning to port their tools to DNF for F27 which should improve situation. Also I did some improvements recently in this direction in libdnf (and backported to hawkey). But looks like only few people are interested in using rich dependencies... Getting a bit back to the original problem, just put Req: gnupg2 since gnupg (v1) is basically dead (and RPM uses gnupg2 anyway). > > Rich. > - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljmLdYACgkQaVcUvRu8 X0xi5w//ZLPft1gsshJcK0mTRxRWLDGentLZ+RV/QjLZzCsFpf2LB76EkMdEg9xC M+B8ZGAdfxsqPc1m2xvy/iXt33PhUy2xODHp1D/qFgUUtt9Bucr7Tx+uWgnoB4Lz tFKmOfa4cux+h7+TLlw0snVGDcHGbIZlWg/EJrCk1jy1Aaj8cpPh0LFuOWvmTP8t 69zjpVHux4uCMf5kF0M3yem0Db2gFsir7w2FBMSHmFUZS4S9E6Ap655tLrC7gBve v8crsS+O7igk0lIMClwNI7iFl7QJdJq96qxWa8+HMtz1yme0+g/3PKqPubYWApQA CF7zqSmAiDRWZCoVZ6+IX0YeDQ20tkzmIL6bfSUigt9CKhZVvoHMA1oLCczSh3xj h6QMceziATcI91VL/0KUairDhyh2NYzL9lHnrx1Fe7CGCy+VuJT4FyzDZ3AcQ2bQ 3pCiqyb21/WsFza20zNZL21ltbHXiNPdXl7GnZ2C2RihGUAFUBYsQQ/vFtKj0R4y afEbPFaPV0C9HrawzRsfVZxiquGPXWwwbgNpZFyuQrtpOZFlrKpVxOQoWOmt/vAg dZmoddqAjnVPwpFJlW5BcvwI/Akuu2EvSmfFsQ2YVBEzfkhsYLYBXwzPnxu4BAdk DhqDwVEP7zXCkPEbK76GS/9ipRnWE/vpz/47xU2UTaWVhgR8AT8= =R55y -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-versioned Obsoletes tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-04-03 at 11:18 +0200, Michael Schwendt wrote: > On Sat, 01 Apr 2017 19:54:28 +0200, Igor Gnatenko wrote: > > > repo system 0 testtags > > #>=Pkg: foo-static 1 1 x86_64 > > repo available 0 testtags > > #>=Pkg: bar 1 1 x86_64 > > #>=Obs: foo-static > > #>=Pkg: foo-static 2 1 x86_64 > > system x86_64 rpm system > > poolflags implicitobsoleteusescolors > > solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy > > keeporphans yumobsoletes > > job update all packages > > result transaction,problems > > #>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available > > #>install bar-1-1.x86_64@available > > Here again, a single test is insufficient, if there is no commentary > that > explains what the defined behaviour of the RPM backend is and that > there > is no alternative solution. Only with documentation of defined > behaviour > one could conclude that no other solution exists and that the shown > behaviour matches the test target. > > If wanting to move forward, anyone raising doubts about the current > handling of non-versioned Obsoletes tags (and Obsoletes tags in > general) > during update transactions, would need to start at the very beginning > and > analyze how RPM (_not_ only "rpm -Uvh") can handle Obsoletes in sets > of > installed *and* available packages. Based on that, one can come up > with > strategies for depsolving based on repo/package metadata, such as > evaluation order of PRCO or whether and when to ignore older NEVR of > a > package where multiple EVRs are found. That wasn't call to change anything, it was example why we MUST stick with versioned obeolstes. RPM behavior is not interesting because it is just evaluating constraints, nothing else. Interesting thing is depsolving - libsolv. > > Some day I've had a fruitless discussion with Seth Vidal about > behaviour > of "yum install foo" and whether it should fetch only the very latest > package that provides "foo", evaluating Obsoletes and updates > already, > or whether it may install any old EVR it finds in the repos and only > handle available updates/uprades and Obsoletes in subsequent "yum > update" > runs. Yum, for example, installed an old package release only to > replace > it with an available update immediately afterwards when running "yum > update". > Some of the behaviour of tools is based on arbitrary definition by > developers and possibly not because of strict technical requirements. > Behaviour could be changed, but not without agreement from the devs. > If > you want to change something about handling non-versioned Obsoletes, > the > whole thing must be examined at a much deeper level and under > consideration > of any documentation there may be that gives a rationale about the > behaviour > of current tools and backends. I don't want to change anything, I'm pretty happy with current guidelines (moreover, I was asking to make ALL obsoletes versioned some months ago but didn't got to the point of mass bug filing). > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljiFj4ACgkQaVcUvRu8 X0yAoA/+Kcddo90AS9tBg7XLLn39P9sR/ly+i4n7en8sGr1C8PEWV0N3J4914UjR /lAxW4s62evq4/d9xKhWI+EGIcufCweS8/egpJq3EVmStSujJoPZJlhoxiwKQeWV MHxr5iPuu/oUeDCHecXHkfhGC3bG1ok6PjTvC129ABEYhJrSEkA1rC9yZgUm3pFa l3MrPIoT+R9SzTjYaIFYSI6drE9hnU+sF9aVMYfPzSdLiSM2Mi0oj7bVU28mhxJ3 9O6BkHowXOFP3s7WA2asBSw7LETe74htXGRmlEovppcJwYmd12qHF7EM+YakfMVk rBxkM4JEmPjGjp9GVRvtLWHf+FTo41amz+i+WU6Caaa1M7APymoy+sVk5Dlu4iM1 Tfpzj/Y8FlzI6bPcqu7YuKHF7ckWRlXY8h/gVspBFm1RZPxy8WnTpCEUGZ9L0C4r GycIREUYFWMk82Vu822qJwGSx4TmqDfcsvyNSgsUdxqRL9L051LC3cKtmohl+vJn BWJWTTu5fWf0eUFDwzwhGHpL+9zKeUkxSZnkIFnc/Fm+FalcXLZQTeZbKqhXR6rs PKDwkP2guLmrxCGjpnSMk/qaDamZuQPYrpXecVlF+5L9Lke/mqKdHrmHN7F8smcN 1UkkBSF9meITMlnvJTSJzEdOwv9DSh8Ok44c4hhRiTlq0Cv/U1I= =HhcG -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass issue: /usr/bin/env dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2017-04-02 at 07:55 +0100, Tomasz Kłoczko wrote: > On 1 April 2017 at 22:25, Neal Gompa wrote: > > > This is a libsolv test case. Fedora's high level package manager > > (DNF[0]) uses libsolv[1] for its resolver engine. If you're trying > > to > > determine how something is going to behave, you can write a test > > case > > and use testsolv (in the libsolv-tools package) to run the test > > case > > and see what the solver would do. It gives you the ability to > > reproducibly replay any kind of solution scenario. DNF will output > > libsolv test cases for a given action when "--debugsolver" is added > > as an option to the command. > > > > And from your prev Igor email: > > And please, stop spreading misinformation! As I said earlier, you > have > > to prove your information to FPC (which implies confirmation from > > DNF > > developers). > > > So .. looks like: > 1) your test case does not test what I've been testing (did you > really > download, try and look at it?). > 2) Igor as well seems not been trying to test anything. I showed you testcase where if you don't use versioned obsoletes, you can't re-introduce back original package. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljg3yoACgkQaVcUvRu8 X0ydLw/8DvpsEIGzm0jzK49OlqX3ELzLEHIsEUm96l49QSBbKcrLxSNx1vP+jn6B wfl7YS4JvglU83yrmcZYlQRqEhpbclRxqOYhYvQ5/MjOqVlnjD2yXbARKNoIoFoa YeWaTkm4JLtxP4aLyxQHq7ccHiNKhm1+RMQaQRYS6gBDI6JMs5YCXM3sMyeKl5NP dxBZfBUDTYNnh3PA4jvWcgAQTnv5Qmd9dCqMT72f+nSebsOqn1dBwQsL/bgTNkp1 idCorJbBDhGGUxpvS4egxDLjfSyoZl7bfhUhU1WBaLMHyL2oye7r5eCclr6b3I75 C3Ytp+8/r75meidSzmfSyxeXCXCQiZWfAqraYkLcVpB9QGFKy4gaMbe4BPXGZEUB hU4YAqQKKWeMg9xw+X/6m7jDdYq5pAWOOJ2V1iXSN+lj3/k3HoG6OBFQnddBAX2d uRCa3annCKzVBnZlRA53HH5yaNYMG9DkkucQTIAPRAk9dKe/SpKZJLHmXvygrGJf f5OgaLmfzgNXXEu4RqQWjfeKhPfY/z/DQpcgQvNO05yvEzAkNHKp1QMO77LiNtQ0 UaYcYVmBRzZvh5USYtfkop6He1/muO80O/OmmBBY1flrHXnIKpUR0/z8rBoM32VP sG0bbLGSMbxdgV8zuTPqiiYrMrJ9JkzKwgJN/OEzh4wCHomAIq8= =4h9b -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass issue: /usr/bin/env dependency
is correct message: > > Obsoleting : test-static-1.0-1.x86_64 > 3/5 > > Now I have much more questions but I have only few minutes. > Seems today in UK will be nice sunny day so maybe will try to write a > bit > more late evening or tomorrow morning. First I need to read a bit > more > about libsolve and few other new pieces. Don't bother. All your points here are basically going to /dev/null if you are not going to contact FPC. You can be even right in some aspects, but just telling people here that they are stupid and only you are right is not leading anywhere. > > I'll write first one: > Why dnf guys started playing with writing from scratch completely new > resolver, recommending even dnf as new package manager (which implies > rpm > obsoletion .. soon; I'm sure that many people are not fully aware of > this) > instead extracting base resolver from rpm code and wrapping it by new > code? > (First sentence which I've learn during my first job in UK was "don't > move, > improve") > dnf used to be only adding on top of raw rpm possibility to operate > on > packages repositories. For some reason someone decided to replace rpm > adding of course in new code bugs which even 20 years ago in rpm > implemented in perl not been present. * No one replaces RPM * RPM doesn't have depsolving algorithm(s) > > kloczek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljg3oEACgkQaVcUvRu8 X0zE5g//Qw7sTL0x4u7mfewzVswLZL+Va/dFek2ovvlwmA1dUhg3LZfsyOrI7O3D BWbx4zvYGM7VvJNISDXurAb4ccr58nWaqKDsURJtJUPAH4yUUiVp1vz7ZqrymiFu gmF8uwxsAKgFL7NYwBpLEki8xz22mYWKkpZ/RBzuN/C5T3Az3hziCVFkfFg4IrJP y3FybCLNaJtsnj0NZFhTl//QYMlgFgqKI0mKNlmc3E3DmdVKddy52z58NWxHbzwY H85zxetO+c+9TvWYFC5UIoZdiI3jnV2AtFhkglB/zimonsW3K9q4581xrCe8zDso V5RNQExvequjM+cIbUQJZbmi6A8henzlfDiAgLtOAVYKX3xBwGdE4gjOMp92DJQM UPCcgFrYhTThpQvU5F2IWimMjiYQ/sPauwyMaRy4EsG9zscCOyRmyCxeoh44KbHC IqVPWyx9c1LyJoGoyULfdrM146FqSRNQsdaL2YdPA5VGstyG2IYQxRe0BB4Ch57g ocUsFBE3m1n5zIKpicTavATWR2LXSX5OG9NMYY7I3TwzoRGE6pRqYPzqKfafvFL7 w7JZPwQsVEey5IL4+GCfC013VXSmmEiA02ILreXWAQRejzBaOEb7QBzTCkoorEf7 uo87Eok5C7uSLGQToHL4HMOJQY+2v9KpMXHpoYt5RACFIFd3uuA= =+D8J -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass issue: /usr/bin/env dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2017-04-01 at 15:52 +0100, Tomasz Kłoczko wrote: > On 1 April 2017 at 08:19, Michael Schwendt > wrote: > > > In reality, that's not case always. In order to remove a previously > > > > introduced Obsoletes tag, you would need to do what exactly? > > > > I've already wrote this straight. Quote: > > "So exact paragraph in FPG should be not about using versioned > Obsolete > rule but should contain straight rule that "resurrecting" package > should > cause remove Obsolete rule as consequence such decision." > > I've as well implemented and posted test case which presents how such > cases > should be implemented. > In other words: despite natural language explanations (which I've > gave > probably 3-4 variants) you have "by example" demonstration with which > you > can play or modify presenting that after modification something is > not > working ass expected. > Please start playing with those specs files which I've posted. > *Do not trust my words and please rely ONLY on what you can > execute!!!* > > I fully understand that it is not easy to understand some new > approach if > so long so many people been using some other variant which suppose to > be > correct but is not. > > One more time: posted here test case works and does not need > versioned > Obsoletes rules. > Does it really not lights up some bulb inside your mind? .. maybe at > least > some small spark? > > Reality is that Fedora have been using wrong solution such scenario > that > now many people mentally have problem with accepting that it is > other/better/simler solution. Such communal effect is *well known* in > psychology. > > If you want to proof that I'm wrong just *please do not continue > sending > next comments* in this thread. It is completely pointless!! > Take test case which I've posted and modify it to the state when it > will > start producing not expected results or change something in context > of the > packages in which such short test is executed. > So far no one here even one time posted something which may look like > like > producing not expected results. > > We've come a long way, and returning to day zero and repeating some > > mistakes is not a good idea. > > > Look .. Fedora exist only 14 years. > People been thinking that the Earth is centre of the Universe for > thousands > years. > If something IS wrong time has no matter. > Time, trust, number of people .. those things should not be brought > here as > an argument. Because it is not the "nec Hercules contra plures" case. > No .. as I've been able implement and post test case with results > *I'm > longer not a side of this dispute*. Do you see this? > At the moment you are trying to convince this ~1KB of tar.xz archive > to > start producing different results than I've posted. > It takes only few seconds to download attachment and execute what is > inside. (Rhetorical question) Did you try do this? > If yes .. did you try after this spend few seconds asking yourself > "why > this annoying guy implement this exactly that way? Why it works? Can > this > test work correctly in case all past cases which caused writing some > part > of FPG? Can it work always?" > > To everyone: instead spending time on writing reply *please* invest > exactly > the same time to execute and analyse what is inside this tests .. repo system 0 testtags #>=Pkg: foo-static 1 1 x86_64 repo available 0 testtags #>=Pkg: bar 1 1 x86_64 #>=Obs: foo-static #>=Pkg: foo-static 2 1 x86_64 system x86_64 rpm system poolflags implicitobsoleteusescolors solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes job update all packages result transaction,problems #>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available #>install bar-1-1.x86_64@available And please, stop spreading misinformation! As I said earlier, you have to prove your information to FPC (which implies confirmation from DNF developers). > kloczek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljf6VQACgkQaVcUvRu8 X0zUag/+Nqp4BYYMnJN6C4SmRUcQbTS5TlPaCEiuCOGv+o84EbWnQ2/7JqTglNu7 w8iOeNF+3Dp+krt3oqSDPSxn7RNFKu/uiZiDqqx7YSGqcIlZRHT04C42KlmaKXYN tGWXyWdz0uudV1hMYYzmd/iHNvfr0PJ34ukbdPcc+z0+CuJZPwQKJDRp+f6eNWBM bq1K0BHJOjkT6JU+94Gzj/cYK9KKT+SHQDehrYKZh2BPRVdd7HQFSqVeMqooYSC1 1eaMEBT1kTXkgA5
polkit doesn't start with :0: can't open init.js: No such file or directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This appears in journal after some of last updates. Did anyone experience such problem? Also logs are full of things like: org.gnome.SettingsDaemon.Power.desktop[1836]: Error executing command as another user: Not authorized org.gnome.SettingsDaemon.Power.desktop[1836]: This incident has been reported. polkitd[938]: :1: ReferenceError: Action is not defined polkitd[938]: Error converting action and details to JS object: Evaluating 'new Action();' failed pkexec[3538]: brain: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/brain] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 321] P.S. workaround is to put https://cgit.freedesktop.org/polkit/plain/src /polkitbackend/init.js?id=0.113 into /init.js, though it doesn't fix work of polkit (only allows my laptop to start) - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljewl8ACgkQaVcUvRu8 X0wvKQ/+KlWVGXL+Y+XiW2LdwuXXqHC4CiVB9BcxwUec/nce6/rQk1dA533R5QHB 8SxPYVR03Ju66uSj0CRta5udm/Ip4/kCW1MNfOdsSqpzDSiSMNwzDCqmNxBBnMZc /r0stp3dcEe9JKQJ0u0BgIPnNTzsQA3yBPDtVgZLHdrsyDfZhOmgrd5LZVrSiUXv 8N1G65lmUsYRCe+p3iTYYVWFPihEXD12EjQfaDiDLred6ILewxiIG3HKJdAgFnjX 307nmu4gS8UmkYoPBo9yMAFwRTAVNVO3bf8S3IH+TaJBoOiHVVbEgt7Y3ziuP+/7 oXGio1tW+OdTCNyEUloPdCPcujTRiBtMYcMwvwTeuShRAGPE2z4IV2fd9AiA2fxD 5cxsPyTz3pMUhDnRVXPUUqfanftApG0Ynwjy3CaOe9zKYab5I8FpZuHiFxLjYpKV +hsSfKjUf322KUhr72ITOEO0ReQrplcuxe5jSZFbKPPhVWdaBfrM8RGBSftA1b0P vVPTdvCyLdGpsV87EzaRjWnA2zOHqanYvKeOLQjti7edGPwrXhxvbTA3D6ZDU+b9 tj30XymwTAkwdb5Dg+dmg79hSnnuzEwaRij9IXbd1ZAo2VGyjrNt8J4aQSt0/2Et bZKbaPv9ohxclWTSAxisUBl25LhMQWmdEjhMA3P044zawnAf5dc= =BjgS -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)
kage. > > Result: > > $ sh ./test-ver.sh > Preparing... ### > ## > [100%] > Updating / installing... > 1:test-1.0- > 1 # [ > 33%] > 2:test-devel-1.0- > 1 # [ > 67%] > 3:test-static-1.0- > 1# > [100%] > test-static-1.0-1.x86_64 > test-devel-1.0-1.x86_64 > test-1.0-1.x86_64 > Preparing... ### > ## > [100%] > Updating / installing... > 1:test-2.0- > 1 # [ > 20%] > 2:test-devel-2.0- > 1 # [ > 40%] > Cleaning up / removing... > 3:test-static-1.0- > 1# [ > 60%] > 4:test-devel-1.0- > 1 # [ > 80%] > 5:test-1.0- > 1 # > [100%] > test-devel-2.0-1.x86_64 > test-2.0-1.x86_64 > Preparing... ### > ## > [100%] > Updating / installing... > 1:test-3.0- > 1 # [ > 20%] > 2:test-devel-3.0- > 1 # [ > 40%] > 3:test-static-3.0- > 1# [ > 60%] > Cleaning up / removing... > 4:test-devel-2.0- > 1 # [ > 80%] > 5:test-2.0- > 1 # > [100%] > test-3.0-1.x86_64 > test-devel-3.0-1.x86_64 > test-static-3.0-1.x86_64 > > As you see result is EXACTLY the same. > In attachment you have tar with 4 spec files and two test scripts. > It is some possibility that you may be right in some scenario which I > still > do not understand so please try to change test case to the form when > it > will start failing presenting exact scenario which is possible to > correct/avoid by using versioned Obsoletes. > PS ATM I'm ready to bet with at least 1:10 ratio that it is some > misunderstanding of some very simple case. > So I'm moving my words one step back and putting this case in WIP > state > asking for exact example implemented in test case. > > > > > BTW Epoch. Using Epoch is only for scenario when it is necessary > > > roll > > > > back > > > to earlier version of *the same package* when such package *is > > > > installed*. > > > > That's not true either. A package doesn't need to be installed at > > all, and > > it doesn't need to be the "same package". In repo metadata highest > > EVR > > wins version comparison. Again, depending on how the package tools > > and > > depsolvers are implemented, you would not even see a package due to > > its > > EVR. Also, there's the scenario of package splits, such as a > > library > > getting released as a separate project with an own versioning > > scheme, > > and Epoch is the only way to handle that, regardless of whether a > > package > > is installed already. > > > > If package is present in rpm database only in form of "Provides: > A--" for resolver effectively it is like such > package is > really installed. Ergo: it changes nothing. In both cases will be > done > exactly the same operation o resolving packages dependencies and > write new > state of installed packages. Please provide libsolv testcases (something like https://github.com/ope nSUSE/libsolv/blob/master/test/testcases/yumobs/split.t), create FPC ticket, attach testcases, their results and proposal (new wiki page regarding guidelines), subscribe DNF developers and only after that we can talk about anything. > > kloczek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljeqSYACgkQaVcUvRu8 X0xq0A//b9RBpFX7XVQDPKQw2K1vlefaZmr6/zwq4qURKnnf1yFRTa1noH1lY/kw jTa8azbXJuRN046AN3xhxmRhl6wsx5rpmAUl+s2Kvy2r3XF9oJqPPfLOObke85tL f5WnOdAsHfFaAJlAv1H/YCpF8kfxoc3hhDWPZp0YmVwOyQOVdLh+b0hRKvXgPKQz dO9v+FQAcA/PuHvNcJDTs3zHbsBJv7QHQ2E9Bi4IAO9oJEaW8o/ObHj7dkM6NFrU 2C5PPRAE+dnqDO7NGUA5jY/MXDeiXTgU0HJTvaqinQYmrGueSwYfzUauUlVDbSLN ndl9oaBnPJPsB/53ovviMgSKg4EbAL4P7NRcUgbLwJjQ1eH4DwNifK9oh7sCuea8 u59QXnN97rEQH7rW3UpxhSeJQTO2sE32/Ug8QC8Zb4WOn3cljVeHrcqH6BO8Xn1n eN0yaaIjbWyXlwX88uR/wZu80M0Gy3GdvtxZ8hoQDiO0X0iRs050QCP5Rb9uS2mF EDKgcAjdNsXHBiEGcDXWKDF/70FnspZFRKvEhNkH9vZpzJ+47hkTXPmH52EJQYoW 0tJ2TN1pUvuCWX9M5uKmqNX1qD/pQG+kW+CwvWb2eLXyss6BI0wpWOoSONTo7siY qEXqhWYuOeKFtn461G+mMktJ2ESmRfg768EQQaVNSeh+7b53hDM= =TxfK -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Wrongly handled LLVM update [Fwd: [Fedora Update] [CRITPATH] [comment] llvm-3.9.1-1.fc25]
> The following comment has been added to the beignet-1.3.0-4.fc25 > clang-3.9.1-1.fc25 compiler-rt-3.9.1-1.fc25 gnome-builder-3.22.4- > 2.fc25 kdevelop-5.0.4-3.fc25 lldb-3.9.1-1.fc25 llvm-3.9.1-1.fc25 > mesa-13.0.4-2.fc25 pocl-0.14-0.3.git3fef5b5.fc25 qt-creator-4.1.0- > 2.fc25.2 rust-1.15.1-1.fc25.3 update: > > bodhi - 2017-03-14 17:23:50.280569 (karma: 0) > This update has been pushed to stable. Why it got pushed to stable? * gnome-builder now has broken dependencies which is not acceptable * F25->F26 upgradepath is broken > https://bodhi.fedoraproject.org/updates/FEDORA-2017-82d76412cf > -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170220.n.2 compose check report
qa.fedoraproject.org/tests/57196 > ID: 57197 Test: x86_64 universal install_ext3 > URL: https://openqa.fedoraproject.org/tests/57197 > ID: 57198 Test: x86_64 universal install_xfs > URL: https://openqa.fedoraproject.org/tests/57198 > ID: 57199 Test: x86_64 universal install_lvmthin > URL: https://openqa.fedoraproject.org/tests/57199 > ID: 57200 Test: x86_64 universal install_package_set_minimal > URL: https://openqa.fedoraproject.org/tests/57200 > ID: 57201 Test: x86_64 universal install_anaconda_text > URL: https://openqa.fedoraproject.org/tests/57201 > ID: 57204 Test: x86_64 universal install_no_swap > URL: https://openqa.fedoraproject.org/tests/57204 > ID: 57207 Test: x86_64 universal install_simple_encrypted@uefi > URL: https://openqa.fedoraproject.org/tests/57207 > ID: 57208 Test: x86_64 universal install_simple_free_space@uef > i > URL: https://openqa.fedoraproject.org/tests/57208 > ID: 57209 Test: x86_64 universal install_multi_empty@uefi > URL: https://openqa.fedoraproject.org/tests/57209 > ID: 57210 Test: x86_64 universal install_software_raid@uefi > URL: https://openqa.fedoraproject.org/tests/57210 > ID: 57212 Test: x86_64 universal install_btrfs@uefi > URL: https://openqa.fedoraproject.org/tests/57212 > ID: 57213 Test: x86_64 universal install_ext3@uefi > URL: https://openqa.fedoraproject.org/tests/57213 > ID: 57214 Test: x86_64 universal install_xfs@uefi > URL: https://openqa.fedoraproject.org/tests/57214 > ID: 57215 Test: x86_64 universal install_lvmthin@uefi > URL: https://openqa.fedoraproject.org/tests/57215 > ID: 57216 Test: x86_64 universal install_no_swap@uefi > URL: https://openqa.fedoraproject.org/tests/57216 > ID: 57217 Test: x86_64 universal install_kickstart_hdd > URL: https://openqa.fedoraproject.org/tests/57217 > ID: 57218 Test: x86_64 universal upgrade_minimal_64bit > URL: https://openqa.fedoraproject.org/tests/57218 > ID: 57220 Test: x86_64 universal upgrade_server_64bit > URL: https://openqa.fedoraproject.org/tests/57220 > ID: 57223 Test: x86_64 universal upgrade_2_minimal_64bit > URL: https://openqa.fedoraproject.org/tests/57223 > ID: 57228 Test: x86_64 universal install_updates_img_local > URL: https://openqa.fedoraproject.org/tests/57228 > ID: 57229 Test: x86_64 universal install_shrink_ext4 > URL: https://openqa.fedoraproject.org/tests/57229 > ID: 57230 Test: x86_64 universal install_shrink_ntfs > URL: https://openqa.fedoraproject.org/tests/57230 > ID: 57234 Test: x86_64 universal > install_kickstart_firewall_disabled > URL: https://openqa.fedoraproject.org/tests/57234 > ID: 57235 Test: x86_64 universal > install_kickstart_firewall_configured > URL: https://openqa.fedoraproject.org/tests/57235 > ID: 57236 Test: x86_64 universal install_kickstart_nfs > URL: https://openqa.fedoraproject.org/tests/57236 > > Passed openQA tests: 22/85 (x86_64) > > Skipped openQA tests: 2 of 87 -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: heads up: update of python-docker-py to 2.x in rawhide
On Wed, 2017-02-15 at 14:32 +, James Hogarth wrote: > On 14 Feb 2017 11:24, "James Hogarth" > wrote: > > > > On 14 Feb 2017 09:28, "Tomas Tomecek" wrote: > > Quoting James Hogarth (2017-02-13 18:02:23) > > On 13 February 2017 at 16:40, James Hogarth > m> > > wrote: > > > On 13 February 2017 at 15:36, Tomas Tomecek > > > wrote: > > > > Hello, > > > > > > > > am planning to update package python-docker-py from 1.x series > > > > to 2.x > > series in > > > > rawhide. The update should happen rather soon, so we're sure it > > > > gets > > to F26 (and > > > > hence we can have docker-compose 1.11 in F26). The reason this > > > > is > > important is > > > > that 2.x is not backwards compatible with 1.x. Here is a list > > > > of > > breaking > > > > changes: > > > > > > > > https://docker-py.readthedocs.io/en/stable/change-log.html#b > > reaking-changes > > > > > > > > > > > > Here is a list of affected packages: > > > > > > > > $ dnf repoquery --whatrequires \*docker-py > > > > atomic-0:1.15.2-2.fc26.x86_64 > > > > docker-compose-0:1.9.0-3.fc26.noarch > > > > flr-0:0.0.1-1.fc26.noarch > > > > python-atomic-reactor-0:1.6.19-5.fc26.noarch > > > > python-dockerpty-0:0.4.1-4.fc26.noarch > > > > python2-docker-squash-0:1.0.5-3.fc26.noarch > > > > python3-atomic-reactor-0:1.6.19-5.fc26.noarch > > > > python3-docker-squash-0:1.0.5-3.fc26.noarch > > > > python3-dockerpty-0:0.4.1-4.fc26.noarch > > > > python3-sen-0:0.5.0-1.fc26.noarch > > > > > > > > > > > > Maintainers of these packages, shall I help you with porting to > > docker-py-2? > > > > > > > > > > > > (This is the third time I'm trying to send this e-mail, this > > > > time > > without CCs; > > > > sorry if spamming) > > > > > > > > Since I'm resending, I already managed to rebase the package > > > > and all > > the changes > > > > are in dist-git. Will submit a build once we are sure the > > > > update > > doesn't break > > > > anything. > > > > > > > > > > > > > > Since this is a breaking change in the module and upstream have > > > formally renamed from python-docker-py to python-docker might I > > > suggest that it is more appropriate to issue a fresh package > > > review > > > for python-docker (which can then in due course perhaps obsolete > > > python-docker-py or at least just retire it without obsoleting) > > > would > > > be more appropriate? > > > > > > This will break the scripts of anyone using the docker python > > > module > > > after all ... > > > > > > Related to this are you aware of any plans to rebase from 1.9.0 > > > in RHEL > > extras? > > > > Further to this looks like the F26 mass rebuild picked up this > > change > > by accident ... > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=854128 > > > > At the very least you need a self-contained F26 FESCO change ticket > > for > > this ... > > > > The correct procedure, given upstream has renamed, is to epoch bump > > this back to 1.10 and then to do a package review for python-docker > > though ... > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Oh! > > Thanks for letting me know. > > The rename is actually a really good point. What bothers me is that > upstream git > repo is still named docker-py, same for documentation. PyPI package > is named > docker, as you pointed out. They even check if the 1.x series is > installed: > > https://github.com/docker/docker-py/blob/master/setup.py#L12 > > So let's rename then. I will submit new review. But first let's fix > rawhide. > > Regarding RHEL extras: not sure; first I want to make it happen in > Fedora, > then > wait for everyone to get used to it (especially atomic command). The > thing > is > that plenty of tools and scripts in RHEL ecosystem use this library. > I don't > want to break those. If this bothers you, feel free to open bugzilla > and we > can > discuss there. > > > Thank you, James. > > > Tomas > > > No problem and great stuff > > Feel free to cc me when you submit the review and I'll be happy to > pick it > up. > > I have scripts that use this in my workplace so useful to know when I > might > need to update them :) > > > > I see you've submitted the review request > > I've grabbed it and will do the review this evening. Can you stop using HTML please? It makes all messages just to loose quoting which makes messages unreadable... > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
clinfo license change from Public Domain to CC0
https://github.com/Oblomov/clinfo/commit/946961fff88d54b480011a5a1748920bcfe4350a Since clinfo-2.1.17.02.09, it's CC0 and not Public Domain. Just FYI. -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
On Wed, 2017-02-08 at 09:55 -0500, Daniel J Walsh wrote: > What is going on with this Change Request? Any reason it has not been > acted on at this point? We are putting changes into our packages > assuming that this will be allowed. Given that it is in category "ChangeAcceptedF26", just go ahead and push changes ;) Once it's done, change status of tracking bug (https://bugzilla.redhat.com/show_b ug.cgi?id=1419514) to MODIFIED. > > > On 01/06/2017 05:08 PM, Igor Gnatenko wrote: > > On Fri, Jan 6, 2017 at 9:29 PM, Daniel J Walsh wrote: > > > https://fedoraproject.org/wiki/Changes/DockerOverlay2 > > > > Thanks! Note, that you will need to send it for wrangler. > > > > > > On 01/06/2017 02:27 PM, Igor Gnatenko wrote: > > > > > > Shouldn't this be submitted as a change? > > > > > > This would bring much more visibility to users of Fedora and even outside. > > > > > > -Igor Gnatenko > > > > > > On Jan 6, 2017 8:13 PM, "Daniel J Walsh" wrote: > > > > Upstream docker is moving to overlay2 by default for its storage. We > > > > plan on following suit. Their are some performance advantages of > > > > overlay2 over devicemapper in memory sharing, which we would like to > > > > take advantage of. We now have SELinux support for Overlay file > > > > systems, so the security should be just as good. > > > > > > > > Note: Overlay is not a Posix Compliant file system, so their could be > > > > problems with your containers running on overlay, so > > > > we want to make sure it is fairly easy to switch back to devicemapper. > > > > > > > > Devicemapper out of the box, on Fedora Workstation, currently defaults > > > > to loopback devices for storage, which has a performance penalty, but > > > > this was the only way we were able to get docker to work right away. > > > > Switching to overlay2 will cause the storage to be shared with / and > > > > will eliminate this performance overhead. This is the way we will ship > > > > Fedora Workstation. > > > > > > > > On Fedora atomic host and Fedora server we have been storing > > > > devicemapper storage on a separate partition. We plan on doing the same > > > > thing with overlay2. This means separate device will be mounted on > > > > /var/lib/docker. This will make it easier for someone to switch back to > > > > devicemapper, if overlay2 has problems. > > > > > > > > Upgraded systems will not be effected. > > > > > > > > If you want to switch from one storage to another take a look at the > > > > `atomic storage` commands. > > > > > > > > We will write up release notes to cover this change. Along with a blog > > > > explaining the commands to switch back and forth. > > > > ___ > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > > > > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > > > > > > > > > -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] libgit2 stack has been updated to 0.25.x in Rawhide
On Wed, 2017-02-08 at 10:57 +0100, Vít Ondruch wrote: > > Dne 7.2.2017 v 17:14 Igor Gnatenko napsal(a): > > + rubygem-rugged > > . Updated to 0.25.1.1 as well > > From yesterday's compose. > > [rubygem-github-linguist] > rubygem-github-linguist-5.0.2-1.fc26.noarch requires rubygem(rugged) = > 0:0.25.0b10 It happened even before... I got message about this more than 1 month ago. It's bug in rubygem-github-linguist. I guess some automatically generated dependency. > > > It is probably better to check more then just first level of > dependencies I did and thing is that it's not related to rebase of libgit2 stack. Before we had 0.24.6 of rubygem-rugged and there were missing dependencies. > > > Vít > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] libgit2 stack has been updated to 0.25.x in Rawhide
libgit2 - cargo . Needs re-bootstrapping because of circular dependencies + geany-plugins + git-evtag - julia . Error: nothing provides libgfortran.so.3()(64bit) needed by openblas-threads- 0.2.19-4.fc26.x86_64 - kf5-ktexteditor . No matching package to install: 'kf5-kparts-devel >= 5.31' - kate + libgit2-glib . Still 0.24.x based, but with backported patch (uses libgit2-0.25) - gitg . Doesn't need to be rebuilt - gnome-builder . Doesn't need to be rebuilt + python-pygit2 . Updated to 0.25.0 as well + rubygem-rugged . Updated to 0.25.1.1 as well - subsurface . qt-ui/globe.cpp:207:5: error: 'GeoDataLineString' was not declared in this scope Enjoy! -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: question about dnf builddep with some deps missing on some arches
On Mon, 2017-02-06 at 12:54 +0200, Panu Matilainen wrote:
> On 02/06/2017 01:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, Feb 05, 2017 at 11:02:16PM +0100, Igor Gnatenko wrote:
> > > On Sun, 2017-02-05 at 18:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > > systemd.spec file has
> > > > %ifarch %{ix86} x86_64 aarch64
> > > > BuildRequires: gnu-efi gnu-efi-devel
> > > > %endif
> > > >
> > > > ... and this seems to work fine in mock/koji/etc.
> > > >
> > > > dnf builddep deals file with an srpm built on the architecture:
> > > > $ fedpkg clone -a systemd && cd systemd && fedpkg srpm
> > > > $ sudo dnf builddep *.src.rpm
> > > > (ok)
> > > >
> > > > But the following command fails on ppc64le:
> > > > $ sudo dnf builddep systemd
> > > > No matching package to install: 'gnu-efi'
> > > > No matching package to install: 'gnu-efi-devel'
> > > > Not all dependencies satisfied
> > > > Error: Some packages could not be found.
> > > >
> > > > I'm confused: this seems like an error in dnf, or am I doing something
> > > > wrong?
> > >
> > > SRPMs are distributed only once, so it's matter of luck which one will be
> > > distributed.
> >
> > Hm, OK. I see why it is like this, but this limitation makes the
> > command much less useful. Maybe at least the dnf.plugin.builddep man
> > page should warn about this?
>
> I'd say dnf builddep should by default extract the spec out of the
> src.rpm and parse the spec locally for build-deps. There needs to be an
> option for using the metadata in src.rpm directly though, because using
> it IS perfectly sane when you do it like the buildsys does.
But it means that you need to have all BuildRequires installed in order to run
all scrips which are used from spec.
Moreover, it's security hole.
>
> - Panu -
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: question about dnf builddep with some deps missing on some arches
On Sun, 2017-02-05 at 18:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> systemd.spec file has
> %ifarch %{ix86} x86_64 aarch64
> BuildRequires: gnu-efi gnu-efi-devel
> %endif
>
> ... and this seems to work fine in mock/koji/etc.
>
> dnf builddep deals file with an srpm built on the architecture:
> $ fedpkg clone -a systemd && cd systemd && fedpkg srpm
> $ sudo dnf builddep *.src.rpm
> (ok)
>
> But the following command fails on ppc64le:
> $ sudo dnf builddep systemd
> No matching package to install: 'gnu-efi'
> No matching package to install: 'gnu-efi-devel'
> Not all dependencies satisfied
> Error: Some packages could not be found.
>
> I'm confused: this seems like an error in dnf, or am I doing something wrong?
SRPMs are distributed only once, so it's matter of luck which one will be
distributed.
>
> dnf-2.0.0-2.fc26.noarch
> libdnf-0.7.0-0.7gitf9b798c.fc26.ppc64le
> dnf-plugins-core-1.0.0-0.rc1.2.fc26.noarch
> python3-dnf-2.0.0-2.fc26.noarch
> python3-dnf-plugins-core-1.0.0-0.rc1.2.fc26.noarch
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Copr f26 with pkgconfig
On Fri, 2017-02-03 at 12:07 +0100, Didier Fabert wrote: > Hi there, > > I'm unable to build netdata package for f26 on copr. The error, in file > root.log.gz, was about pkgconfig: > > Error: package pkgconf-pkg-config-1.2.1-1.fc26.x86_64 conflicts with > > pkgconfig < 1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.x86_64 > > Yes, pkgconfig is explicitly mark as BuildRequires. > > Does anybody have an idea to solve this problem ? Someone needs to update COPR builders... > > Full logs are https://copr-be.cloud.fedoraproject.org/results/tartare/netdata/ > fedora-26-x86_64/00506909-netdata/ > > Sincerely, > > Didier. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[IMPORTANT] dnf segfaults in rawhide (strlen() SIGSEGV)
Hello, today after updating my system, dnf started segfaulting. I debugged it a bit and found out that it is not dnf/libdnf's fault, but glibc's[0]. If dnf started crashing for you, just use --refresh in command-line or downgrade glibc from -29 to -28. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1417870 -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 25 Koji buildroots broken…
On Tue, 2017-01-31 at 09:42 +0100, Hans de Goede wrote: > Hi, > > On 30-01-17 20:41, Rex Dieter wrote: > > Kevin Kofler wrote: > > > > > That is not true. Mesa is composed of multiple subpackages. The > > > updater I > > > used (plasma-pk-updates) happily updated mesa-dri-drivers to the > > > new build > > > and kept the old builds of mesa-libGL and mesa-libGLES that > > > provide the > > > libGL libraries. Though to be fair that does not seem to have > > > actually > > > broken anything. > > > > This issue could be fixed in mesa packaging (that would enforce > > that all > > subpkg components be updated together). I can help implement that, > > if there > > is a consensus that would be a "good thing(tm)" > > Igor Gnatenko co-maintains mesa now a days, I'm pretty sure he will > happily accept a patch tightening up the inter-pkg dependencies. > > Igor, can you confirm (or deny) this please ? Sure, just send a patch and if it looks good -- I will happily apply it! :) > > Regards, > > Hans -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Rust SIG
Hello everybody, we are establishing new SIG for Rust[0]. Feel free to join us on IRC (#fedora-rust) and/or Mailing List (r...@lists.fedoraproject.org). Help with improving our wiki page is very welcomed ;) [0] https://fedoraproject.org/wiki/SIGs/Rust -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: How to build both python 2 and 3 bindings from autotools?
On Thu, 2017-01-26 at 09:10 +1000, Peter Hutterer wrote: > Before I start hacking up something nasty I figured it's better to > ask: how > do I build both py2 and py3 bindings from a package using autotools > (i.e. > AM_PATH_PYTHON)? I think it's better to not use automake's stuff for this and use distutils/setuptools (this is btw, how gpgme and rpm does). gpgme also integrates it into makefiles, but that's something what I would like to not deal with... in RPM we just run pythonX setup.py build/install during build/install process. > > So far my idea revolves around installing both python-devel packages > and > overriding PYTHON in each %build , etc. But maybe > there's a > simpler solution? > > Package in question is evemu and yes, we are also the upstream > maintainers > so if there's a more sensible solution we can move that into > upstream. > > Thanks > > Cheers, > Peter > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Diagreement with pkgconfig removal
On Mon, 2017-01-23 at 11:10 -0500, Frank Ch. Eigler wrote: > praiskup wrote: > > > [...] > > Cool. Let's provide 'pkgconf' so we can be also three, too! But > > at the > > same time please consider not dropping 'pkgconfig' for no reason. > > ... and also let's make sure that the new package does not break > builds. > For one of ours, the .spec file contained: > > BuildRequires: pkgconfig > BuildRequires: foo-devel > > Yes, this is not canonical pkgconfig(foo) & perfect & stuff, but it's > worked for years. With the new changes, it breaks builds: > [...] https://kojipkgs.fedoraproject.org//work/tasks/2704/17392704/ro > ot.log > > DEBUG util.py:421: Error: package > pkgconf-pkg-config-1.2.0-1.fc26.aarch64 conflicts with pkgconfig < > 1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.aarch64 This is known issue (not really caused by pkgconf change, but it is caused by bug in dnf), see: https://pagure.io/releng/issue/6597 > > > - FChE > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ClipIt
On Fri, 2017-01-20 at 15:50 +, mastaiza wrote: > Hi, somebody do not take the package ClipIt . de...@lists.deforaproject.org is not appropriate place for such messages. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
pyopencl now contains BSD code
Upstream added parts of random123 project which is BSD-licensed. This affects only rawhide, since I don't plan to build it for any stable releases. Thanks for the time ;) -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
On Wed, Jan 18, 2017 at 9:54 PM, Dusty Mabe wrote: > > > On 01/18/2017 03:50 PM, Igor Gnatenko wrote: >> On Wed, Jan 18, 2017 at 9:48 PM, Dusty Mabe wrote: >>> >>> >>> On 01/06/2017 03:29 PM, Daniel J Walsh wrote: >>>> https://fedoraproject.org/wiki/Changes/DockerOverlay2 >>> >>> Can we get this onto the "official looking" page for F26 changes [1]? >> Change initiator should add it to category ReadyForWrangler and this >> change will be discussed on next (or after next) FESCo meeting. > > I see this on that page already: Category:ChangeReadyForWrangler no, it's just text. real category is: [[Category:ChangePageIncomplete]] > > Does that work? > > Dusty > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
On Wed, Jan 18, 2017 at 9:48 PM, Dusty Mabe wrote: > > > On 01/06/2017 03:29 PM, Daniel J Walsh wrote: >> https://fedoraproject.org/wiki/Changes/DockerOverlay2 > > Can we get this onto the "official looking" page for F26 changes [1]? Change initiator should add it to category ReadyForWrangler and this change will be discussed on next (or after next) FESCo meeting. > > Do we also need to document in here the different configurations for the > different variants? > > Atomic Host vs Server vs Workstation? > > Dusty > > [1] https://fedoraproject.org/wiki/Releases/26/ChangeSet > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The default buildroot no longer contains python/python3
On Tue, Jan 17, 2017 at 12:19 PM, Petr Šabata wrote: > On Mon, Jan 16, 2017 at 02:19:43PM +0100, Igor Gnatenko wrote: >> On Mon, 2017-01-16 at 13:13 +0100, Petr Šabata wrote: >> > Let it be known that due to certain packaging changes implemented >> > in December, neither python nor python3 are automatically pulled >> > into the default, minimal buildroot anymore. >> I have to note that for python3 it's not really true, since rpm-build >> "depends" (one of depgens require functionality to work[0]) on python3- >> setuptools. >> >> Hopefully at some point it will be moved to something like python- >> generators (like we did with perl). > > Well, that's disappointing. > > Since we would really, really like to drop python3 from Base Runtime, finding > some other [easy] solution would be preferred. Hmmm. But it's part of rpm-build, do you really need to have rpm-build in base runtime? > > P > >> > >> > This negatively affects packages the require python/python3 at >> > build time but do not explicitly say so, causing FTBFS issues. >> > This will manifest itself during the upcoming mass rebuild, >> > at the latest. >> > https://fedoraproject.org/wiki/Releases/26/Schedule >> > >> > If your package is affected, make sure you declare your build >> > dependencies correctly and add anything that's missing. >> > https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 >> > >> > See https://pagure.io/fesco/issue/1660 for some background on this. >> > >> > Cheers, >> > P >> > ___ >> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org >> > To unsubscribe send an email to devel-announce-leave@lists.fedoraproj >> > ect.org >> > ___ >> > devel mailing list -- devel@lists.fedoraproject.org >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1410631 >> -- >> -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The default buildroot no longer contains python/python3
On Mon, 2017-01-16 at 13:13 +0100, Petr Šabata wrote: > Let it be known that due to certain packaging changes implemented > in December, neither python nor python3 are automatically pulled > into the default, minimal buildroot anymore. I have to note that for python3 it's not really true, since rpm-build "depends" (one of depgens require functionality to work[0]) on python3- setuptools. Hopefully at some point it will be moved to something like python- generators (like we did with perl). > > This negatively affects packages the require python/python3 at > build time but do not explicitly say so, causing FTBFS issues. > This will manifest itself during the upcoming mass rebuild, > at the latest. > https://fedoraproject.org/wiki/Releases/26/Schedule > > If your package is affected, make sure you declare your build > dependencies correctly and add anything that's missing. > https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 > > See https://pagure.io/fesco/issue/1660 for some background on this. > > Cheers, > P > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-leave@lists.fedoraproj > ect.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org [0] https://bugzilla.redhat.com/show_bug.cgi?id=1410631 -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: Rebasing to Readline-7.0 in rawhide
On Sat, 2017-01-14 at 17:17 +0100, Pavel Raiskup wrote:
> On Friday, January 13, 2017 6:33:49 PM CET Igor Gnatenko wrote:
> > On Fri, 2017-01-13 at 10:30 -0500, Siteshwar Vashisht wrote:
> > > Hello,
> > >
> > > Readline-7.0 was released few months ago and I have rebased it in
> > > rawhide to version 7.0. I have created a compatibility package
> > > compat-readline6 to avoid breaking any existing applications.
> > >
> > > Update to readline-7.0 caused a build failure with gdb that was
> > > fixed
> > > by this commit [1].
> >
> > I've rebuilt yesterday ~199 packages to link against new soname,
>
> Was that complete list? I miss the build for PostgreSQL e.g.
Macaulay2
afpfs-ng
augeas
bes
folks
freeradius
ghc-readline
glusterfs-coreutils
gnomint
guile
insight
ipmitool
kawa
ktechlab
libgda
libldm
libwvstreams
malaga
maxima
nmh
ocaml-omake
opendbx
perl-Term-ReadLine-Gnu
physfs
piklab
postgresql
python26
root
shigofumi
socat
sqlcipher
tcl-tclreadline
telegram-cli
torque
v8-314
xmlrpc-c
This are the packages in koji which are still linking to
libreadline.so.6.
Full list of packages I've rebuilt is more complicated and much wider
(just use datagrapper to find my commits to git).
P.S. I probably missed some of packages to rebuild...
>
> Pavel
>
> > however some of them (~38) failed by various reasons:
> > airtsp: #1307310 NEW- Denis Arnaud - airtsp: FTBFS in
> > rawhide
> > augeas: still building
> > bacula: #1412924 NEW- Simone Caronni - bacula: FTBFS in
> > Fedora
> > Rawhide
> > bes: maintainer reported upstream
> > dropwatch: #1412926 MODIFIED - Neil Horman - dropwatch: FTBFS in
> > Fedora Rawhide on ppc64/ppc64le
> > folks: #1412927 NEW- Brian Pepple - folks: FTBFS in Fedora
> > Rawhide
> > freeradius: #1385588 POST - Nikolai Kondrashov - freeradius-
> > 3.0.11-3.fc26 FTBFS: dereferencing pointer to incomplete type 'SSL
> > {aka
> > struct ssl_st}'
> > gnomint: #1412929 NEW- Adam Huffman - gnomint is not
> > buildable
> > from master (rawhide) branch
> > guile: #1412931 NEW- Miroslav Lichvar - guile: FTBFS in
> > Fedora
> > Rawhide
> > insight: #1409768 NEW- Patrick Monnerat - insight FTBFS in
> > rawhide
> > ipmitool: no bugs/investigation
> > kawa: #1307678 NEW- Mosaab Alzoubi - kawa: FTBFS in rawhide
> > ktechlab: #1307703 NEW- Kiara Navarro - ktechlab: FTBFS in
> > rawhide
> > libgda: no bugs/investigation
> > libldm: no bugs/investigation
> > libwvstreams: no bugs/investigation
> > Macaulay2: no bugs/investigation
> > malaga: no bugs/investigation
> > maxima: still building
> > nmh: no bugs/investigation
> > opendbx: no bugs/investigation
> > physfs: no bugs/investigation
> > piklab: #1307864 NEW- Kiara Navarro - piklab: FTBFS in
> > rawhide
> > root: still building
> > shigofumi: no bugs/investigation
> > socat: #1404290 NEW- Paul Wouters - socat build failure on
> > rawhide (fc26)
> > tcl: no bugs/investigation
> > telegram-cli: #1412932 NEW- Antonio Trande - telegram-cli:
> > FTBFS in Fedora Rawhide
> > torque: no bugs/investigation
> > v8: #1389477 NEW- Tom "spot" Callaway - FTBFS in
> > crankshaft/lithium-allocator
> > >
> > > I am providing abidiff report for the changes between readline-
> > > 6.3
> > > and readline-7.0 :
> > >
> > > ELF SONAME changed
> > > Functions changes summary: 2 Removed, 2 Changed (1 filtered out),
> > > 17
> > > Added functions
> > > Variables changes summary: 0 Removed, 1 Changed, 15 Added
> > > variables
> > >
> > > SONAME changed from 'libreadline.so.6' to 'libreadline.so.7'
> > >
> > > 2 Removed functions:
> > >
> > > 'function void _rl_audit_tty(char*)'{_rl_audit_tty}
> > > 'function void replace_history_data(int, histdata_t*,
> > > histdata_t*)'{replace_history_data}
> > >
> > > 17 Added functions:
> > >
> > > 'function void _hs_append_history_line(int, const
> > > char*)'{_hs_append_history_line}
> > > 'function void _hs_replace_history_data(int, histdata_t*,
> > > histdata_t*)'{_hs_replace_history_data}
> > > 'function int _rl_find_prev_mbchar_internal(char*, int,
> > > int)'{_rl_find_prev_mbchar_internal}
> > > 'function int
> &g
Re: HEADS UP: Rebasing to Readline-7.0 in rawhide
x27;readline_state*' has sub-type changes:
> in pointed to type 'struct readline_state' at readline.h:894:1:
> type size changed from 1536 to 1792 bits
> 2 data member insertions:
> 'char* readline_state::kseq', at offset 576 (in bits) at
> readline.h:913:1
> 'char* readline_state::wordbreakchars', at offset 1216 (in
> bits) at readline.h:932:1
> 13 data member changes:
> 'int readline_state::buflen' offset changed from 192 to 96
> (in bits)
> 'UNDO_LIST* readline_state::ul' offset changed from 256 to
> 192 (in bits)
> 'char* readline_state::prompt' offset changed from 320 to
> 256 (in bits)
> 'int readline_state::rlstate' offset changed from 384 to 320
> (in bits)
> 'int readline_state::done' offset changed from 416 to 352
> (in bits)
> 'Keymap readline_state::kmap' offset changed from 448 to 384
> (in bits)
> 'int readline_state::insmode' offset changed from 576 to 512
> (in bits)
> 'int readline_state::edmode' offset changed from 608 to 544
> (in bits)
> 'int readline_state::pendingin' offset changed from 832 to
> 672 (in bits)
> 'char* readline_state::macro' offset changed from 896 to 832
> (in bits)
> 'int readline_state::catchsigs' offset changed from 960 to
> 896 (in bits)
> 'int readline_state::catchsigwinch' offset changed from 992
> to 928 (in bits)
> 'char readline_state::reserved[64]' offset changed from 1024
> to 1280 (in bits)
>
>
>
> 15 Added variables:
>
> 'int
> _rl_colored_completion_prefix'{_rl_colored_completion_prefix}
> 'char* _rl_emacs_mode_str'{_rl_emacs_mode_str}
> 'int _rl_emacs_modestr_len'{_rl_emacs_modestr_len}
> 'int _rl_enable_bracketed_paste'{_rl_enable_bracketed_paste}
> 'int _rl_optimize_typeahead'{_rl_optimize_typeahead}
> 'char* _rl_vi_cmd_mode_str'{_rl_vi_cmd_mode_str}
> 'int _rl_vi_cmd_modestr_len'{_rl_vi_cmd_modestr_len}
> 'char* _rl_vi_ins_mode_str'{_rl_vi_ins_mode_str}
> 'int _rl_vi_ins_modestr_len'{_rl_vi_ins_modestr_len}
> 'int _rl_vi_redoing'{_rl_vi_redoing}
> 'int history_file_version'{history_file_version}
> 'int
> history_lines_read_from_file'{history_lines_read_from_file}
> 'int
> history_lines_written_to_file'{history_lines_written_to_file}
> 'int history_multiline_entries'{history_multiline_entries}
> 'int
> rl_persistent_signal_handlers'{rl_persistent_signal_handlers}
>
> 1 Changed variable:
>
> [C]'int rl_readline_state' was changed to 'unsigned long int
> rl_readline_state' at readline.h:500:1:
> size of symbol (in bytes) changed from 4 to 8
> type of variable changed:
> type name changed from 'int' to 'unsigned long int'
> type size changed from 32 to 64 bits
>
>
>
>
> I would be happy to help if any package maintainers need my help with
> updating to readline-7.0.
>
> [1] https://src.fedoraproject.org/cgit/rpms/gdb.git/commit/?id=194c08
> 60de7383cb82bbc6d28c64ba07bb5bea72
>
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
FTBFS tracking bug
Hello, do we have tracking bug for FTBFS? I remember there was one for F24, but can't find something similar for F26. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
On Wed, Jan 11, 2017 at 12:46 AM, Adam Williamson
wrote:
> On Fri, 2016-09-02 at 12:44 +0200, Kalev Lember wrote:
>> On 08/31/2016 02:10 PM, Charalampos Stratakis wrote:
>> > Hello all,
>> >
>> > While checking out the SPEC file of python, it seems there were some
>> > packages that, while separate at some point, they got included in python's
>> > stdlib and then obsoleted as standalone packages (thus to cope with the
>> > change, python was obsoleting these packages and providing them as well in
>> > the SPEC). So every package that currently (Build)Requires any of these
>> > packages will essentially drag python with it.
>> >
>> > I will remove these provides soon, since the packages were orphaned long
>> > time ago, but the packages that still require them, will need to be fixed
>> > and (Build)Require python instead.
>>
>> My suggestion would be to request provenpackager access and just fix all
>> those packages yourself in rawhide. If you file bugs, these are probably
>> going to take quite a bit of time to get fixed and you won't be able to
>> drop the compatibility provides for several Fedora releases.
>
> Please be careful with such 'fixes'. Some specs are also built for EPEL
> 6; in EPEL 6, some of these (e.g. python-argparse) are still separate
> packages.
>
> I kind of agree with Neal / Kevin that removing these is pointless and
> unnecessary. Now I will have to conditionalize my affected specs
> somehow in order to keep using them to do builds both for EPEL 6 (where
> I *must* include Requires: python-argparse) and Rawhide (where I now
> *cannot* include Requires: python-argparse)...which is a pain.
Python stack is derived too much from EL to Fedora. Just maintain 2
different specs. Even EL7 is always painful since you have to do
%if 0%{?rhel} && 0%{?rhel} <= 7
BuildRequires: python-setuptools
%else
BuildRequires: python2-setuptools
%endif
> --
> 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
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]
On Tue, Jan 10, 2017 at 11:49 AM, Matthew Miller wrote: > > On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote: > > Apache httpd and KDE are very interesting examples. Both KDE and > > Apache httpd integrate with Subversion, on two levels: KDE has > > Subversion client support, Apache httpd has server support. And > > Subversion is implemented using apr (the Apache Portable Runtime > > library). > > > > So unless we start building Subversion twice, once for use with > > Apache httpd, and once for use within KDE, modules containing KDE > > and Apache httpd will have to agree on the same version of > > Subversion and the same version of apr. To cut down support > > overhead, we'd probably want them to use the same versions, too, but > > this might not always be possible (e.g., newer upstream versions may > > have obliterate support, which would be considered an important > > server-side feature, but also change the working copy format, which > > would not be acceptable for a stable desktop release). > > Thanks, Florian - that's a great example. This is an area where Fedora, > in our well-meaning attempt to integrate everything, has hobbled > ourselves compared to more focused distributions. A project like Solus > can focus on just the desktop case and doesn't have to care about > Apache as an actual server; a server-only distro can make the opposite > choice. In Fedora right now, someone has to lose. Modularity gives us > flexibility to make a different decision on a case-by-case basis. At this point modularity doesn't help with this at all. It doesn't solve problems when you want to have library with 2 variants. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packages FTBFS with Python 3.6
On Wed, Dec 28, 2016 at 8:25 PM, Igor Gnatenko wrote:
> On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok wrote:
>> Hi all,
>> We've recently tried to rebuild all Python packages with Python 3.6.
>> However, we currently have bunch of packages that simply fail to build.
>>
>> As the list contains >200 packages, it would be very helpful, if you
>> (package maintainers) could help us solve the issues, as we cannot go one by
>> one to investigate the issue.
>>
>> I've attached the list of failed packages (failed.txt). You can search Koji
>> to find out, what went wrong. Sometimes, it's just missing dependency. That
>> dependency should be on this list as well. If it is not, maybe we lost it,
>> please tell us if that's the case. Maybe the dependency is circular and
>> something needs to be bootstrapped. If you need provenpackager powers, let
>> me know.
> I've fixed python-smartcols and python-behave..
>
> Attaching current rawhide/koji packages which depend on python 3.5
> instead of 3.6 still.
Let me update a list of packages (don't worry if you know about this
and it depends on some other fixes, just want to make some regular
updates of status):
PACKAGEMAINTAINERS
lcgdm aalvarez
adev
andreamanzi
rocha
python-characteristic tomprince
python-deapzbyszek
python-django-admin-honeypot echevemaster
python-django-avatar kumarpraveen
python-django-countriesbkabrda
python-django-filter bkabrda
churchyard
lbazan
python-django-jsonfieldgermano
python-django-notifications-hq suanand
python-flower jcline
python-gensim besser82
python-kdcproxynalin
npmccallum
python-mdp zbyszek
python-mossignatenkobrain
python-nipyignatenkobrain
python-os-brickapevec
jpena
jruzicka
python-oslo-messaging apevec
gchamoul
markmc
ndipanov
python-oslo-middleware apevec
gchamoul
python-oslo-versionedobjects apevec
hguemar
python-profilehooksbkabrda
python-pyopenclignatenkobrain
python-recommonmarkjujens
python-repoze-who-plugins-sa lmacken
python-sphinxcontrib-programoutput itamarjp
zbyszek
rb_libtorrent fale
root ellert
shogun besser82
lupinix
sympy cbm
jjames
> --
> -Igor Gnatenko
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
On Fri, Jan 6, 2017 at 9:29 PM, Daniel J Walsh wrote: > https://fedoraproject.org/wiki/Changes/DockerOverlay2 Thanks! Note, that you will need to send it for wrangler. > > > On 01/06/2017 02:27 PM, Igor Gnatenko wrote: > > Shouldn't this be submitted as a change? > > This would bring much more visibility to users of Fedora and even outside. > > -Igor Gnatenko > > On Jan 6, 2017 8:13 PM, "Daniel J Walsh" wrote: >> >> Upstream docker is moving to overlay2 by default for its storage. We >> plan on following suit. Their are some performance advantages of >> overlay2 over devicemapper in memory sharing, which we would like to >> take advantage of. We now have SELinux support for Overlay file >> systems, so the security should be just as good. >> >> Note: Overlay is not a Posix Compliant file system, so their could be >> problems with your containers running on overlay, so >> we want to make sure it is fairly easy to switch back to devicemapper. >> >> Devicemapper out of the box, on Fedora Workstation, currently defaults >> to loopback devices for storage, which has a performance penalty, but >> this was the only way we were able to get docker to work right away. >> Switching to overlay2 will cause the storage to be shared with / and >> will eliminate this performance overhead. This is the way we will ship >> Fedora Workstation. >> >> On Fedora atomic host and Fedora server we have been storing >> devicemapper storage on a separate partition. We plan on doing the same >> thing with overlay2. This means separate device will be mounted on >> /var/lib/docker. This will make it easier for someone to switch back to >> devicemapper, if overlay2 has problems. >> >> Upgraded systems will not be effected. >> >> If you want to switch from one storage to another take a look at the >> `atomic storage` commands. >> >> We will write up release notes to cover this change. Along with a blog >> explaining the commands to switch back and forth. >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changing default "docker" storage to to Overlay2 in Fedora 26
Shouldn't this be submitted as a change? This would bring much more visibility to users of Fedora and even outside. -Igor Gnatenko On Jan 6, 2017 8:13 PM, "Daniel J Walsh" wrote: > Upstream docker is moving to overlay2 by default for its storage. We > plan on following suit. Their are some performance advantages of > overlay2 over devicemapper in memory sharing, which we would like to > take advantage of. We now have SELinux support for Overlay file > systems, so the security should be just as good. > > Note: Overlay is not a Posix Compliant file system, so their could be > problems with your containers running on overlay, so > we want to make sure it is fairly easy to switch back to devicemapper. > > Devicemapper out of the box, on Fedora Workstation, currently defaults > to loopback devices for storage, which has a performance penalty, but > this was the only way we were able to get docker to work right away. > Switching to overlay2 will cause the storage to be shared with / and > will eliminate this performance overhead. This is the way we will ship > Fedora Workstation. > > On Fedora atomic host and Fedora server we have been storing > devicemapper storage on a separate partition. We plan on doing the same > thing with overlay2. This means separate device will be mounted on > /var/lib/docker. This will make it easier for someone to switch back to > devicemapper, if overlay2 has problems. > > Upgraded systems will not be effected. > > If you want to switch from one storage to another take a look at the > `atomic storage` commands. > > We will write up release notes to cover this change. Along with a blog > explaining the commands to switch back and forth. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support (Take Two!)
On Jan 6, 2017 5:16 PM, "Neal Gompa" wrote: On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled wrote: > On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote: > >> ... > >> * I do not see any practical advantage of Debian multiarch over FHS > >> multilib. > > > > Good question, multiarch is a huge win for *embedded* developers. > > > > Let me give real life example from my $day job: > > * We build stuff for arm and x86_64 (I ignore our legacy platforms > > like x86, ppc, whatnot...) > > > > * We cross compile most stuff (faster), but not everything is easily > > cross-compilable: > > - Notorious examples are libraries with their own code-generation tools. > > - Examples: thrift, dbus-c++ (you need to *run* built tools) > > - So we build some packages natively (either on real ARM or in chroot with > qemu-user-static). > > > > * With old, non-multiarch scheme: > > - Library packages compiled natively on ARM would be under /usr/lib. > > - But they cannot be installed on the build machine, so I can cross-compile > > applications against them. > > - The workaround was to unpack them, relocate the libraries, headers, etc > > to the prefix expected by cross compiler (e.g: /opt/toolchain/) and > > repack the result into an "all" architecture package. > > > > * With multiarch distribution (Debian/jessie in my case): > > - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > > *regardless* if they were built natively or cross-compiled. > > - These packages may be co-installed on my development host and be used > > by the cross compiler. > > - So I have an ARM repository, everything built (natively + cross) is > uploaded > > there and I can pull library dependencies into my build environment. > > - And the *exact* same binary packages installed on the ARM target are > > installed and being used by the cross compilers. > > Much of what I would have said has been said by Oron (some of this I've said in earlier parts of this thread, as well). But the bigger thing is that it makes it much easier to bootstrap new architectures for Fedora, too, as we can start from libraries and build up to applications relatively easily. It doesn't completely solve the issue, as there would still be some conflicts, but it makes it a lot less challenging. Enabling things like being able to do test and development with arbitrary architectures would be a huge boon, as well. That being said, I would be in remiss to indicate that platform libdirs (what Debian calls multiarch libdirs) are able to be implemented in a backwards-compatible way. Debian was able to pull it off because they originally used /lib32 and /lib64, but migrated to /lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks to point to them). We should be able to do the same. If we touch this thing I would like to have /usr/lib/triple. At this moment we don't have good cross-compiler support and this would help us (at least to some degree). The main break will be that /usr/lib will no longer contain archful data, and that's going to be a difference no matter how you slice it. We could elect to do /usr/lib32 and that would still be an improvement of the situation over what we have now, but it's still a break (though not necessarily one that will break third party applications). If we don't want to do full platform libdirs, I would really like us to move 32-bit libraries to /usr/lib32. It would just be much cleaner on the filesystem that way. If we do full platform libdirs, I would like us to have the symlinks for /usr/lib32 and /usr/lib64 to point to the correct places, too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes - KDE wallet kinit
On Mon, Jan 2, 2017 at 11:27 PM, Orion Poplawski wrote: > On 12/11/2016 05:34 PM, Dennis Gilmore wrote: >> * koji and the source lookaside were changed to use kerberos >> authentication >> instead of ssl certificates. All maintainers will need to: >> >> kinit your-fas-accountn...@fedoraaproject.org >> >> to get a valid kerberos TGT and be able to authenticate to koji and >> the lookaside upload cgi. > > KDE users may find this useful - I've started using the newly packaged > kwalletcli to do: Cool, would be nice add it into wiki: https://fedoraproject.org/wiki/Infrastructure/Kerberos > > $ cat ~/.kde/Autostart/kinit.desktop > [Desktop Entry] > Comment[en_US]= > Comment= > Exec=bash -c 'kwalletcli -f Passwords -e or...@fedoraproject.org | kinit > or...@fedoraproject.org;kswitch -p m...@domain.com' > GenericName[en_US]=Initialize Fedora Kerberos > GenericName=Initialize Fedora Kerberos > MimeType= > Name[en_US]=kinit > Name=kinit > Path= > StartupNotify=false > Terminal=false > TerminalOptions= > Type=Application > X-DBUS-ServiceName= > X-DBUS-StartupType= > X-KDE-SubstituteUID=false > X-KDE-Username= > name[en_US]=Kinit > > After storing the password in the wallet's "Passwords" directory under my > principal name. > > I find that I have to also kswitch back to my local principal for NFS to work > for me at work. > > -- > Orion Poplawski > Technical Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 http://www.nwra.com > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaning python-sphinx-theme-better
On Mon, Jan 2, 2017 at 9:14 PM, Sandro Mani wrote: > Hi > > I've orphaned python-sphinx-theme-better. It was briefly used by > python-pillow for its documentation in the past, but that's not the case > anymore and python-sphinx-theme-better hasn't seen any activity upstream > since 2013. As far as I can tell [1] no other package in fedora requires it. You can retire it in rawhide as well. > > Sandro > > [1] > $ dnf repoquery --disablerepo=* --enablerepo=rawhide-source --whatrequires > python-sphinx-theme-better --alldeps > $ dnf repoquery --disablerepo=* --enablerepo=rawhide-source --whatrequires > python3-sphinx-theme-better --alldeps > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swaps
On Mon, Jan 2, 2017 at 7:09 PM, Sandro Mani wrote: > Hi > > For the upgrade to python-pillow-4.0.0, I need these two packages reviewed: Appreciate that! > > - https://bugzilla.redhat.com/show_bug.cgi?id=1409647 - libimagequant - > Palette quantization library > - https://bugzilla.redhat.com/show_bug.cgi?id=1409648 - python-olefile - > Python package to parse, read and write Microsoft OLE2 files > > First is a simple C library. Second is a simple python library. Reviewed both. > > Happy to review in exchange. Could you take some useful package -- screencloud[0]? I don't use it, but people do. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1396847 > > Thanks > Sandro -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best practices for getting CFLAGS/LDFLAGS etc.
On Mon, Jan 2, 2017 at 10:56 AM, Florian Weimer wrote:
> The final values of CFLAGS/LDFLAGS/… are set (as shell variables) by the
> %configure macro. There is no other immediately obvious way to get those
> definitions. This means that if you can't use %configure for some reason,
> you are out of luck.
>
> In this situation, this still works:
>
> %global %_configure :
> %configure
>
> As a result, %configure tries to run “:” instead of “./configure”, which is
> a NOP, and only the shell variable initialization remains.
>
> Is this the recommend way to initialize the compiler flags?
export CFLAGS="%{__global_cflags}"
export CXXFLAGS="%{__global_cxxflags}"
export LDFLAGS="%{__global_ldflags}"
and others (e.g. fortran flags)
It's not really portable way (it most likely will not work on other
RPM-based distros, but who cares). RPM itself define only %optflags.
export CFLAGS="${CFLAGS:-%__global_cflags}"
export CXXFLAGS="${CXXFLAGS:-%__global_cxxflags}"
export FFLAGS="${FFLAGS:-%__global_fflags}"
export FCFLAGS="${FCFLAGS:-%__global_fcflags}"
export LDFLAGS="${LDFLAGS:-%__global_ldflags}"
>
> Should we introduce a %setup_cflags macro to make this more explicit?
Would be helpful to not copy-paste exports over buildsystems.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: `best=1` in new Mock
On Sun, Jan 1, 2017 at 1:49 PM, Miroslav Suchy wrote: > Hi, > I just released new version of Mock. And I want to quote one important > change from the release notes so everyone is aware of it: > > https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.3.3 > > All chroot (but rawhide) configs now contains best=1. > This way DNF will always try to install latest package. If its > dependence cannot be satisfied DNF will report an error. Without this > DNF may silently install some older version which does not have broken deps. > This is fine for regular user, but not for buildsystems, where > maintainers usually want to use latest version. I think koji manages this properly, so only latest version of package is included into buildroot (even it has broken deps). Though someone like Dennis or Kevin should confirm this... > > Note that this change may result in sudden build failure, which > previously silently succedded. In this case, please check your > BuildRequires and ask maintainers of those build deps to resolve broken > dependency. This option was not added to rawhide chroots as there are > broken dependencied very often. > > Additionaly option best=1 is used for repos passed to mockchain using -a > option. > > > Mirek Suchy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packages FTBFS with Python 3.6
On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok wrote: > Hi all, > We've recently tried to rebuild all Python packages with Python 3.6. > However, we currently have bunch of packages that simply fail to build. > > As the list contains >200 packages, it would be very helpful, if you > (package maintainers) could help us solve the issues, as we cannot go one by > one to investigate the issue. > > I've attached the list of failed packages (failed.txt). You can search Koji > to find out, what went wrong. Sometimes, it's just missing dependency. That > dependency should be on this list as well. If it is not, maybe we lost it, > please tell us if that's the case. Maybe the dependency is circular and > something needs to be bootstrapped. If you need provenpackager powers, let > me know. I've fixed python-smartcols and python-behave.. Attaching current rawhide/koji packages which depend on python 3.5 instead of 3.6 still. -- -Igor Gnatenko dnsyo elastic-curator gerrymander google-api-python-client graphite-api hgsvn lcgdm libcec libproxy libuser netstat-monitor openwsman pcs pdc-client python3-bsddb3 python3-cherrypy python-acme python-adal python-beanbag python-blosc python-cassandra-driver python-castellan python-ceilometerclient python-cerberus python-characteristic python-congressclient python-cursive python-deap python-dill python-django-admin-honeypot python-django-avatar python-django-countries python-django-filter python-django-formtools python-django-jsonfield python-django-model-utils python-django-notifications-hq python-django-openstack-auth python-django-pyscss python-fastimport python-flask-migrate python-flask-script python-flower python-gensim python-gerritlib python-hglib python-k8sclient python-kdcproxy python-keystonemiddleware python-lazr-smtptest python-magnumclient python-manilaclient python-marrow-mailer python-mdp python-microversion-parse python-more-itertools python-moss python-netdiff python-nipy python-openstacksdk python-os-brick python-osc-lib python-os-client-config python-oslo-cache python-oslo-context python-oslo-db python-oslo-log python-oslo-messaging python-oslo-middleware python-oslo-policy python-oslo-reports python-oslo-service python-oslo-versionedobjects python-oslo-vmware python-photutils python-profilehooks python-prov python-pyopencl python-recommonmark python-repoze-who-plugins-sa python-rows python-sphinxcontrib-programoutput python-sphinxcontrib-spelling python-statsd python-structlog python-swiftclient python-tackerclient python-tosca-parser python-troveclient rb_libtorrent root rpy shogun sympy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: LibRaw soname bump
On Wed, Dec 28, 2016 at 12:12 AM, Jon Ciesla wrote: > 0.18.0 is coming. I'm taking care of: > > efl > entangle > freeimage > gegl03 > gthumb > kf5-libkdcraw > libkdcraw > nomacs > OpenImageIO > oyranos > shotwell You missed some of packages: * evas-generic-loaders * fotoxx * indi-gphoto * krita * kstars * luminance-hdr * photoqt * siril > > If I missed something, let me know. > > -- > http://cecinestpasunefromage.wordpress.com/ > > in your fear, seek only peace > in your fear, seek only love > > -d. bowie > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
scanmem lincese changes from GPLv2+ to GPLv3+ and LGPLv3+
Since 0.16 libscanmem is LGPLv3+ and the rest is GPLv3+. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: cross-compiler support?
On Tue, Dec 20, 2016 at 12:59 AM, Laura Abbott wrote: > On 12/19/2016 02:59 PM, Igor Gnatenko wrote: >> Hi, >> >> I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs >> >> But it doesn't work: >> This package is compiled in bootstrap mode and used only to solve circular >> build dependency. You don't want to use this package. It's not expected to >> work. >> >> In normal circumstances, you should not see bootstrap package in any >> released Fedora. >> >> Do I miss something? >> > > Well there is gcc-arm-linux-gnu for example but that's for kernels per > description Didn't see it before... But looks like it doesn't work either: /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory /usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory /usr/bin/arm-linux-gnu-ld: cannot find -lc /usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory > > $ dnf info gcc-arm-linux-gnu > Installed Packages > Name: gcc-arm-linux-gnu > Arch: x86_64 > Epoch : 0 > Version : 6.1.1 > Release : 2.fc24 > Size: 59 M > Repo: @System > From repo : updates > Summary : Cross-build binary utilities for arm-linux-gnu > URL : http://gcc.gnu.org > License : GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and > : LGPLv2+ and BSD > Description : Cross-build GNU C compiler. > : > : Only building kernels is currently supported. Support for > : cross-building user space programs is not currently provided as > : that would massively multiply the number of packages > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
cross-compiler support?
Hi, I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs But it doesn't work: This package is compiled in bootstrap mode and used only to solve circular build dependency. You don't want to use this package. It's not expected to work. In normal circumstances, you should not see bootstrap package in any released Fedora. Do I miss something? -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Updated xmlrpc-c (1.47.1) is on the way
On Sun, Dec 18, 2016 at 3:27 PM, Alexander Bokovoy wrote: > On su, 18 joulu 2016, Igor Gnatenko wrote: >> >> Unfortunately we stuck with very old (1.32.5, somewhere from 2012) >> version of xmlrpc-c. I've rebased it to newer version (1.47.1, from >> this month). It doesn't anymore use cmake (it was port from one of our >> contributors, official buildsys is autoconf+gnumake) for building, now >> it uses meson (you can see why in my blog[0]). >> >> * abrt >> No problem for rebuild >> * certmonger >> FTBFS due to openssl1.1[1], though probably it should be retired >> because looks like it's part of FreeIPA now > > Certmonger is a separate project and is a separate package. The fact > that it is used by FreeIPA does not change the state of it. > >> * freeipa >> No problem for rebuild > > Did you actually try to install/enroll IPA client with new xmlrpc-c? > Last time the change happened due to CVE, GSSAPI authentication broke in > xmlrpc-c and none of IPA clients were able to enroll. This was a major > breakage. Hmm.. I have not checked it, but before doing update/rebuilds will try to spawn IPA server/client in VM and see whether it works. You can try yourself as well from this repo: https://copr.fedorainfracloud.org/coprs/ignatenkobrain/xmlrpc-c-rebase/ > > >> I will build new xmlrpc-c and rebuild dependent libraries this or next >> week. >> >> >> [0] https://blogs.gnome.org/ignatenko/2016/12/17/meson-%E2%99%A5-xmlrpc-c/ >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1405790 >> [2] https://github.com/FreightAgent/freight-tools/issues/5 >> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1385596 > > > -- > / Alexander Bokovoy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Updated xmlrpc-c (1.47.1) is on the way
Unfortunately we stuck with very old (1.32.5, somewhere from 2012) version of xmlrpc-c. I've rebased it to newer version (1.47.1, from this month). It doesn't anymore use cmake (it was port from one of our contributors, official buildsys is autoconf+gnumake) for building, now it uses meson (you can see why in my blog[0]). * abrt No problem for rebuild * certmonger FTBFS due to openssl1.1[1], though probably it should be retired because looks like it's part of FreeIPA now * freeipa No problem for rebuild * freight-tools Doesn't build with new xmlrpc-c, but seems easy to fix[2] * libreport No problem for rebuild * opensips FTBFS due to openssl1.1[3] * rtorrent No problem for rebuild * fawkes Was not able to build due to nothing provides libvtkftgl.so.1 needed by pcl-1.8.0-2.fc26.x86_64 I will build new xmlrpc-c and rebuild dependent libraries this or next week. [0] https://blogs.gnome.org/ignatenko/2016/12/17/meson-%E2%99%A5-xmlrpc-c/ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1405790 [2] https://github.com/FreightAgent/freight-tools/issues/5 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1385596 -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: rawhide: Illegal char '-' (0x2d) in: Release: 3.fc26-pending
On Wed, Dec 14, 2016 at 12:00 PM, Nikos Mavrogiannopoulos
wrote:
> Any idea on why this happens when attempting to build in rawhide? Is
> the buildroot broken?
You need to update fedpkg/pyrpkg.
>
> $ fedpkg build
> error: line 6: Illegal char '-' (0x2d) in: Release: 3.fc26-pending
> error: query of specfile /home/.../fedora/gnutls/gnutls.spec failed,
> can't parse
>
> The line in question has:
> Release: 3%{?dist}
>
>
> Builds in other branches work fine.
>
> regards,
> Nikos
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announcement: Fedora Docker Layered Image Build Service is GO!
On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller wrote: > It is with great pleasure that the Fedora Project Announces the availability > of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor > Community! > > With this announcement we are opening availability of the Docker Layered > Image Build Service for the Docker Layered Images[1] that the Fedora Cloud > SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as > official components of Fedora. From there we will be extending an invitation > to all Fedora Contributors to maintain Docker Layered Image Containers for > official release by the Fedora Project. Currently this effort is to enable > the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a > primary deliverable to power the future of Cloud. This is also to enable the > Fedora Modularity[5] work be delivered as Containers in the future as Fedora > becomes fundamentally more modular in nature. > > How do I get started? > > Contributors will go through a simliar process as what they currently do > with RPM Review Requests. There will be Container Reviews as well as > Container Guidelines: > > https://fedoraproject.org/wiki/Container:Review_Process > https://fedoraproject.org/wiki/Container:Guidelines Nice job! I have couple of questions: * why "FROM fedora:25", how do I choose version on which I want to base container? * is there containers in registry for rawhide? > > At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as > the Review Process along with input from all Fedora Contributors. This may > change later with the formation of a Fedora Container Committee (similar to > the Fedora Packaging Committee[6]). > > Please note that both the Guidelines and the Review Process are likely to > evolve along with the Container technologies as we move into the future so > we encourage community members to check the documentation for updates. > > For more information, please see the following Fedora Community Blog: > > > https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/ > > [0] - > https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service > [1] - https://fedoraproject.org/wiki/Cloud > [2] - > https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/ > [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles > [4] - https://getfedora.org/en/atomic/download/ > [5] - https://fedoraproject.org/wiki/Modularity > [6] - https://fedoraproject.org/wiki/Packaging_Committee > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
On Mon, Dec 12, 2016 at 2:33 AM, Michael Catanzaro wrote: > On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote: >> * koji and the source lookaside were changed to use kerberos >> authentication >> instead of ssl certificates. All maintainers will need to: >> >> kinit your-fas-accountn...@fedoraaproject.org >> >> to get a valid kerberos TGT and be able to authenticate to koji and >> the lookaside upload cgi. >> >> See the general kerberos information at: >> https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication >> for more details. > > I had some fun with this! Turns out both username and domain are case- > sensitive. I almost gave up when none of the following worked: > > $ kinit catanz...@fedoraproject.org > $ kinit catanz...@fedoraproject.org > $ kinit catanz...@fedoraproject.org > > This worked: > > $ kinit catanz...@fedoraproject.org > > OK great, but now it wants me to type a password, but I still don't > want to switch my FAS account to use a memorable password, so let's try > to use the gnome-online-accounts option instead! Unfortunately the > instructions on how to use gnome-online-accounts in the wiki do not > work. It shows a little error icon in the Domain box, as if to indicate > that FEDORAPROJECT.ORG is an invalid domain (but unhelpfully without > any actual tooltip or error message). Is there a known problem here? yes, and even patch available: https://bugzilla.redhat.com/show_bug.cgi?id=1401605 > > Michael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: shapelib soname bump
On Sun, Dec 11, 2016 at 7:04 PM, Ralf Corsepius wrote: > On 12/11/2016 01:44 PM, Igor Gnatenko wrote: > >>>>> gpsbabel-0:1.5.3-4.fc24 >> >> + perl xmldoc/makedoc >> /var/tmp/rpm-tmp.rKbJFb: line 62: perl: command not found >> Can you file FTBFS bug? > > Why didn't you try a scratch-build in advance to a introducing broken builds > into git? 1. What means "broken build into git"? 2. Why should I try scratch-build in case I know that if build will not fail due my change? > > Anyway, I (gpsbabel maintainer) will take care of this, tomorrow. > > Ralf > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Start packaging/maintaining in Fedora
On Dec 11, 2016 3:46 PM, "Ms Sanchez" wrote: Hello everyone! I want to start packaging and maintaining packages in Fedora, but I'm a bit lost. What should I do first? How can I start maintaining a package? Is there anyone who can guide me a bit, please? https://fedoraproject.org/wiki/Join_the_package_collection_maintainers I know Python and C languages. Thanks in advance! Sylvia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: out of space on some builders
On Dec 11, 2016 2:53 PM, "Patrick マルタインアンドレアス Uiterwijk" < puiterw...@redhat.com> wrote: > Looks like there are problems on some builders: Then reporting koji errors, it would be great if you could attach the task link so that we can check. http://koji.fedoraproject.org/koji/taskinfo?taskID=16837961 For example this one. > > BuildrootError: could not init mock buildroot, mock exited with status > 1; see build.log for more information > > And there is no build.log. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
out of space on some builders
Looks like there are problems on some builders: BuildrootError: could not init mock buildroot, mock exited with status 1; see build.log for more information And there is no build.log. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] gpgme-1.8.0 comes in Rawhide
On Sat, Dec 10, 2016 at 7:30 PM, Neal Gompa wrote: > On Sat, Dec 10, 2016 at 1:28 PM, Igor Gnatenko wrote: >> There is also C++ bindings, but I didn't package it. Do you want me to do it? > > > If you could, I think it'd be appreciated if the C++ bindings were included. Done. New pacakges: * gpgmepp * gpgmepp-devel * qgpgme * qgpgme-devel Python packages are named: * python2-gpg * python3-gpg since they provide "gpg" egg and to not confuse people with pygpgme project. It's building right now. > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: shapelib soname bump
On Sun, Dec 11, 2016 at 1:20 PM, Sandro Mani wrote: > > > On 11.12.2016 12:54, Igor Gnatenko wrote: >> >> On Sun, Dec 11, 2016 at 11:54 AM, Sandro Mani >> wrote: >>> >>> Hi >>> >>> I'm preparing the shapelib-1.4.0 update, which bumped the soname. There >>> are >>> no API changes, it was just to synchronize with the debian soname. >>> Dependent >>> packages are: >>> >>> gpsbabel-0:1.5.3-4.fc24 + perl xmldoc/makedoc /var/tmp/rpm-tmp.rKbJFb: line 62: perl: command not found Can you file FTBFS bug? >>> grads-0:2.0.2-18.fc26 done >>> librecad-0:2.1.0-1.fc25 http://koji.fedoraproject.org/koji/taskinfo?taskID=16837961 /usr/bin/tar: LibreCAD-dbf1cc7c9597740d34a068f6f09c36841054e903/librecad/res: Cannot mkdir: No space left on device anyway, after next try -- done >>> marble-widget-qt5-1:16.08.3-1.fc26 done >>> plplot-libs-0:5.11.1-5.fc25 can't be built due to swig/octave incompatibility >>> >>> I'll need help rebuilding the above packages. >> >> I can help, ping me when package is in koji and I should rebuild these >> packages. > > Thanks, the package is now in koji. > > > Sandro > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: shapelib soname bump
On Sun, Dec 11, 2016 at 11:54 AM, Sandro Mani wrote: > Hi > > I'm preparing the shapelib-1.4.0 update, which bumped the soname. There are > no API changes, it was just to synchronize with the debian soname. Dependent > packages are: > > gpsbabel-0:1.5.3-4.fc24 > grads-0:2.0.2-18.fc26 > librecad-0:2.1.0-1.fc25 > marble-widget-qt5-1:16.08.3-1.fc26 > plplot-libs-0:5.11.1-5.fc25 > > I'll need help rebuilding the above packages. I can help, ping me when package is in koji and I should rebuild these packages. > > Thanks > Sandro > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Missing heads up for gmsh SONAME bump
Looks like there was no announcement nor rebuild of dependent packages. getdp has broken dependencies in the rawhide tree: On x86_64: getdp-2.10.0-2.fc26.x86_64 requires libGmsh.so.2.14()(64bit) On armhfp: getdp-2.10.0-2.fc26.armv7hl requires libGmsh.so.2.14 On ppc64le: getdp-2.10.0-2.fc26.ppc64le requires libGmsh.so.2.14()(64bit) On aarch64: getdp-2.10.0-2.fc26.aarch64 requires libGmsh.so.2.14()(64bit) On ppc64: getdp-2.10.0-2.fc26.ppc64 requires libGmsh.so.2.14()(64bit) On i386: getdp-2.10.0-2.fc26.i686 requires libGmsh.so.2.14 Please resolve this as soon as possible. Would be nice in future if someone will send headsup and/or rebuild dependent packages. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] gpgme-1.8.0 comes in Rawhide
On Sat, Dec 10, 2016 at 7:28 PM, Igor Gnatenko wrote: > Currently we stuck for very old version and I am preparing update, > notable changes are: > * Python bindings (both py2 and py3), upstream recommend projects to > switch to official bindings > * libgpgme-pthread.so is removed, GPGME is thread-safe (should not > affect packages using gpgme-config) > > There is also C++ bindings, but I didn't package it. Do you want me to do it? > > Packages to rebuild: I realized that ABI was not broken, so most of the packages do not need rebuild. * balsa * kdepim4 * kdepimlibs * kde-runtime * kget * kf5-gpgmepp * kf5-libkleo * kleopatra * ostree Rebuilt * kdepim Needs rebuild of kf5-mailcommon * kf5-mailcommon Needs rebuild of kf5-messagelib * kdepim-addons * kdepim-apps-libs DEBUG util.py:426: No matching package to install: 'kf5-pimcommon-devel >= 16.08.3' * kf5-messagelib DEBUG util.py:426: No matching package to install: 'kdepim-apps-libs-devel >= 16.08.3' DEBUG util.py:426: No matching package to install: 'kf5-libgravatar-devel >= 16.08.3' DEBUG util.py:426: No matching package to install: 'kf5-pimcommon-devel >= 16.08.3' * trojita FTBFS by other reasons -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
