Re: xindy, texlive, and concurrency
On Thu, May 16, 2019 at 3:46 AM Jerry James wrote:
>
> I finally found some time to look at the xindy failure to build.
> First, let me say that I've got a workaround for the problem, which
> resulted in the beautiful green colors in this xindy-enabled scratch
> build of texlive-base:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
>
> When the build process reached the xindy part of the build, it would
> successfully build xindy itself, then go to work on some
> documentation. This involved invoking latex on several input files.
> This marked the first (and possibly only) point in the build where
> latex was invoked, so latex.fmt had not yet been generated. Since we
> build with %{?_smp_mflags}, several independent threads invoked latex
> at approximately the same time. Every one of those invocations
> detected that latex.fmt was missing and tried to generate it.
>
> If you got lucky, each one of those threads would generate latex.fmt,
> then quickly consume it as it ran on its appointed input file. If you
> didn't get lucky, one or more threads would start reading latex.fmt
> after some other thread started writing it, but before it finished
> writing it all the way. That's why xindy would sometimes build and
> sometimes fail to build: the build process had a race condition.
So this is a build system bug from upstream. If concurrency introduces
a race condition then source-target dependencies are lacking in the
build system. Depending on the build system it may not be upstream's
fault, but the tooling itself.
A workaround for the concurrency problem would be an atomic write of
the generated file. This way even when it is generated multiple times
while others try to read it they either see a complete or missing file.
The only way I'm aware of for this workaround would be to write to a
temp file on the same filesystem, and then use mv to rename it
atomically.
> It is unfortunate that texlive is smart enough to detect missing
> format files and generate them, but not smart enough to stop that from
> happening multiple times concurrently. Anyway, poor xindy has been
> maligned: none of this was xindy's fault, nor clisp's. We, the Fedora
> packagers, threw concurrency at a job that lacked concurrency control.
> And the whole xindy_arches thing is useless: this is not an
> arch-specific problem, so removing random arches from the build
> accomplishes nothing.
>
> The workaround is to invoke latex on a dummy input file early in
> %build. This causes latex.fmt to be generated, and then everything is
> hunky-dory when xindy is built later.
>
> My recommendation is to remove the xindy_arches conditional from the
> texlive-base and texlive spec files. Make it unconditionallly on
> again. Then insert something like this at the top of %build:
>
> # Make texlive generate latex.fmt, so that multiple threads do not race to
> # make it during the xindy build.
> cat > dummy.tex << EOF
> \documentclass{article}
> \begin{document}
> This is a document.
> \end{document}
> EOF
> latex dummy.tex
> rm -f dummy.*
>
> That is the substance of this pull request:
>
> https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
>
> Also, I should be able to push a clisp build with s390x support to F30
> stable tomorrow. I, personally, would really appreciate having xindy
> reappear in F30, due to Sphinx assuming it is available.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190515.n.1 changes
OLD: Fedora-Rawhide-20190514.n.0 NEW: Fedora-Rawhide-20190515.n.1 = SUMMARY = Added images:0 Dropped images: 6 Added packages: 7 Dropped packages:1 Upgraded packages: 162 Downgraded packages: 0 Size of added packages: 10.00 MiB Size of dropped packages:277.00 KiB Size of upgraded packages: 9.12 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 171.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20190514.n.0-sda.raw.xz Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190514.n.0.iso Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20190514.n.0.aarch64.raw.xz Image: SoaS live i386 Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20190514.n.0.iso Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190514.n.0-sda.raw.xz Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190514.n.0.iso = ADDED PACKAGES = Package: nodejs-generate-function-2.3.1-1.fc31 Summary: Module that helps you write generated functions in Node RPMs:nodejs-generate-function Size:11.73 KiB Package: nodejs-generate-object-property-1.2.0-8.fc31 Summary: Generate safe JS code that can used to reference a object property RPMs:nodejs-generate-object-property Size:10.12 KiB Package: nodejs-har-validator-2.0.6-1.fc31 Summary: Extremely fast HTTP Archive (HAR) validator using JSON Schema RPMs:nodejs-har-validator Size:17.64 KiB Package: nodejs-is-my-json-valid-2.12.4-8.fc31 Summary: A JSONSchema validator that uses code generation to be extremely fast RPMs:nodejs-is-my-json-valid Size:16.69 KiB Package: nodejs-is-property-1.0.2-8.fc31 Summary: Tests if a json property can be safely accessed using the .syntax RPMs:nodejs-is-property Size:11.80 KiB Package: policycoreutils-2.9-1.module_f31+4252+e9820e36 Summary: SELinux policy core utilities RPMs:policycoreutils policycoreutils-dbus policycoreutils-devel policycoreutils-gui policycoreutils-newrole policycoreutils-python-utils policycoreutils-restorecond policycoreutils-sandbox python2-policycoreutils python3-policycoreutils Size:5.46 MiB Package: setools-4.2.1-3.module_f31+4252+e9820e36 Summary: Policy analysis tools for SELinux RPMs:python3-setools setools setools-console setools-console-analyses setools-gui Size:4.47 MiB = DROPPED PACKAGES = Package: dwm-6.1-8.module_f31+3254+1bcded0b Summary: Dynamic window manager for X RPMs:dwm dwm-user Size:277.00 KiB = UPGRADED PACKAGES = Package: Carla-2.0.0-0.10.20190501git41f81a8.fc31 Old package: Carla-2.0.0-0.9.20181225git2f3a442.fc30 Summary: Audio plugin host RPMs: Carla Carla-devel Carla-vst lv2-carla Size: 65.43 MiB Size change: 11.59 MiB Changelog: * Wed May 15 2019 Martin Gansser - 2.0.0-0.10.20190501git41f81a8 - Update to 2.0.0-0.10.20190501git41f81a8 Package: R-hexbin-1.27.3-1.fc31 Old package: R-hexbin-1.27.2-4.fc30 Summary: Hexagonal Binning Routines RPMs: R-hexbin Size: 5.44 MiB Size change: 547.29 KiB Changelog: * Tue May 14 2019 Elliott Sales de Andrade - 1.27.3-1 - Update to latest version Package: R-tinytex-0.13-1.fc31 Old package: R-tinytex-0.12-1.fc31 Summary: Helper Functions to Install and Maintain 'TeX Live', and Compile 'LaTeX' Documents RPMs: R-tinytex Size: 107.29 KiB Size change: 1.54 KiB Changelog: * Tue May 14 2019 Elliott Sales de Andrade - 0.13-1 - Update to latest version Package: R-xfun-0.7-1.fc31 Old package: R-xfun-0.6-1.fc31 Summary: Miscellaneous Functions by 'Yihui Xie' RPMs: R-xfun Size: 182.56 KiB Size change: 500 B Changelog: * Tue May 14 2019 Elliott Sales de Andrade - 0.7-1 - Update to latest version Package: anaconda-31.12-1.fc31 Old package: anaconda-31.11-1.fc31 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 20.75 MiB Size change: 23.84 KiB Changelog: * Wed May 15 2019 Martin Kolman - 31.12-1 - Fix condition for running GUI User spoke in Initial Setup (mkolman) - Expose individual user group, user and root password DBus tasks (mkolman) - Use a DBus task for Initial Setup configuration (mkolman) - Add ConfigureInitialSetupTask (mkolman) - Sysroot support for enable_service() and disable_service() (mkolman) - Fix documentation for nosslverify (jkonecny) - Replace noverifyssl flag in anaconda (jkonecny) - Adjust verify_ssl config from cmdline (jkonecny) - Move payload nosslverify to the config files (jkonecny) - Skip some of the driver disk tests (vponco
Re: Removal of krb5-devel from "stable" F29 buidroot broke my package
Vít Ondruch wrote on Thu, May 16, 2019 at 08:28:45AM +0200: > >> This was removed on my request, triggered by this PR [1]. Nevertheless I > >> concur that this should happen just in Rawhide and never be backported > >> into stable releases. > > > > I don't see why this is a problem. Removing an unneeded build > > dependency from a package shouldn't affect anything else. That it did > > merely pointed out a bug in the other package where the build deps > > were incomplete. The problem is not the build dependency, you can get rid of it everywhere without any impact except for openssl itself. What is less transparent is the removal of an actual Require (two actually, zlib-devel is no longer pulled either) ; that can impact other packages and workflows. Someone installing openssl-devel could have expected it to pull krb5-devel and zlib-devel, now they need to install it explicitely separately for their own use as well, it's a change in user interface. > We lived with this "bug" for years. There is no reason to fix this bug > in stable release just to cause other bugs. And it was obvious it would > broke at least build of Ruby and now it is obvious it did broke not just > Ruby. It would be enough to have to solve this issues in Rawhide. > > Also, (not) pulling -devel package into build root might result in some > subtle bugs such as some part of package functionality disabled based on > build configuration, which might went unnoticed, until the package is > released. This is irresponsible. configure with feature autodetection is a PITA :/ -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: xindy, texlive, and concurrency
On Thu, May 16, 2019 at 09:11:21AM +0200, Dridi Boukelmoune wrote:
> On Thu, May 16, 2019 at 3:46 AM Jerry James wrote:
> >
> > I finally found some time to look at the xindy failure to build.
> > First, let me say that I've got a workaround for the problem, which
> > resulted in the beautiful green colors in this xindy-enabled scratch
> > build of texlive-base:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
> >
> > When the build process reached the xindy part of the build, it would
> > successfully build xindy itself, then go to work on some
> > documentation. This involved invoking latex on several input files.
> > This marked the first (and possibly only) point in the build where
> > latex was invoked, so latex.fmt had not yet been generated. Since we
> > build with %{?_smp_mflags}, several independent threads invoked latex
> > at approximately the same time. Every one of those invocations
> > detected that latex.fmt was missing and tried to generate it.
> >
> > If you got lucky, each one of those threads would generate latex.fmt,
> > then quickly consume it as it ran on its appointed input file. If you
> > didn't get lucky, one or more threads would start reading latex.fmt
> > after some other thread started writing it, but before it finished
> > writing it all the way. That's why xindy would sometimes build and
> > sometimes fail to build: the build process had a race condition.
>
> So this is a build system bug from upstream. If concurrency introduces
> a race condition then source-target dependencies are lacking in the
> build system. Depending on the build system it may not be upstream's
> fault, but the tooling itself.
>
> A workaround for the concurrency problem would be an atomic write of
> the generated file. This way even when it is generated multiple times
> while others try to read it they either see a complete or missing file.
>
> The only way I'm aware of for this workaround would be to write to a
> temp file on the same filesystem, and then use mv to rename it
> atomically.
Yes! Check-if-exists, write-to-tmpfile, atomic-rename. If the rename
fails, someone else won the race, so discard the tmpfile, continue
as usual.
So this isn't really a bug in the build system, but a bug in latex
which bungles creation of what is essentially a cache file.
(One expects that a tool like latex may be invoked more than once
at the same time and anything it does internally is its own business).
Let me also add my +1 to the write-up itself, a very nice story.
Zbyszek
> > It is unfortunate that texlive is smart enough to detect missing
> > format files and generate them, but not smart enough to stop that from
> > happening multiple times concurrently. Anyway, poor xindy has been
> > maligned: none of this was xindy's fault, nor clisp's. We, the Fedora
> > packagers, threw concurrency at a job that lacked concurrency control.
> > And the whole xindy_arches thing is useless: this is not an
> > arch-specific problem, so removing random arches from the build
> > accomplishes nothing.
> >
> > The workaround is to invoke latex on a dummy input file early in
> > %build. This causes latex.fmt to be generated, and then everything is
> > hunky-dory when xindy is built later.
> >
> > My recommendation is to remove the xindy_arches conditional from the
> > texlive-base and texlive spec files. Make it unconditionallly on
> > again. Then insert something like this at the top of %build:
> >
> > # Make texlive generate latex.fmt, so that multiple threads do not race to
> > # make it during the xindy build.
> > cat > dummy.tex << EOF
> > \documentclass{article}
> > \begin{document}
> > This is a document.
> > \end{document}
> > EOF
> > latex dummy.tex
> > rm -f dummy.*
> >
> > That is the substance of this pull request:
> >
> > https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
> >
> > Also, I should be able to push a clisp build with s390x support to F30
> > stable tomorrow. I, personally, would really appreciate having xindy
> > reappear in F30, due to Sphinx assuming it is available.
> >
> > Regards,
> > --
> > Jerry James
> > http://www.jamezone.org/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
Re: Removal of krb5-devel from "stable" F29 buidroot broke my package
> configure with feature autodetection is a PITA :/ The PITA doesn't come from auto-detection, rather auto-selection of (optional) dependencies. I tend to prefer explicit --with-* or --enable-* flags for anything optional and fixed defaults. It would be worse if we had to tell a configure script where each individual build dependency can be found! There tend to be more than what meets the eye, much more. Take your average project building with autotools and try this: ./configure --help | less Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
how to create Makefile
Hi, I'm trying to compile the program olive with the help of a spec file [1], which unfortunately fails when creating the Makefile. Have somebody a idea or solution ? [1] https://martinkg.fedorapeople.org/Packages/olive/olive.spec Regars Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: xindy, texlive, and concurrency
On Thu, May 16, 2019 at 9:41 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, May 16, 2019 at 09:11:21AM +0200, Dridi Boukelmoune wrote: > Let me also add my +1 to the write-up itself, a very nice story. > > Zbyszek I may have accidentally skipped the +1 step and jumped straight to suggestions on how to improve the situation, shifting the blame away from _smp_mflags. But I agree this is a very relatable investigation! Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Thursday's FPC Meeting (2019-05-16 16:00 UTC)
On Wed, May 15, 2019 at 05:52:15PM -0400, James Antill wrote: > Following is the list of topics that will be discussed in the FPC > meeting Thursday at 2019-05-16 16:00 UTC in #fedora-meeting-1 on > irc.freenode.net. > > Local time information (via. uitime): > > = Day: Thursday == > 2019-05-16 09:00 PDT US/Pacific > 2019-05-16 12:00 EDT --> US/Eastern <-- > 2019-05-16 16:00 UTC UTC > 2019-05-16 17:00 BST Europe/London > 2019-05-16 18:00 CEST Europe/Berlin > 2019-05-16 18:00 CEST Europe/Paris > 2019-05-16 21:30 IST Asia/Calcutta > New Day: Friday - > 2019-05-17 00:00 HKT Asia/Hong_Kong > 2019-05-17 00:00 +08 Asia/Singapore > 2019-05-17 01:00 JST Asia/Tokyo > 2019-05-17 02:00 AEST Australia/Brisbane > > > Links to all tickets below can be found at: > > https://pagure.io/packaging-committee/issues?status=Open&tags=meeting > > = Followups = > > #topic #845 Wiki deprecation status > .fpc 845 > https://pagure.io/packaging-committee/issue/845 > > #topic #859 Scriptlet to replace a directory: try delete first? > .fpc 859 > https://pagure.io/packaging-committee/issue/859 > > = New business = > > #topic #886 Enable BRP for detecting RPATH > .fpc 886 > https://pagure.io/packaging-committee/issue/886 > > #topic #887 Review Process Exemption: colcon - collective construction > .fpc 887 > https://pagure.io/packaging-committee/issue/887 > > #topic #889 (RE-)Bootstrap Exception for erlang-rebar3 > .fpc 889 > https://pagure.io/packaging-committee/issue/889 > > = Open Floor = Can you please also add https://pagure.io/packaging-committee/pull-request/890? I can be there to answer questions if that helps. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to create Makefile
On Thu, May 16, 2019 at 9:49 AM Martin Gansser wrote: > > Hi, > > I'm trying to compile the program olive with the help of a spec file [1], > which unfortunately fails when creating the Makefile. > Have somebody a idea or solution ? > > [1] https://martinkg.fedorapeople.org/Packages/olive/olive.spec Follow the cmake guidelines, you are missing a "%cmake ." statement before building. https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ Just in case, to my knowledge this is not an acceptable package for Fedora. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to create Makefile
I'm trying to compile the program olive with the help of a spec file [1], which unfortunately fails when creating the Makefile. Have somebody a idea or solution ? qt projects usally uses "qmake" if you have a .pro project file. https://doc.qt.io/archives/3.3/qmake-manual-3.html so long MUFTI ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Removal of krb5-devel from "stable" F29 buidroot broke my package
In meson we automatically set all "auto" features to be "enabled". So people have to disable things they don't want manually. On Thu, May 16, 2019, 10:00 Dridi Boukelmoune wrote: > > configure with feature autodetection is a PITA :/ > > The PITA doesn't come from auto-detection, rather auto-selection of > (optional) dependencies. I tend to prefer explicit --with-* or --enable-* > flags for anything optional and fixed defaults. > > It would be worse if we had to tell a configure script where each > individual build dependency can be found! There tend to be more > than what meets the eye, much more. Take your average project > building with autotools and try this: > > ./configure --help | less > > Dridi > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Removal of krb5-devel from "stable" F29 buidroot broke my package
Dne 16. 05. 19 v 9:20 Dominique Martinet napsal(a): > Vít Ondruch wrote on Thu, May 16, 2019 at 08:28:45AM +0200: This was removed on my request, triggered by this PR [1]. Nevertheless I concur that this should happen just in Rawhide and never be backported into stable releases. >>> I don't see why this is a problem. Removing an unneeded build >>> dependency from a package shouldn't affect anything else. That it did >>> merely pointed out a bug in the other package where the build deps >>> were incomplete. > The problem is not the build dependency, you can get rid of it > everywhere without any impact except for openssl itself. > > What is less transparent is the removal of an actual Require (two > actually, zlib-devel is no longer pulled either) ; that can impact other > packages and workflows. Ah, right, I meant Require of course. I stand corrected. Thx. Vít > Someone installing openssl-devel could have expected it to pull > krb5-devel and zlib-devel, now they need to install it explicitely > separately for their own use as well, it's a change in user interface. > >> We lived with this "bug" for years. There is no reason to fix this bug >> in stable release just to cause other bugs. And it was obvious it would >> broke at least build of Ruby and now it is obvious it did broke not just >> Ruby. It would be enough to have to solve this issues in Rawhide. >> >> Also, (not) pulling -devel package into build root might result in some >> subtle bugs such as some part of package functionality disabled based on >> build configuration, which might went unnoticed, until the package is >> released. This is irresponsible. > configure with feature autodetection is a PITA :/ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
planning on taking python-urwid
Hey, this is just a heads-up that I'm planning on taking python-urwid since it's a dep of 2 of my packages. It's orphaned and I want it to find a new home. Rel-eng ticket will follow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[heads-up] soname version bump for evolution-data-server in rawhide
Hello, next week's 3.33.2 release of evolution-data-server, on 2019-05-20, will contain soname version bumps in libecal, libedata-cal, libebook and libedata-book. At least unless anything bad happens. The main change on the calendar part is that there will be used libical-glib instead of libical, which allows automatic gobject introspection generation. That turned to be as significant change as it worth the calendar API change from version 1.2 to 2.0. The other change on the address book and the calendar parts was about adding a new argument into some methods, which touches both the C API and the D-Bus API, thus there is a version bump on the D-Bus service names as well. [1] Below is the list of affected packages in Fedora, divided into four sections: * Those, which require patching: almanah bijiben (aka gnome-notes) evolution evolution-ews evolution-mapi folks gnome-calendar gnome-shell gnome-todo libopensync libreoffice pidgin-chime syncevolution * Those, which require only rebuild: ekiga evolution-rspam evolution-rss glabels gnome-contacts gnome-phone-manager sflphone * Those, which require patching, but are already retired: california ffgtk * Those, which require work: elementary-calendar wingpanel-indicator-datetime Any existing patches can be found through [3], which contains also links to respective merge requests and bugs, filled to let know the maintainers beforehand. I will rebuild/apply patches to the packages I've commit rights for. I'd need help with others. Especially those two elementary-related packages won't work easily, because they use vala bindings, which they bundle in the sources, thus there is needed a lot of work. One of the elementary developers promised me to look on it once the eds is released. If you find more packages to be ported and you'd like to help with it, just let me know. Bye, Milan [1] This may cause trouble to Flatpak applications, which compile against some version of the evolution-data-server (eds) and then rely on the host system eds D-Bus services (that applies both ways, it won't help to compile against older eds, because the Flatpak application won't work on systems with the new eds). Such applications can run their own eds services, as shown here [2]. The advantage of it is to receive also backend-specific fixes in their Flatpak application, not only client-side fixes. The disadvantage is that the data won't be shared between the applications. [2] https://gitlab.gnome.org/GNOME/evolution/blob/master/flatpak/org.gnome.Evolution-stable.json#L258 [3] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sign_and_send_pubkey: signing failed: agent refused operation
On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote: > Hello, > > I'm getting the following error when I'm access the fedora git trees. > > sign_and_send_pubkey: signing failed: agent refused operation > ste...@pkgs.fedoraproject.org: Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > Now I know I have the correct publickey (id_rsa/id_rsa.pub) > because they work on a different host. and generally > when I have the wrong keys, I get the above error minus > > sign_and_send_pubkey: signing failed: agent refused operation > > Any idea what is happening? What Fedora and OpenSSH version are you using? Does it work if you downgrade openssh? Are you using gnome-keyring? What is the output of "echo $SSH_AUTH_SOCK"? This error means that the agent fails to provide the signature using your private key for some reason. Running the ssh-agent separately in debug mode (ssh-agent -d) might show a bit more information. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sign_and_send_pubkey: signing failed: agent refused operation
On Thu, 16 May 2019 11:11:52 +0200 Jakub Jelen wrote: > On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote: > > Hello, > > > > I'm getting the following error when I'm access the fedora git > > trees. > > > > sign_and_send_pubkey: signing failed: agent refused operation > > ste...@pkgs.fedoraproject.org: Permission denied (publickey). > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > > > Now I know I have the correct publickey (id_rsa/id_rsa.pub) > > because they work on a different host. and generally > > when I have the wrong keys, I get the above error minus > > > > sign_and_send_pubkey: signing failed: agent refused operation > > > > Any idea what is happening? > > What Fedora and OpenSSH version are you using? Does it work if you > downgrade openssh? Are you using gnome-keyring? What is the output of > "echo $SSH_AUTH_SOCK"? probably only for the record as I don't expect many Fedora/ppc64le desktop users here and the problem seems to be ppc64le specific :-) You get the "agent refused operation" there, because the gcr-prompter process (dbus service) crashes when unlocking the ssh key, for more details see https://bugzilla.redhat.com/show_bug.cgi?id=1631759 Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Packages retirement as part of OpenStack clients updates in Rawhide
Hi, OpenStack client packages have been updated in Fedora Rawhide to the latest releases included in recently published Stein version. As part of this update some packages which were required in the past are not longer needed, so i plan to retire them from Fedora: python-automaton python-castellan python-ceilometermiddleware python-cursive python-keystonemiddleware python-microversion-parse python-oslo-cache python-oslo-concurrency python-oslo-messaging python-oslo-middleware python-oslo-policy python-oslo-privsep python-oslo-reports python-oslo-rootwrap python-oslo-service python-oslo-sphinx python-oslo-vmware python-osprofiler python-os-win python-pycadf python-reno python-taskflow According to repoqueries to rawhide, these packages are not longer needed for any other package so it should be safe to get them out but let me know if anything else is needing them in. Best regards, Alfredo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages retirement as part of OpenStack clients updates in Rawhide
On 16. 05. 19 11:38, Alfredo Moralejo Alonso wrote:
Hi,
OpenStack client packages have been updated in Fedora Rawhide to the latest
releases included in recently published Stein version.
As part of this update some packages which were required in the past are not
longer needed, so i plan to retire them from Fedora:
...
python-oslo-sphinx
I might have outdated data, but:
$ dnf repoquery --repo=compose{,-source} --whatrequires python3-oslo-sphinx
diskimage-builder-0:1.26.1-8.fc31.noarch
dlrn-0:0.9.1-1.fc31.src
python-automaton-0:1.14.0-5.fc30.src
python-bash8-0:0.1.1-18.fc30.src
python-bashate-0:0.5.1-11.fc30.src
python-castellan-0:0.5.0-7.fc30.src
python-congressclient-0:1.5.0-10.fc30.src
python-cursive-0:0.1.2-8.fc30.src
python-grafyaml-0:0.0.5-12.fc30.src
python-hacking-0:1.1.0-6.fc31.src
python-k8sclient-0:0.3.0-10.fc30.src
python-keystonemiddleware-0:4.21.0-2.fc30.src
python-microversion-parse-0:0.1.3-11.fc30.src
python-murano-pkg-check-0:0.3.0-11.fc30.src
python-os-testr-0:0.8.0-10.fc31.src
python-os-win-0:2.2.0-9.fc30.src
python-oslo-messaging-0:8.1.2-1.fc31.src
python-oslo-privsep-0:1.13.0-9.fc30.src
python-renderspec-0:1.7.0-8.fc31.src
python-rsd-lib-0:0.5.1-1.fc31.src
python-rsdclient-0:0.2.0-1.fc31.src
python-subunit2sql-0:1.9.0-3.fc30.src
python-taskflow-0:3.4.0-1.fc31.src
python-yaql-0:1.1.3-6.fc30.src
python3-congressclient-tests-0:1.5.0-10.fc30.noarch
I see quite a lot packages that are not listed as being retired.
And this is just one package I picked, I haven't checked all.
Were all those recently updated to remove the depndency?
According to repoqueries to rawhide, these packages are not longer needed for
any other package so it should be safe to get them out but let me know if
anything else is needing them in.
Let's wait for the new compose, so we can double check?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages retirement as part of OpenStack clients updates in Rawhide
On Thu, May 16, 2019 at 11:49 AM Miro Hrončok wrote:
> On 16. 05. 19 11:38, Alfredo Moralejo Alonso wrote:
> > Hi,
> >
> > OpenStack client packages have been updated in Fedora Rawhide to the
> latest
> > releases included in recently published Stein version.
> >
> > As part of this update some packages which were required in the past are
> not
> > longer needed, so i plan to retire them from Fedora:
> >
> > ...
> > python-oslo-sphinx
>
>
> I might have outdated data, but:
>
> $ dnf repoquery --repo=compose{,-source} --whatrequires python3-oslo-sphinx
> diskimage-builder-0:1.26.1-8.fc31.noarch
> dlrn-0:0.9.1-1.fc31.src
> python-automaton-0:1.14.0-5.fc30.src
> python-bash8-0:0.1.1-18.fc30.src
> python-bashate-0:0.5.1-11.fc30.src
> python-castellan-0:0.5.0-7.fc30.src
> python-congressclient-0:1.5.0-10.fc30.src
> python-cursive-0:0.1.2-8.fc30.src
> python-grafyaml-0:0.0.5-12.fc30.src
> python-hacking-0:1.1.0-6.fc31.src
> python-k8sclient-0:0.3.0-10.fc30.src
> python-keystonemiddleware-0:4.21.0-2.fc30.src
> python-microversion-parse-0:0.1.3-11.fc30.src
> python-murano-pkg-check-0:0.3.0-11.fc30.src
> python-os-testr-0:0.8.0-10.fc31.src
> python-os-win-0:2.2.0-9.fc30.src
> python-oslo-messaging-0:8.1.2-1.fc31.src
> python-oslo-privsep-0:1.13.0-9.fc30.src
> python-renderspec-0:1.7.0-8.fc31.src
> python-rsd-lib-0:0.5.1-1.fc31.src
> python-rsdclient-0:0.2.0-1.fc31.src
> python-subunit2sql-0:1.9.0-3.fc30.src
> python-taskflow-0:3.4.0-1.fc31.src
> python-yaql-0:1.1.3-6.fc30.src
> python3-congressclient-tests-0:1.5.0-10.fc30.noarch
>
>
> I see quite a lot packages that are not listed as being retired.
> And this is just one package I picked, I haven't checked all.
>
> Were all those recently updated to remove the depndency?
>
>
Thanks for re-checking, i'll double check it as i see some packages there
which are not being retired.
> > According to repoqueries to rawhide, these packages are not longer
> needed for
> > any other package so it should be safe to get them out but let me know
> if
> > anything else is needing them in.
>
> Let's wait for the new compose, so we can double check?
>
>
Sure.
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to create Makefile
Thanks for your feedback, i switched from qmake to cmake. A review [1] in rpmfusion already exists. [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=5163 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: xindy, texlive, and concurrency
On Thu, 16 May 2019 at 01:51, Vít Ondruch wrote:
> Dear Jerry,
>
> Although I have no idea what xindy is, I enjoyed reading your analysis.
> Thx for your insightful post.
>
>
>
I want to say ++ to this. I have found every one of Mr James articles
explaining all the things he has done to work on, debug, dead-ends, etc to
be insightful and incredibly useful to track down in other software. If you
have a chance, please look up some previous ones.
Thank you again Jerry James. Your work and analysis is deeply appreciated.
> Vít
>
>
> Dne 16. 05. 19 v 3:45 Jerry James napsal(a):
> > I finally found some time to look at the xindy failure to build.
> > First, let me say that I've got a workaround for the problem, which
> > resulted in the beautiful green colors in this xindy-enabled scratch
> > build of texlive-base:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
> >
> > When the build process reached the xindy part of the build, it would
> > successfully build xindy itself, then go to work on some
> > documentation. This involved invoking latex on several input files.
> > This marked the first (and possibly only) point in the build where
> > latex was invoked, so latex.fmt had not yet been generated. Since we
> > build with %{?_smp_mflags}, several independent threads invoked latex
> > at approximately the same time. Every one of those invocations
> > detected that latex.fmt was missing and tried to generate it.
> >
> > If you got lucky, each one of those threads would generate latex.fmt,
> > then quickly consume it as it ran on its appointed input file. If you
> > didn't get lucky, one or more threads would start reading latex.fmt
> > after some other thread started writing it, but before it finished
> > writing it all the way. That's why xindy would sometimes build and
> > sometimes fail to build: the build process had a race condition.
> >
> > It is unfortunate that texlive is smart enough to detect missing
> > format files and generate them, but not smart enough to stop that from
> > happening multiple times concurrently. Anyway, poor xindy has been
> > maligned: none of this was xindy's fault, nor clisp's. We, the Fedora
> > packagers, threw concurrency at a job that lacked concurrency control.
> > And the whole xindy_arches thing is useless: this is not an
> > arch-specific problem, so removing random arches from the build
> > accomplishes nothing.
> >
> > The workaround is to invoke latex on a dummy input file early in
> > %build. This causes latex.fmt to be generated, and then everything is
> > hunky-dory when xindy is built later.
> >
> > My recommendation is to remove the xindy_arches conditional from the
> > texlive-base and texlive spec files. Make it unconditionallly on
> > again. Then insert something like this at the top of %build:
> >
> > # Make texlive generate latex.fmt, so that multiple threads do not race
> to
> > # make it during the xindy build.
> > cat > dummy.tex << EOF
> > \documentclass{article}
> > \begin{document}
> > This is a document.
> > \end{document}
> > EOF
> > latex dummy.tex
> > rm -f dummy.*
> >
> > That is the substance of this pull request:
> >
> > https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
> >
> > Also, I should be able to push a clisp build with s390x support to F30
> > stable tomorrow. I, personally, would really appreciate having xindy
> > reappear in F30, due to Sphinx assuming it is available.
> >
> > Regards,
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora and the MDS CVEs
For those of you wondering the Fedora status of the MDS CVEs that went public on Tuesday. Here is where we stand: kernel-5.0.16 and microcode_ctl-2.1-29 contain the initial mitigations for kernel/microcode, and are in stable updates for F29 and F30, The kernel is still in updates-testing for F28 as it needs karma, but should make it to regular updates soon. libvirt and qemu have updates in updates-testing across all releases. F29 and F30 updates will push to stable today, and F28 still needs karma. All updates, once they hit stable, may take a day or two to reach all mirrors, so if you do not see it available, you can keep trying, or go directly to the main mirror. If you do not know what the MDS CVEs are, or would like more infomation on them, there is a good write up at https://access.redhat.com/security/vulnerabilities/mds Thanks, Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages retirement as part of OpenStack clients updates in Rawhide
On Thu, May 16, 2019 at 12:10 PM Alfredo Moralejo Alonso <
amora...@redhat.com> wrote:
>
>
> On Thu, May 16, 2019 at 11:49 AM Miro Hrončok wrote:
>
>> On 16. 05. 19 11:38, Alfredo Moralejo Alonso wrote:
>> > Hi,
>> >
>> > OpenStack client packages have been updated in Fedora Rawhide to the
>> latest
>> > releases included in recently published Stein version.
>> >
>> > As part of this update some packages which were required in the past
>> are not
>> > longer needed, so i plan to retire them from Fedora:
>> >
>> > ...
>> > python-oslo-sphinx
>>
>>
>> I might have outdated data, but:
>>
>> $ dnf repoquery --repo=compose{,-source} --whatrequires
>> python3-oslo-sphinx
>> diskimage-builder-0:1.26.1-8.fc31.noarch
>> dlrn-0:0.9.1-1.fc31.src
>> python-automaton-0:1.14.0-5.fc30.src
>> python-bash8-0:0.1.1-18.fc30.src
>> python-bashate-0:0.5.1-11.fc30.src
>> python-castellan-0:0.5.0-7.fc30.src
>> python-congressclient-0:1.5.0-10.fc30.src
>> python-cursive-0:0.1.2-8.fc30.src
>> python-grafyaml-0:0.0.5-12.fc30.src
>> python-hacking-0:1.1.0-6.fc31.src
>> python-k8sclient-0:0.3.0-10.fc30.src
>> python-keystonemiddleware-0:4.21.0-2.fc30.src
>> python-microversion-parse-0:0.1.3-11.fc30.src
>> python-murano-pkg-check-0:0.3.0-11.fc30.src
>> python-os-testr-0:0.8.0-10.fc31.src
>> python-os-win-0:2.2.0-9.fc30.src
>> python-oslo-messaging-0:8.1.2-1.fc31.src
>> python-oslo-privsep-0:1.13.0-9.fc30.src
>> python-renderspec-0:1.7.0-8.fc31.src
>> python-rsd-lib-0:0.5.1-1.fc31.src
>> python-rsdclient-0:0.2.0-1.fc31.src
>> python-subunit2sql-0:1.9.0-3.fc30.src
>> python-taskflow-0:3.4.0-1.fc31.src
>> python-yaql-0:1.1.3-6.fc30.src
>> python3-congressclient-tests-0:1.5.0-10.fc30.noarch
>>
>>
>> I see quite a lot packages that are not listed as being retired.
>> And this is just one package I picked, I haven't checked all.
>>
>> Were all those recently updated to remove the depndency?
>>
>>
> Thanks for re-checking, i'll double check it as i see some packages there
> which are not being retired.
>
After checking again, following packages from the proposed list are still
needed by others:
- python-oslo-sphinx
- python-oslo-concurrency (needed by copr-backend).
I'll update both to latest releases.
>
>
>> > According to repoqueries to rawhide, these packages are not longer
>> needed for
>> > any other package so it should be safe to get them out but let me know
>> if
>> > anything else is needing them in.
>>
>> Let's wait for the new compose, so we can double check?
>>
>>
> Sure.
>
>
BTW, to move on I need to get a couple of PRs merged:
https://src.fedoraproject.org/rpms/python-congressclient/pull-request/1
https://src.fedoraproject.org/rpms/python-mistralclient/pull-request/3
I'm trying to contact the maintainer to get them merged.
> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > ``` > > $ docker run --rm -t arm64v8/fedora:30 uname -m > > standard_init_linux.go:207: exec user process caused "no such file or > > directory" > > ``` > > you should just run > $ docker run --rm -t fedora:30 uname -m > on all arches, we push manifest listed containers to dockerhub so that > command will work everywhere. Alright, I did not know the kind of alias feature. Thanks for the info. -- Jun Aruga / He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > you should just run > > $ docker run --rm -t fedora:30 uname -m > > on all arches, we push manifest listed containers to dockerhub so that > > command will work everywhere. > > Alright, I did not know the kind of alias feature. Thanks for the info. But my motivation is not like * Running x86_64 container on x86_64 machine * Running aarch64 container on aarch64 machine ... but * Running aarch64, s390x, ppc64le and etc containers on x86_64 machine. The reason is that makes multi arch's tests enable on x86_64 environment or x86_64 base CI service. -- Jun Aruga / He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sign_and_send_pubkey: signing failed: agent refused operation
On Wed, May 15, 2019 at 05:09:41PM -0400, Steve Dickson wrote: > Hello, > > I'm getting the following error when I'm access the fedora git trees. > > sign_and_send_pubkey: signing failed: agent refused operation > ste...@pkgs.fedoraproject.org: Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > Now I know I have the correct publickey (id_rsa/id_rsa.pub) > because they work on a different host. and generally > when I have the wrong keys, I get the above error minus > > sign_and_send_pubkey: signing failed: agent refused operation > > Any idea what is happening? Do you have multiple keys loaded? ISTR hitting this when I had a large number of different keys and it would hit a limit trying them. In my ~/.ssh/config I have this: HOST *.fedoraproject.org fedorapeople.org *.fedorahosted.org fedorahosted.org IdentityFile ~/.ssh/fedora to force it to use the right key on the 1st try. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
is anyone using /usr/sbin/halt.local?
There's a proposal to drop the support for this pre-systemd compat feature, but if it's actually used, we'll keep it. C.f. https://github.com/systemd/systemd/pull/12571. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x: hanging koji build
I'd like to thank everyone who contributed time + provided guidance on this issue. I just build a working version of borgbackup and which is on its way to the F30 testing repository. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Elections: Nomination period open
This is your reminder that elections nominations are open through Wednesday 2019-05-22 at 23:59:59 UTC. On Wed, May 8, 2019 at 9:08 AM Ben Cotton wrote: > > Today we are starting the Nomination & Campaign period during which we > accept nominations to the "steering bodies" of the following teams: > > * FESCo (Engineering) (4 seats) [1] > * Fedora Council (1 seat) [2] > * Mindshare (1 seat) [3] > > This period is open until 2019-05-22 at 23:59:59 UTC. > > Candidates may self-nominate. If you nominate someone else, please > check with them to ensure that they are willing to be nominated before > submitting their name. > > The steering bodies are currently selecting interview questions for > the candidates. > > Nominees submit their questionnaire answers via a private Pagure > issue. The Election Wrangler or their backup will publish the > interviews to the Community Blog before the start of the voting > period. Fedora Podcast episodes will be recorded and published as > well. > > Please note that the interview is mandatory for all nominees. Nominees > not having their interview ready by end of the Interview period > (2019-05-29) will be disqualified and removed from the election. > > As part of the campaign people may also ask questions to specific > candidates on the appropriate mailing list. > > The full schedule of the elections is available on the Elections > schedule[4]. For more information about the elections process, see the > wiki[5]. > > [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > [2] https://fedoraproject.org/wiki/Council/Nominations > [3] https://fedoraproject.org/wiki/Mindshare/Nominations > [4] https://fedorapeople.org/groups/schedule/f-30/f-30-elections.html > [5] https://fedoraproject.org/wiki/Elections > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd == Summary == The upstream OpenSSH disabled password logins for root back in 2015. The Fedora should follow to keep security expectation and avoid users surprises with this configuration. == Owner == * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer * Email: jje...@redhat.com == Detailed Description == The OpenSSH server configuration contains a configuration option `PermitRootLogin`, which controls whether the root user is allowed to login using passwords or using public key authentication. The root login is target of most of the random or targeted attack on Linux systems and password is usually the weakest part. For that reason, the upstream OpenSSH changed this option in 2015 to `prohibit-password`, which still allows public-key authentication, but prevents the password logins. Fedora was for many practical reasons keeping the old configuration since then, but the difference is no longer bearable and might confuse users expecting the root logins will not be enabled out of the box. On the other hand, there is still a lot of infrastructure, installers and test instances that simply might depend on this configuration and therefore this change needs to go through the system-wide change so everyone is onboard. == Benefit to Fedora == This will provide more secure Fedora installations out of the box and prevent inadvertently accessible root logins in the wild. == Scope == * Proposal owners: Modify the default shipped sshd configuration in `sshd_config` to no longer include the `PermitRootLogin yes` option and advertise this change throughout Fedora. * Other developers: Make sure their workflow does not include logging in as a root to ssh, otherwise modify that workflow * Release engineering: [https://pagure.io/releng/issues/8342] * Policies and guidelines: none * Trademark approval: none == Upgrade/compatibility impact == The updates of previously-modified `sshd_config` will not be affected and create a `.rpmnew` configuration file. The updates of default `sshd_config` will be updated and the modification needs to be listed in release notes to prevent surprises. == How To Test == * Make sure you have root user with password and you can login to this user using `su` * Make sure the sshd_config does not contain `PermitRootLogin yes` option * Restart sshd service: `systemctl restart sshd` * Try to connect to root user: `ssh -oPreferredAuthentications=password root@localhost` * Should fail Other authentication methods (publickey, gssapi should not be affected) == User Experience == Nothing in production should really depend on root password logins in 2019. If it does, it is the time to change that (or explicitly allow it on the affected systems). == Dependencies == Installer and kickstarts depending on this functionality. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Maintainer will revert the change to sshd_config if needed. * Contingency deadline: Beta freeze * Blocks release? no * Blocks product? no == Documentation == OpenSSH in Fedora 31 does not allow root logins using passwords by default. Upstream release notes: http://www.openssh.com/txt/release-7.0 == Release Notes == OpenSSH in Fedora 31 does not allow root logins using passwords by default. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: perl 5.30
https://fedoraproject.org/wiki/Changes/perl5.30
== Summary ==
A new ''perl 5.30'' version brings a lot of changes done over a year
of development. Perl 5.30 should be released at the end of May 2019.
See [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta] for more details about preparing release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]]
* Email:
* Name: [[User:Ppisar| Petr Písař]]
* Email:
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Upstream to release Perl 5.30
* Get dedicated build-root from rel-engs (''f31-perl'')
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.30.0
* Build new perl 5.30 keeping old COMPAT Provides
* Rebuild dual-lived packages (otherwise dnf recommends --skip-broken and fails)
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Remove old perl(:MODULE_COMPAT_5.28.*) from perl
* Undefine perl_bootstrap
* Rebuild other packages: Use Fedora::Rebuild dependency solver
* Rebuild packages having perl_bootstrap condition in spec file
* Rebuild all updated packages
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f31'' build root
* Rebuilt Perl packages: 0 of 3186 done (0.00 %)
* Failed builds (0):
* Unsatisfied dependencies (0):
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.30.0 version is stable release
this year.
In addition, Perl ''site'' paths will be made ABI-specific. CPAN
modules intended for an installation under /usr/local/ will be
installed to /usr/local/{share,lib*}/perl5/5.30 paths. This will
prevent from breaking Perl with old locally installed modules after a
Fedora upgrade.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f31-perl''
build-root against perl 5.30.0 and then if no major problem emerges
the packages will be merged back to ''f31'' build-root.
* Proposal owners:
New perl and all packages requiring perl or a Perl module will be
rebuilt into ''f31-perl'' build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issue/8368 #8368] (a
check of an impact with Release Engineering is needed)
Release engineers will be asked for new ''f31-perl'' build-root
inheriting from ''f31'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f31-perl'' packages back to
''f31'' build-root.
* Policies and guidelines:
No policies have to be modified to complete this change.
== Upgrade/Compatibility Impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.30 will be removed from the
distribution. That will require to remove those packages from existing
systems otherwise package manager will encounter unsatisfied
dependencies. Modules installed locally into /usr/local will become
unavailable and users will need to reinstall them.
== How to Test ==
Try upgrading from Fedora 30 to 31. Try some Perl application to
verify they work as expected. Try embedded perl in slapd or snmpd.
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstalation.
== Dependencies ==
There is more than 3100 packages depending on perl. Most of them are
expected not to break. Finishing this change can be endangered only by
critical changes in a toolchain.
== Contingency Plan ==
If we find perl 5.30 is not suitable for Fedora 31, we will revert
back to perl 5.28 and we drop the temporary build-root with already
rebuilt packages.
* Contingency deadline: branching Fedora 31 from Rawhide.
* Blocks release? No.
== Documentation ==
* [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta]
* An announcement on the perl-devel mailing list
*
[https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org/thread/YLWW33T7C4LTQY5XQ6E6PXOZUGYTP27M/
Making Perl site paths ABI-specific] discussion on perl-devel mailing
list
== Release Notes ==
=== Important Changes ===
* Unicode 11, 12 and draft 12.1 is supported
* The upper limit "n" specifiable in a regular expression quantifier
of the form "{m,n}" has been doubled to 65534
* Wildcards in Unicode property value specifications are now partially supported
* qr'\N{name}' is now supported
* It is now possible to compile perl to always use thread-safe locale
operations.
* Limited variable length lookbehind in regular expression pattern
matching is now experimentally supported
* Use faster met
Self Introduction: Jordan Ogas
Greetings, My name is Jordan, I'm a member of the Programming and Runtime Environment team for the High Performance Computing Division (HPC) at the Los Alamos National Laboratory (LANL). I have been encouraged by my package reviewer, Dave Love, to introduce myself to the community in an effort to assimilate Fedora packaging culture and increase the likely hood of being sponsored. It is my goal to become the official Charliecloud package maintainer and an expert in software packaging. The Charliecloud package under review is the first package I've ever created. Thus, I am hoping to find a sponsor who will be patient with me as I continue to grow and learn from my mistakes. As a member of the PRE team at LANL I am responsible for testing and maintaining programming environments on a large collection of super computers with various specifications, e.g., hardware, architecture (hello aarch64), interconnects, size, etc. I spend a lot of time contributing to LANL's novel unprivileged Linux container runtime, Charliecloud. Outside of work you can usually find me relaxing with my wife or taming dinosaurs and dying to piranhas in the video game 'Ark: Survival Evolved' with my 9 year old son. Package under review (in need of sponsorship): https://bugzilla.redhat.com/show_bug.cgi?id=1690046 Best, Jordan Ogas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
On 16/05/19 14:53 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd == Summary == The upstream OpenSSH disabled password logins for root back in 2015. The Fedora should follow to keep security expectation and avoid users surprises with this configuration. Hoorah! This is one of the first things I change every time I install Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sign_and_send_pubkey: signing failed: agent refused operation
On 5/16/19 5:11 AM, Jakub Jelen wrote: > On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote: >> Hello, >> >> I'm getting the following error when I'm access the fedora git trees. >> >> sign_and_send_pubkey: signing failed: agent refused operation >> ste...@pkgs.fedoraproject.org: Permission denied (publickey). >> fatal: Could not read from remote repository. >> >> Please make sure you have the correct access rights >> and the repository exists. >> >> Now I know I have the correct publickey (id_rsa/id_rsa.pub) >> because they work on a different host. and generally >> when I have the wrong keys, I get the above error minus >> >> sign_and_send_pubkey: signing failed: agent refused operation >> >> Any idea what is happening? > > What Fedora and OpenSSH version are you using? Update F29 and openssh-7.9p1-5.fc29 > Does it work if you downgrade openssh? Do do for some reason things started working again w/out a downgrade. Are you using gnome-keyring? No. > What is the output of "echo $SSH_AUTH_SOCK"? /run/user/3606/keyring/ssh > > This error means that the agent fails to provide the signature using > your private key for some reason. Running the ssh-agent separately in > debug mode (ssh-agent -d) might show a bit more information. OK... thanks for the tip... but like I said.. things just started working again... Maybe was because I am on a remote Oracle campus? ;-) Thanks! steved. > > Regards, > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Jordan Ogas
On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote: > > Greetings, > > > > My name is Jordan, I'm a member of the Programming and Runtime Environment > > team for the High Performance Computing Division (HPC) at the Los Alamos > > National Laboratory (LANL). I have been encouraged by my package reviewer, > > Dave Love, to introduce myself to the community in an effort to assimilate > > Fedora packaging culture and increase the likely hood of being sponsored. > > > > It is my goal to become the official Charliecloud package maintainer > and an expert > > in software packaging. The Charliecloud package under review is the > first package > > I've ever created. Thus, I am hoping to find a sponsor who will be > patient with me > > as I continue to grow and learn from my mistakes. > > > > As a member of the PRE team at LANL I am responsible for testing and > > maintaining programming environments on a large collection of super > computers > > with various specifications, e.g., hardware, architecture (hello aarch64), > > interconnects, size, etc. I spend a lot of time contributing to LANL's > novel > > unprivileged Linux container runtime, Charliecloud. > Have you experimented and played with rootless podman? > > > > Outside of work you can usually find me relaxing with my wife or taming > > dinosaurs and dying to piranhas in the video game 'Ark: Survival > Evolved' with > > my 9 year old son. > > > > Package under review (in need of sponsorship): > > https://bugzilla.redhat.com/show_bug.cgi?id=1690046 > > > > Best, > > > > Jordan Ogas > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Atomic Host Two Week Release Announcement: 29.20190516.0
A new Fedora Atomic Host update is available via an OSTree update: Version: 29.20190516.0 Commit(x86_64): 7f719bf60b865ca96aacd0e8ae3e6074c7eb5783d8ceb9003dbba5dfd5a29ba3 Commit(aarch64): 3930a03b8ffcce1aa66f17b8811e2a4da80aedb8234a1f47b62d603986b580ec Commit(ppc64le): 144bb02d1485234b79ba385b47dc64199a7df159d3a0a3f17837cc7fb90cf7e1 We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time. Existing systems can be upgraded in place via e.g. `atomic host upgrade`. Corresponding image media for new installations can be downloaded from: https://getfedora.org/en/atomic/download/ Alternatively, image artifacts can be found at the following links: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0.aarch64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0.aarch64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190516.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0.ppc64le.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0.ppc64le.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190516.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0.x86_64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0.x86_64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190516.0.x86_64.vagrant-libvirt.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190516.0.x86_64.vagrant-virtualbox.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190516.0.iso Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190516.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190516.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0-x86_64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190516.0-x86_64-CHECKSUM For direct download, the "latest" targets are always available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest https://getfedora.org/atomic_raw_x86_64_latest https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest https://getfedora.org/atomic_dvd_ostree_x86_64_latest aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest https://getfedora.org/atomic_raw_aarch64_latest https://getfedora.org/atomic_dvd_ostree_aarch64_latest ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest https://getfedora.org/atomic_raw_ppc64le_latest https://getfedora.org/atomic_dvd_ostree_ppc64le_latest Filename fetching URLs are available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest_filename https://getfedora.org/atomic_raw_x86_64_latest_filename https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest_filename https://getfedora.org/atomic_raw_aarch64_latest_filename https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest_filename https://getfedora.org/atomic_raw_ppc64le_latest_filename https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam
Re: s390x: hanging koji build
On Thu, May 16, 2019 at 12:37 PM Felix Schwarz wrote: > I'd like to thank everyone who contributed time + provided guidance on this > issue. I just build a working version of borgbackup and which is on its way to > the F30 testing repository. Great news! I really like the spirit of helpfulness and collaboration that the Fedora community has. It has kept me hanging around lo these many years. :-) Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: xindy, texlive, and concurrency
On Thu, May 16, 2019 at 5:55 AM Stephen John Smoogen wrote: > I want to say ++ to this. I have found every one of Mr James articles > explaining all the things he has done to work on, debug, dead-ends, etc to be > insightful and incredibly useful to track down in other software. If you have > a chance, please look up some previous ones. > > Thank you again Jerry James. Your work and analysis is deeply appreciated. Awww, you guys are making me blush. Thank you for the kind words. I actually enjoy ferreting out problems in software, which probably makes me some kind of oddball. Heck, the rest of you are probably oddballs, too. :-) And, going off on a really steep tangent, I was just reading about Flock and wishing I could go. I've been hanging around the Fedora community for something on the order of 14 years now, believe it or not, and I have yet to meet a single other Fedora contributor in person. There's no way I'm going to make it to Hungary, I'm afraid. What is coming up in North America in the next year or so that will have significant numbers of Fedorans present? I would love to put some faces to the names I've been seeing on my screen all these years. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Fri, 30 Nov 2018 at 13:42, Miro Hrončok wrote: > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure that the package should be retired, please do so now with a proper > reason: > > Orphaned packages: > > ladspa-swh-plugins orphan 59 weeks ago Hi. Somehow I missed this email from November, perhaps because I was not a co-maintainer. ladspa-swh-plugins got retired 3 weeks ago. Now we cannot install jamin in F30, as it requires ladspa-swh-plugins. https://bugzilla.redhat.com/show_bug.cgi?id=1709735 Is it too late to unretire ladspa-swh-plugins now? I can take it over. Does it need a re-review? It's an old package, and should build without any changes. Thanks, Orcan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
arm03-packager00: wrong Rawhide mock config
Where should problem reports with the test machines be directed? I can't build for Rawhide in mock on arm03-packager00 because /etc/mock/fedora-rawhide-armhfp.cfg refers to Fedora 30. The correct config is in /etc/mock/fedora-rawhide-armhfp.cfg.rpmnew. Can somebody with admin privileges fix that up, please? In the meantime, I'll just make my own copy of the config and move on, but that really should be fixed. Thanks, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Thu, 2019-05-16 at 22:23 -0400, Orcan Ogetbil wrote: > On Fri, 30 Nov 2018 at 13:42, Miro Hrončok wrote: > > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. If you know > > for > > sure that the package should be retired, please do so now with a > > proper > > reason: > > > > Orphaned packages: > > > > ladspa-swh-plugins orphan 59 weeks ago > > Hi. Somehow I missed this email from November, perhaps because I was > not a co-maintainer. > ladspa-swh-plugins got retired 3 weeks ago. Now we cannot install > jamin in F30, as it requires ladspa-swh-plugins. > https://bugzilla.redhat.com/show_bug.cgi?id=1709735 > Is it too late to unretire ladspa-swh-plugins now? I can take it > over. > Does it need a re-review? It's an old package, and should build > without any changes. Now we have 8 weeks [1] but ladspa-swh-plugins [2] was retired 5 months ago, so we need a re-review [3], if you unretire it please let me know,flowblade also may use it . Thanks. [1] https://pagure.io/fesco/issue/2089 [2] https://src.fedoraproject.org/rpms/ladspa-swh-plugins [3] https://pagure.io/releng/issue/8120 [3] > Thanks, > Orcan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sign_and_send_pubkey: signing failed: agent refused operation
On Thu, 2019-05-16 at 15:31 -0400, Steve Dickson wrote: > > On 5/16/19 5:11 AM, Jakub Jelen wrote: > > On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote: > > > Hello, > > > > > > I'm getting the following error when I'm access the fedora git > > > trees. > > > > > > sign_and_send_pubkey: signing failed: agent refused operation > > > ste...@pkgs.fedoraproject.org: Permission denied (publickey). > > > fatal: Could not read from remote repository. > > > > > > Please make sure you have the correct access rights > > > and the repository exists. > > > > > > Now I know I have the correct publickey (id_rsa/id_rsa.pub) > > > because they work on a different host. and generally > > > when I have the wrong keys, I get the above error minus > > > > > > sign_and_send_pubkey: signing failed: agent refused operation > > > > > > Any idea what is happening? > > > > What Fedora and OpenSSH version are you using? > Update F29 and openssh-7.9p1-5.fc29 This one is in the wild for quite a long time. > > Does it work if you downgrade openssh? > Do do for some reason things started working again w/out a > downgrade. > > Are you using gnome-keyring? > No. > > > What is the output of "echo $SSH_AUTH_SOCK"? > /run/user/3606/keyring/ssh This is the path used by gnome-keyring. But internally, the gnome keyring is using the openssh's ssh-agent in recent versions so there is still quite many moving parts. > > This error means that the agent fails to provide the signature > > using > > your private key for some reason. Running the ssh-agent separately > > in > > debug mode (ssh-agent -d) might show a bit more information. > OK... thanks for the tip... but like I said.. things just started > working again... Maybe was because I am on a remote Oracle campus? ;- > ) Good to hear that it works now. Please, let me know if you would see something weird going on with openssh. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
