Re: Fedora Packaging Guidelines on docs.fedoraproject.org
On 1.10.2018 23:38, Neal Gompa wrote: On Mon, Oct 1, 2018 at 5:03 PM Björn Persson wrote: Jason L Tibbitts III wrote: Indeed, asciidoctor works a bit better than asciidoc does but still converts quickly. It's actually in the "rubygem-asciidoctor" package. Maybe I'll try that next time I have some free time. This is giving me a "best viewed with Netscape Navigator" feeling though. Not only are there several different badly designed document authoring languages, but they're apparently even splitting into tool-specific dialects. I'm wondering if it was a good idea to use asciidoc in the first place. Unlike reStructuredText, asciidoc implementations seem to be in very poor shape. While the entire situation (the tool used is not packages, the conversion is incomplete) is not perfect, I wouldn't blame it on asciidoc implementations. asciidoctor is very good actually and I don't see why to consider it "very poor shape". I have much more experience with sphinx + rst and in fact would personally liked it more, but there's nothing wrong with asciidoc markup. What's wrong is the need of using magic containers to build the docs. But that's most entirely not asciidoc's fault. -- 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: Orphaned python2-matplotlib
On 1.10.2018 19:29, Miro Hrončok wrote:
On 1.10.2018 18:29, Miro Hrončok wrote:
On 1.10.2018 17:55, Jason L Tibbitts III wrote:
"SJS" == Stephen John Smoogen writes:
SJS> What packages? And where are they depending on it?
I believe the underlying issue is that previously the Fedora
python-matplotib package produced both python2 and python3 subpackages.
But recently it dropped support for python2.
Yes.
What I don't understand is:
1) Why my access was removed from the package and set to 'orphan'.
There is no separate set of permissions for EPEL branches but I'd think
that the new Fedora maintainer would have been simply added to the list
of admins.
I haven't in any way removed you form the package. I simply followed
this procedure:
1. package review: https://bugzilla.redhat.com/show_bug.cgi?id=1630799
2. requesting a dist-git repo:
https://pagure.io/releng/fedora-scm-requests/issue/8211
3. the repo exists, unretire on Fedora:
https://pagure.io/releng/issue/7826
("It doesn't really exist in EPEL; the current EPEL package is just a
stub that depends on python-matplotlib. The Fedora package will be a
completely different thing. There shouldn't be any conflict between
them.")
So apparently, this is where you were removed, because I wrote:
> FAS username of the new maintainer? churchyard
And that simply meant "replace current main admin with me".
This was certainly not intended. I've also cced you in the request so
you are aware of the unretirement. Neither of us noticed the consequence.
4. imported with history
https://src.fedoraproject.org/rpms/python2-matplotlib/pull-request/1
5. built
6. announced
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PWZLITS74FYXASZGDF4W7G7LNJNYY4H5/
7. orphaned when I no longer wanted to maintain it. no other
maintainers were present at this point.
Note that at the point, I haven't noticed that this is weird. I should
have. I've only seen it as an action that removes me.
If at any point of the process you got kicked out of the package, this
was certainly not my intent.
2) Why a package was added and then immediately orphaned. In an attempt
to clean up the mess I'm told that there's now a six week period of time
during which the package has to stay live. So this package was imported
with no expectation that it would be maintained only to start some
running clock. And for the duration of that clock, I get to keep the
mess by default?
The package was added because it was needed. It was orphaned because I
don't want to maintain it. Or do I have to maintain the package for
ever juts because I've put it in there? What's the difference between
orphaning it 1 week after introducing it, 1 year or a decade?
My idea and motivation here was that somebody who needs it will take it.
I've tried. Nobody wanted it. I've orphaned it, hoping that once it
appears in the "orphaned packages in need for maintainers"
announcement, somebody will take it.
The "mess" was not "yours" to keep. There was never any mess in the
EPEL branch(es). The only mess that exists now is that the package was
retired and things will start FTBFS and have broken deps (on Fedora),
how can we sort this mess out, I have no idea. Certainly we can
unretire it, but I won't do it just to have it retired again as a mess
that needs to get out.
I'm rather unhappy about this. I had previously raised my objection to
this and requested coordination in this FESCo comment:
https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
happened anyway.
I haven't read that as objection. I've understand it as confusion.
You've asked to tell you if there is somebody to give this package to.
There is nobody. Nobody wants it.
Also, in the releng ticket you've pointed out that this will in no way
clash with the EPEL package. Yet now it seems you retired the package
only because you are the maintainer of the EPEL package (or at least
you should have remained the maintainer).
I don't understand what I've done wrong. I think that every maintainer
has a right to orphan a package at any time.
On the other hand, just retiring a package that other packages depend
on seems like a weird way of dealing with a problem.
I'm sorry that you were removed form the package. It was not by my
action. It might have been a side effect of the unretirement (I
haven't anticipated that side effect).
I'm very sorry that you feel like I went behind your back and like I
did a wrong thing here. This was no trick, this was no calculated move
to strip the package from you or to create a pressure on some other
packagers. This was a simple scenario:
* split a package into two halves
* orphan one of the halves that I don't want to maintain
In fact, I was planning to this for python-SecretStorage as well.
Should I rather not? What should be the correct way of doing this?
And what shall happen with python2-matplotlib in Fedora?
Fedora 29-20181001.n.0 compose check report
No missing expected images. Failed openQA tests: 10/133 (x86_64), 1/2 (arm) ID: 287534 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/287534 ID: 287551 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/287551 ID: 287570 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/287570 ID: 287584 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/287584 ID: 287589 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/287589 ID: 287594 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/287594 ID: 287601 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/287601 ID: 287633 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/287633 ID: 287644 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/287644 ID: 287666 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/287666 ID: 287667 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/287667 Soft failed openQA tests: 3/133 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 287529 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/287529 ID: 287530 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287530 ID: 287556 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/287556 ID: 287557 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/287557 ID: 287607 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/287607 Passed openQA tests: 119/133 (x86_64), 22/24 (i386) Skipped openQA tests: 2 of 159 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Non-responsive package maintainer - Ray Strode (halfline), Plymouth package
On Mon, 2018-10-01 at 16:52 -0400, Ray Strode wrote: > Hi, > On Mon, Oct 1, 2018 at 4:29 PM Stephen < > fedora201...@nuclearsunshine.com> wrote: > > The maintainer for Plymouth, Ray Strode (halfline), is not > > addressing > > its bugs on RHBZ (one response all year on a single bug, accepting > > a > > patch), including showstopper bugs that are preventing boot > > entirely in > > some instances. > > I'm around, but I work on a lot of stuff. plymouth doesn't get a lot > of attention, > since it basically works. Hi Ray, unfortunately in some cases it doesn't though. It's currently completely breaking boot with amdgpu+LUKS, and before that for several months under amdgpu it was not echoing LUKS characters to screen or otherwise updating at all after showing the LUKS prompt, making it seem that password entry was not working and the boot process had frozen. > It doesn't see as much development as some > components because other parts of the stack have been prioritized. > > Having said that, Hans de Goede has taken up the mantle of improving > the > boot experience recently, including some changes to plymouth. So you > should > see some changes soon. > > plymouth does get fixes for blocker issues when necessary, and i > still give it > some attention upstream. > > It is receiving the amount resources we considered appropriate at the > moment. Plymouth sits in the unusual position of being simultaneously boot- critical when enabled, and not actually necessary to the boot process (AFAIK?) I believe there's a fair case to be made that for a component with these unusual characteristics to be default-enabled in Fedora, it needs enough maintenance resources available for it to continue to work (modulo short breakages) on at least non-esoteric hardware with which Fedora otherwise works. I'm not jumping up and down demanding "devote all your time to fix my Plymouth bug(s)!" ;) (I've disabled RHGB for now on my system in any case); rather saying that if there aren't enough resources to make this level of maintenance realistic at the moment, it might be worth looking at whether it's still a good idea for Plymouth to continue to be enabled by default? Alternatively, if a reasonably flexible blacklist is possible (or exists?), that might be lower-maintenance, and obviously less nuclear option than default-disabling Plymouth. > > --Ray > ___ > 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 29 compose report: 20181001.n.0 changes
OLD: Fedora-29-20180929.n.0 NEW: Fedora-29-20181001.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 3 Dropped packages:2 Upgraded packages: 79 Downgraded packages: 0 Size of added packages: 11.11 MiB Size of dropped packages:11.81 MiB Size of upgraded packages: 3.39 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 186.37 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-29-20180929.n.0.s390x.tar.xz Image: AtomicHost vagrant-libvirt x86_64 Path: AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20180929.n.0.x86_64.vagrant-libvirt.box Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-29-20180929.n.0.s390x.tar.xz Image: AtomicHost vagrant-virtualbox x86_64 Path: AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20180929.n.0.x86_64.vagrant-virtualbox.box = ADDED PACKAGES = Package: python-emoji-0.5.1-1.fc29 Summary: Emoji library for Python RPMs:python3-emoji Size:62.80 KiB Package: stratisd-1.0.0-1.module_2238+b7fada88 Summary: Daemon that manages block devices to create filesystems RPMs:stratisd Size:11.04 MiB Package: twa-1.3.1-1.fc29 Summary: Tiny web auditor with strong opinions RPMs:twa Size:14.62 KiB = DROPPED PACKAGES = Package: nini-1.1.0-16.fc29 Summary: .NET configuration library RPMs:nini nini-devel Size:2.26 MiB Package: smuxi-1.0.7-7.fc29 Summary: Powerful, flexible, user-friendly chat client RPMs:smuxi smuxi-devel smuxi-engine smuxi-frontend-gnome smuxi-frontend-stfl Size:9.55 MiB = UPGRADED PACKAGES = Package: accountsservice-0.6.50-1.fc29 Old package: accountsservice-0.6.49-2.fc29 Summary: D-Bus interfaces for querying and manipulating user account information RPMs: accountsservice accountsservice-devel accountsservice-libs Size: 1.19 MiB Size change: -53.23 KiB Changelog: * Mon Sep 24 2018 Adam Williamson - 0.6.50-1 - Update to 0.6.50, plus a couple of backported patches Resolves: #1576903 Package: argbash-2.7.1-1.fc29 Old package: argbash-2.7.0-1.fc29 Summary: Bash argument parsing code generator RPMs: argbash Size: 52.40 KiB Size change: 1.17 KiB Changelog: * Thu Sep 20 2018 Stephen Gallagher - 2.7.1-1 - Update to 2.7.1 - The bash completion now supports arguments of one-of-restricted values. - Tests pass when there is no dash shell installed. - The double-dash handling when -- is the last argument has been improved. - The generated bash completion is now complementing (i.e. not shadowing) the default bash completion. - Docopt fatal regression has been fixed. - Tests were added for docopt output. Package: bcm283x-firmware-20180921-1.404dfef.fc29 Old package: bcm283x-firmware-20180829-3.ec3f856.fc29 Summary: Broadcom bcm283x firmware for the Raspberry Pi RPMs: bcm283x-firmware Size: 11.34 MiB Size change: 1.92 KiB Changelog: * Sun Sep 23 2018 Peter Robinson 20180921-1.404dfef - Latest firmware update Package: bolt-0.5-1.fc29 Old package: bolt-0.4-2.fc29 Summary: Thunderbolt device manager RPMs: bolt Size: 724.28 KiB Size change: 105.00 KiB Changelog: * Fri Sep 21 2018 Christian Kellner - 0.5-1 - bolt 0.5 release - Remove forge macros again and use gitlab as authorative source - Testing depedencies are now only pulled in on Fedora Package: camorama-0.20.6-1.fc29 Old package: camorama-0.20.3-1.fc29 Summary: Gnome webcam viewer RPMs: camorama Size: 1.83 MiB Size change: 157.29 KiB Changelog: * Wed Sep 19 2018 Mauro Carvalho Chehab - 3.8.9-1 - Update to 3.8.9 release Package: cinnamon-control-center-3.8.2-1.fc29 Old package: cinnamon-control-center-3.8.1-1.fc29 Summary: Utilities to configure the Cinnamon desktop RPMs: cinnamon-control-center cinnamon-control-center-devel cinnamon-control-center-filesystem Size: 10.97 MiB Size change: 3.78 KiB Changelog: * Fri Sep 21 2018 Leigh Scott - 3.8.2-1 - Update to 3.8.2 release Package: cinnamon-settings-daemon-3.8.6-1.fc29 Old package: cinnamon-settings-daemon-3.8.4-1.fc29 Summary: The daemon sharing settings from CINNAMON to GTK+/KDE applications RPMs: cinnamon-settings-daemon cinnamon-settings-daemon-devel Size: 3.09 MiB Size change: 2.53 KiB Changelog: * Fri Sep 21 2018 Leigh Scott - 3.8.6-1 - Update to 3.8.6 release Package: clang-7.0.0-1.fc29 Old package: clang-7.0.0-0.14.rc3.fc29 Summary: A C language family front-end for LLVM RPMs: clang clang-analyzer clang-devel clang-libs clang-tools-extra git-clang-format llvm-test-suite python2-clang Size: 1.10 GiB Size change: 5.02 KiB Changelog: * Wed Sep 19
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
> "JF" == John Florian writes: JF> I would agree with that, but I read the announcement as if this JF> *was* finished. The announcement was unfortunately made before things were in what I would consider to be a "releasable" condition. Currently the Wiki pages continue to exist and have not diverged significantly as I have yet to write any new content into the new pages. As that happens, I will add notes to the corresponding wiki pages mentioning that they are outdated copies. Eventually we will replace them with redirects, though I see no reason to delete the original page histories and I imagine they will remain available as long as the wiki itself. Personally I would not have chosen to announce it until things were in better shape, but what's done is done and my effort will be devoted to moving forward. - J< ___ 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 Packaging Guidelines on docs.fedoraproject.org
> "NG" == Neal Gompa writes: NG> I'm wondering if it was a good idea to use asciidoc in the first NG> place. Unlike reStructuredText, asciidoc implementations seem to be NG> in very poor shape. It's what the documentation team has chosen. I don't think the packaging committee would want to do its own thing here; staying with the wiki would have been a better option than that. - J< ___ 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 Packaging Guidelines on docs.fedoraproject.org
On Mon, Oct 1, 2018 at 5:03 PM Björn Persson wrote: > > Jason L Tibbitts III wrote: > > Indeed, asciidoctor works a bit better than asciidoc does but still > > converts quickly. It's actually in the "rubygem-asciidoctor" package. > > Maybe I'll try that next time I have some free time. This is giving me > a "best viewed with Netscape Navigator" feeling though. Not only are > there several different badly designed document authoring languages, > but they're apparently even splitting into tool-specific dialects. > I'm wondering if it was a good idea to use asciidoc in the first place. Unlike reStructuredText, asciidoc implementations seem to be in very poor shape. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Packaging Guidelines on docs.fedoraproject.org
On Mon, Oct 01, 2018 at 11:02:13PM +0200, Björn Persson wrote: > > Indeed, asciidoctor works a bit better than asciidoc does but still > > converts quickly. It's actually in the "rubygem-asciidoctor" package. > Maybe I'll try that next time I have some free time. This is giving me > a "best viewed with Netscape Navigator" feeling though. Not only are > there several different badly designed document authoring languages, > but they're apparently even splitting into tool-specific dialects. That's not really the case here. See https://github.com/asciidoc/asciidoc; asciidoctor is officially the blessed successor to asciidoc. -- Matthew Miller Fedora Project Leader ___ 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 Packaging Guidelines on docs.fedoraproject.org
On 2018-10-01 17:04, Björn Persson wrote: John Florian wrote: And conversely, shouldn't https://fedoraproject.org/wiki/Packaging:Guidelines be telling viewers they now need to go to docs.fp.o? Not until the conversion is finished, in my opinion. I would agree with that, but I read the announcement as if this *was* finished. It said "moved" so that was my impression, but I see with the discussion here that maybe this is really more like an RC? ___ 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 Infrastructure Planned Outage 2018-10-03
l;dr: All Fedora Infrastructure systems will be updated and rebooted over this week. Systems that can be done outside of the planned outage. 2018-10-01 21:00 UTC Staging and downloads 2018-10-02 throughout the 'day' single proxies will be updated/rebooted. 2018-10-03 production systems including all build servers will be rebooted. === Planned Outage - Build/Production - 2018-10-03 21:00 UTC There will be an outage starting at 2018-10-03 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2018-10-03 21:00UTC' Reason for outage: Various kernel, library, and general security updates need to be applied to all servers. Due to the kernel, glibc, and other updates.. all systems will be rebooted afterwords Affected Services: All build, production and related services will be affected. Ticket Link: https://pagure.io/fedora-infrastructure/issue/7272 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Packaging Guidelines on docs.fedoraproject.org
John Florian wrote: > And conversely, shouldn't > https://fedoraproject.org/wiki/Packaging:Guidelines be telling viewers > they now need to go to docs.fp.o? Not until the conversion is finished, in my opinion. Björn Persson pgpChXjsJJFLd.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Packaging Guidelines on docs.fedoraproject.org
On Mon, Oct 1, 2018 at 8:22 PM Jason L Tibbitts III wrote: > > Indeed, asciidoctor works a bit better than asciidoc does but still > converts quickly. It's actually in the "rubygem-asciidoctor" package. FWIW, We *could* use the asciidoctor / asciidoc plugin for jekyll. Both asciidoctor and jekyll are packaged for fedora. The only thing that's missing to support that with official fedora packages right now is a package for rubygem(jekyll-asciidoc). (Check @package-review, guess which package is waiting there for a review ;)) Fabio > - J< > ___ > 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: Fedora Packaging Guidelines on docs.fedoraproject.org
Jason L Tibbitts III wrote: > Indeed, asciidoctor works a bit better than asciidoc does but still > converts quickly. It's actually in the "rubygem-asciidoctor" package. Maybe I'll try that next time I have some free time. This is giving me a "best viewed with Netscape Navigator" feeling though. Not only are there several different badly designed document authoring languages, but they're apparently even splitting into tool-specific dialects. Björn Persson pgpdwRaF_UeOq.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Non-responsive package maintainer - Ray Strode (halfline), Plymouth package
Hi, On Mon, Oct 1, 2018 at 4:29 PM Stephen wrote: > The maintainer for Plymouth, Ray Strode (halfline), is not addressing > its bugs on RHBZ (one response all year on a single bug, accepting a > patch), including showstopper bugs that are preventing boot entirely in > some instances. I'm around, but I work on a lot of stuff. plymouth doesn't get a lot of attention, since it basically works. It doesn't see as much development as some components because other parts of the stack have been prioritized. Having said that, Hans de Goede has taken up the mantle of improving the boot experience recently, including some changes to plymouth. So you should see some changes soon. plymouth does get fixes for blocker issues when necessary, and i still give it some attention upstream. It is receiving the amount resources we considered appropriate at the moment. --Ray ___ 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 Packaging Guidelines on docs.fedoraproject.org
On Mon, Oct 01, 2018 at 03:59:21PM -0400, John Florian wrote:
> On 2018-10-01 10:51, Zbigniew Jędrzejewski-Szmek wrote:
> >I think we instead should make sure that all docs under docs.fp.o
> And conversely, shouldn't
> https://fedoraproject.org/wiki/Packaging:Guidelines be telling
> viewers they now need to go to docs.fp.o?
There's a wiki plugin which can be used:
{{#fedoradocs: https://docs.fedoraproject.org/en-US/packaging-guidelines/}}
will cause a redirect.
--
Matthew Miller
Fedora Project Leader
___
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
Non-responsive package maintainer - Ray Strode (halfline), Plymouth package
The maintainer for Plymouth, Ray Strode (halfline), is not addressing its bugs on RHBZ (one response all year on a single bug, accepting a patch), including showstopper bugs that are preventing boot entirely in some instances. Per https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ , I have attempted to contact Ray via https://bugzilla.redhat.com/show_bug.cgi?id=1629393 twice without success. Does anyone know how to contact Ray? In reference to the above policy, I'm not seeking to take over maintainership of this package, but given that when enabled Plymouth effectively becomes a boot-critical component, it either needs to be adequately maintained or removed from Fedora IMO. ___ 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 Packaging Guidelines on docs.fedoraproject.org
On Fri, 28 Sep 2018 at 16:27, Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > Hello everyone, > > We have moved packaging guidelines onto docs.fedoraproject.org[0]. > If you find any error or would like to change something, don't hesitate to > open ticket or submit pull request for packaging committee repo[1]. > This is great, welcome to the Docs! I can see a lot of feedback in this thread. I might not be the fastest, but I'll definitely catch up with it all and see what I can do. Thanks all! > > Thanks for attention! > > > [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/ > [1] https://pagure.io/packaging-committee > -- > > -Igor Gnatenko > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > -- Adam Šamalík --- Software Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Packaging Guidelines on docs.fedoraproject.org
On 2018-10-01 10:51, Zbigniew Jędrzejewski-Szmek wrote: I think we instead should make sure that all docs under docs.fp.o contain good links to those pages on the wiki. And conversely, shouldn't https://fedoraproject.org/wiki/Packaging:Guidelines be telling viewers they now need to go to docs.fp.o? ___ 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 Packaging Guidelines on docs.fedoraproject.org
Indeed, asciidoctor works a bit better than asciidoc does but still converts quickly. It's actually in the "rubygem-asciidoctor" package. - J< ___ 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 Packaging Guidelines on docs.fedoraproject.org
On 1.10.2018 20:00, Jason L Tibbitts III wrote: "BP" == Björn Persson writes: BP> This was on Fedora 27. So one needs Fedora 28 to help fixing the BP> formatting of the guidelines then? (Once that other breakage is BP> fixed I suppose?) I believe one could build the antora stack from scratch instead of using a container. I would hope it wouldn't require F28 to do so, but it's still way too high of a barrier. BP> Yeah, no I don't think I'm going to run any document conversion BP> programs as root. You certainly shouldn't have to. The problem is making it look like it looks on the web site, since I guess the markup itself is dependent on stylesheets and extra information which isn't actually included in the documents. For a single page, though, it seems that you can get a reasonable interpretation merely by installing asciidoc and running "asciidoc foo.adoc". That will spit out foo.html which you can open in a local browser. That's what I've been doing, but unfortunately it doesn't give me the same results. For example, it doesn't appear to handle the `+whatever+` syntax properly and inserts the literal plusses in the output while the antora-generated version doesn't. I do not know why. BP> I'm getting the impression that you're shooting mosquitoes with a BP> cannon. Plain asciidoc is the lightest weight solution I've found so far. Maybe someone knows some magic that could be passed to asciidoc or another converter which is actually part of the distribution which could be used for at least a more consistent previous. For what's it work, I had a good experience with asciidoctor, although I haven't tried to use it on our guidelines yet. $ sudo dnf install asciidoctor -- 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
Fedora Infrastructure Planned Outage 2018-10-03
tl;dr: All Fedora Infrastructure systems will be updated and rebooted over this week. Systems that can be done outside of the planned outage. 2018-10-01 21:00 UTC Staging and downloads 2018-10-02 throughout the 'day' single proxies will be updated/rebooted. 2018-10-03 production systems including all build servers will be rebooted. === Planned Outage - Build/Production - 2018-10-03 21:00 UTC There will be an outage starting at 2018-10-03 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2018-10-03 21:00UTC' Reason for outage: Various kernel, library, and general security updates need to be applied to all servers. Due to the kernel, glibc, and other updates.. all systems will be rebooted afterwords Affected Services: All build, production and related services will be affected. Ticket Link: https://pagure.io/fedora-infrastructure/issue/7272 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. Reply -- 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
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
> "BP" == Björn Persson writes: BP> This was on Fedora 27. So one needs Fedora 28 to help fixing the BP> formatting of the guidelines then? (Once that other breakage is BP> fixed I suppose?) I believe one could build the antora stack from scratch instead of using a container. I would hope it wouldn't require F28 to do so, but it's still way too high of a barrier. BP> Yeah, no I don't think I'm going to run any document conversion BP> programs as root. You certainly shouldn't have to. The problem is making it look like it looks on the web site, since I guess the markup itself is dependent on stylesheets and extra information which isn't actually included in the documents. For a single page, though, it seems that you can get a reasonable interpretation merely by installing asciidoc and running "asciidoc foo.adoc". That will spit out foo.html which you can open in a local browser. That's what I've been doing, but unfortunately it doesn't give me the same results. For example, it doesn't appear to handle the `+whatever+` syntax properly and inserts the literal plusses in the output while the antora-generated version doesn't. I do not know why. BP> I'm getting the impression that you're shooting mosquitoes with a BP> cannon. Plain asciidoc is the lightest weight solution I've found so far. Maybe someone knows some magic that could be passed to asciidoc or another converter which is actually part of the distribution which could be used for at least a more consistent previous. I'm extremely dissatisfied at the way this has been handled and wish I'd had sufficient free time to find some of these issues before this was implemented, but at the time I didn't and now it seems that the only way out is forward. - J< ___ 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: Could not execute new_sources: Fail to upload files. Server returns status 403
On 09/30/2018 07:25 AM, Miro Hrončok wrote: > On 30.9.2018 14:23, Miro Hrončok wrote: >> Got this when I run `fedpkg new-sources`. >> >> $ fedpkg --release master new-sources wheel-0.32.0.tar.gz >> Could not execute new_sources: Fail to upload files. Server returns >> status 403 >> >> What do i need to do? >> >> I've rekinited, I've rerun `fedora-packager-setup`, `fedora-cert` >> tells me it's not needed any more. >> >> Is there something more I should do? > > It works now. In case anyone is curious... this issue happened because: Our ansible playbooks for that host for some reason have 'state=latest' for the 'dist-git' package that provides the upload.cgi. I was running all our playbooks to ensure everything was in sync and it upgraded that and broke it. We have determined what in the upgrade broke things and submitted a PR to fix it for the next release, and I have changed our playbook to only require the package be 'present'. Sorry for the hassles. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Packaging Guidelines on docs.fedoraproject.org
Igor Gnatenko wrote: > Seems that podman is broken (it is also broken for tibbs in some other > way), this is really sad. Just wondering which version of fedora you are > running and is there really no package called "slirp4netns" (I can see it > in F28/F29/F30). This was on Fedora 27. So one needs Fedora 28 to help fixing the formatting of the guidelines then? (Once that other breakage is fixed I suppose?) > I'm sorry to hear this, try using `sudo docker` in Make file instead of > `podman`. Reason I choose to use podman is that you don't have to be root > in order to run it. Yeah, no I don't think I'm going to run any document conversion programs as root. I'm getting the impression that you're shooting mosquitoes with a cannon. I wasn't trying to set up a mirror of the website or anything. I just wanted to preview the result of my edits. "If I change the .adoc file like this, does it cause the desired change to the HTML code?" That was all I needed to know. It can hardly be necessary to mess with containers just to convert a document from one markup language to another. Björn Persson pgptwrR_8avRm.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 python2-matplotlib
On 1.10.2018 18:29, Miro Hrončok wrote:
On 1.10.2018 17:55, Jason L Tibbitts III wrote:
"SJS" == Stephen John Smoogen writes:
SJS> What packages? And where are they depending on it?
I believe the underlying issue is that previously the Fedora
python-matplotib package produced both python2 and python3 subpackages.
But recently it dropped support for python2.
Yes.
What I don't understand is:
1) Why my access was removed from the package and set to 'orphan'.
There is no separate set of permissions for EPEL branches but I'd think
that the new Fedora maintainer would have been simply added to the list
of admins.
I haven't in any way removed you form the package. I simply followed
this procedure:
1. package review: https://bugzilla.redhat.com/show_bug.cgi?id=1630799
2. requesting a dist-git repo:
https://pagure.io/releng/fedora-scm-requests/issue/8211
3. the repo exists, unretire on Fedora: https://pagure.io/releng/issue/7826
("It doesn't really exist in EPEL; the current EPEL package is just a
stub that depends on python-matplotlib. The Fedora package will be a
completely different thing. There shouldn't be any conflict between them.")
So apparently, this is where you were removed, because I wrote:
> FAS username of the new maintainer? churchyard
And that simply meant "replace current main admin with me".
This was certainly not intended. I've also cced you in the request so
you are aware of the unretirement. Neither of us noticed the consequence.
4. imported with history
https://src.fedoraproject.org/rpms/python2-matplotlib/pull-request/1
5. built
6. announced
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PWZLITS74FYXASZGDF4W7G7LNJNYY4H5/
7. orphaned when I no longer wanted to maintain it. no other maintainers
were present at this point.
Note that at the point, I haven't noticed that this is weird. I should
have. I've only seen it as an action that removes me.
If at any point of the process you got kicked out of the package, this
was certainly not my intent.
2) Why a package was added and then immediately orphaned. In an attempt
to clean up the mess I'm told that there's now a six week period of time
during which the package has to stay live. So this package was imported
with no expectation that it would be maintained only to start some
running clock. And for the duration of that clock, I get to keep the
mess by default?
The package was added because it was needed. It was orphaned because I
don't want to maintain it. Or do I have to maintain the package for ever
juts because I've put it in there? What's the difference between
orphaning it 1 week after introducing it, 1 year or a decade?
My idea and motivation here was that somebody who needs it will take it.
I've tried. Nobody wanted it. I've orphaned it, hoping that once it
appears in the "orphaned packages in need for maintainers" announcement,
somebody will take it.
The "mess" was not "yours" to keep. There was never any mess in the EPEL
branch(es). The only mess that exists now is that the package was
retired and things will start FTBFS and have broken deps (on Fedora),
how can we sort this mess out, I have no idea. Certainly we can unretire
it, but I won't do it just to have it retired again as a mess that needs
to get out.
I'm rather unhappy about this. I had previously raised my objection to
this and requested coordination in this FESCo comment:
https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
happened anyway.
I haven't read that as objection. I've understand it as confusion.
You've asked to tell you if there is somebody to give this package to.
There is nobody. Nobody wants it.
Also, in the releng ticket you've pointed out that this will in no way
clash with the EPEL package. Yet now it seems you retired the package
only because you are the maintainer of the EPEL package (or at least you
should have remained the maintainer).
I don't understand what I've done wrong. I think that every maintainer
has a right to orphan a package at any time.
On the other hand, just retiring a package that other packages depend on
seems like a weird way of dealing with a problem.
I'm sorry that you were removed form the package. It was not by my
action. It might have been a side effect of the unretirement (I haven't
anticipated that side effect).
I'm very sorry that you feel like I went behind your back and like I did
a wrong thing here. This was no trick, this was no calculated move to
strip the package from you or to create a pressure on some other
packagers. This was a simple scenario:
* split a package into two halves
* orphan one of the halves that I don't want to maintain
In fact, I was planning to this for python-SecretStorage as well. Should
I rather not? What should be the correct way of doing this?
And what shall happen with python2-matplotlib in Fedora?
Proposal:
We revert the "Undo the mess that
Taskotron and test dependencies
Hi, naive noob question: Is it possible to execute scripts with taskotron to download 3rd-party dependencies e.g. with pip from PyPi? I tend to say that it's not worth to package simple test libraries with all the dependency hell behind. Those dependencies are not required for normal runtime functionality. Regards, Raphael ___ 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: Resurrection of the NeuroFedora SIG
On Mon, Oct 01, 2018 18:04:56 +0300, Cătălin George Feștilă wrote: > Good to know. > A good article post at Fedora Magazin will be more useful. Thanks! I intend to write a post on the community blog but I'm not sure if NeuroFedora is mature enough to advertise to users on the magazine just yet. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 python2-matplotlib
On 1.10.2018 17:55, Jason L Tibbitts III wrote:
"SJS" == Stephen John Smoogen writes:
SJS> What packages? And where are they depending on it?
I believe the underlying issue is that previously the Fedora
python-matplotib package produced both python2 and python3 subpackages.
But recently it dropped support for python2.
Yes.
What I don't understand is:
1) Why my access was removed from the package and set to 'orphan'.
There is no separate set of permissions for EPEL branches but I'd think
that the new Fedora maintainer would have been simply added to the list
of admins.
I haven't in any way removed you form the package. I simply followed
this procedure:
1. package review: https://bugzilla.redhat.com/show_bug.cgi?id=1630799
2. requesting a dist-git repo:
https://pagure.io/releng/fedora-scm-requests/issue/8211
3. the repo exists, unretire on Fedora: https://pagure.io/releng/issue/7826
("It doesn't really exist in EPEL; the current EPEL package is just a
stub that depends on python-matplotlib. The Fedora package will be a
completely different thing. There shouldn't be any conflict between them.")
4. imported with history
https://src.fedoraproject.org/rpms/python2-matplotlib/pull-request/1
5. built
6. announced
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PWZLITS74FYXASZGDF4W7G7LNJNYY4H5/
7. orphaned when I no longer wanted to maintain it. no other maintainers
were present at this point.
If at any point of the process you got kicked out of the package, this
was certainly not my intent.
2) Why a package was added and then immediately orphaned. In an attempt
to clean up the mess I'm told that there's now a six week period of time
during which the package has to stay live. So this package was imported
with no expectation that it would be maintained only to start some
running clock. And for the duration of that clock, I get to keep the
mess by default?
The package was added because it was needed. It was orphaned because I
don't want to maintain it. Or do I have to maintain the package for ever
juts because I've put it in there? What's the difference between
orphaning it 1 week after introducing it, 1 year or a decade?
My idea and motivation here was that somebody who needs it will take it.
I've tried. Nobody wanted it. I've orphaned it, hoping that once it
appears in the "orphaned packages in need for maintainers" announcement,
somebody will take it.
The "mess" was not "yours" to keep. There was never any mess in the EPEL
branch(es). The only mess that exists now is that the package was
retired and things will start FTBFS and have broken deps (on Fedora),
how can we sort this mess out, I have no idea. Certainly we can unretire
it, but I won't do it just to have it retired again as a mess that needs
to get out.
I'm rather unhappy about this. I had previously raised my objection to
this and requested coordination in this FESCo comment:
https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
happened anyway.
I haven't read that as objection. I've understand it as confusion.
You've asked to tell you if there is somebody to give this package to.
There is nobody. Nobody wants it.
Also, in the releng ticket you've pointed out that this will in no way
clash with the EPEL package. Yet now it seems you retired the package
only because you are the maintainer of the EPEL package (or at least you
should have remained the maintainer).
I don't understand what I've done wrong. I think that every maintainer
has a right to orphan a package at any time.
On the other hand, just retiring a package that other packages depend on
seems like a weird way of dealing with a problem.
I'm sorry that you were removed form the package. It was not by my
action. It might have been a side effect of the unretirement (I haven't
anticipated that side effect).
I'm very sorry that you feel like I went behind your back and like I did
a wrong thing here. This was no trick, this was no calculated move to
strip the package from you or to create a pressure on some other
packagers. This was a simple scenario:
* split a package into two halves
* orphan one of the halves that I don't want to maintain
In fact, I was planning to this for python-SecretStorage as well. Should
I rather not? What should be the correct way of doing this?
And what shall happen with python2-matplotlib in Fedora?
--
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
Summary and minutes for Monday's FESCo Meeting (2018-10-01)
Meeting started by zbyszek at 15:00:17 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-01/fesco.2018-10-01-15.00.log.html . Meeting summary --- * init process (zbyszek, 15:00:20) * #1974 Problematic blocker for F29: dnf 'offline' module tracking (zbyszek, 15:02:07) * LINK: https://pagure.io/fesco/issue/1974 (zbyszek, 15:02:13) * LINK: https://pagure.io/fesco/issue/1974#comment-534269 for any looking for the link (nirik, 15:43:06) * AGREED: We table this for a week to give modularity+dnf folks time to discuss and respond to the proposed requirement. We will revisit next meeting. (+6, 0, 0) (zbyszek, 15:54:31) * proposal for requirements for DNF behaviour at GA: https://pagure.io/fesco/issue/1974#comment-534269 (zbyszek, 15:54:34) * given time constraints, we ask for the discussion to start now (zbyszek, 15:54:37) * #1927 F29 Self Contained Change: Origin 3.10 (zbyszek, 15:54:58) * LINK: https://pagure.io/fesco/issue/1927 (zbyszek, 15:54:58) * AGREED: The update of the Change from 3.10 to 3.11 is approved (+7, 0, 0) (zbyszek, 15:56:57) * Next week's chair (zbyszek, 15:57:21) * ACTION: jforbes will chair next meeting (zbyszek, 15:57:58) * Open Floor (zbyszek, 15:58:03) * LINK: https://pagure.io/fesco/issue/1970 (smooge, 15:58:33) * LINK: https://pagure.io/fesco/issue/1970#comment-532232 (tibbs, 16:02:53) Meeting ended at 16:18:08 UTC. Action Items * jforbes will chair next meeting People Present (lines said) --- * sgallagh (85) * zbyszek (64) * bowlofeggs (55) * contyk (44) * nirik (26) * zodbot (15) * smooge (14) * jforbes (10) * tibbs (8) * adamw (3) * maxamillion (3) * jcajka (1) * tyll (0) * jsmith (0) 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: Orphaned python2-matplotlib
> "SJS" == Stephen John Smoogen writes: SJS> What packages? And where are they depending on it? I believe the underlying issue is that previously the Fedora python-matplotib package produced both python2 and python3 subpackages. But recently it dropped support for python2. What I don't understand is: 1) Why my access was removed from the package and set to 'orphan'. There is no separate set of permissions for EPEL branches but I'd think that the new Fedora maintainer would have been simply added to the list of admins. 2) Why a package was added and then immediately orphaned. In an attempt to clean up the mess I'm told that there's now a six week period of time during which the package has to stay live. So this package was imported with no expectation that it would be maintained only to start some running clock. And for the duration of that clock, I get to keep the mess by default? I'm rather unhappy about this. I had previously raised my objection to this and requested coordination in this FESCo comment: https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have happened anyway. - J< ___ 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 python2-matplotlib
On Mon, 1 Oct 2018 at 11:36, Miro Hrončok wrote: > > On 1.10.2018 17:32, Jason L Tibbitts III wrote: > >> "MH" == Miro Hrončok writes: > > > > MH> I've orphaned python2-matplotlib. Nobody replied to my previous > > MH> heads up e-mails. > > > > So that nobody is confused by this, the python2-matplotlib package was > > previously an EPEL-only stub package maintained by me that existed so > > packagers could simply depend on python2-matplotlib in both Fedora and > > EPEL. (See > > https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages.) The > > orphaning of this package had the result of removing my access from the > > package entirely, on all branches. > > > > Fortunately I have sufficient privileges so I gave access back to > > myself, and then removed everything which was checked into HEAD and went > > back to the original dead.package file with "This is an EPEL-only > > package." > > Could you please explain why did you do that? > > I've orphaned that package (as I don't have desire to take care of it), Why was it your package? It was originally tibbs. > but it certainly does not deserve retirement (aka somebody should > hopefully take it). > > There are packages depending on it. What packages? And where are they depending on it? This was supposed to be an EPEL only package so they should only be EPEL packages which depend on it. If there are packages in other trees depending on it, then how because it should not have been built for it. -- 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
Re: Orphaned python2-matplotlib
On 1.10.2018 17:32, Jason L Tibbitts III wrote: "MH" == Miro Hrončok writes: MH> I've orphaned python2-matplotlib. Nobody replied to my previous MH> heads up e-mails. So that nobody is confused by this, the python2-matplotlib package was previously an EPEL-only stub package maintained by me that existed so packagers could simply depend on python2-matplotlib in both Fedora and EPEL. (See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages.) The orphaning of this package had the result of removing my access from the package entirely, on all branches. Fortunately I have sufficient privileges so I gave access back to myself, and then removed everything which was checked into HEAD and went back to the original dead.package file with "This is an EPEL-only package." Could you please explain why did you do that? I've orphaned that package (as I don't have desire to take care of it), but it certainly does not deserve retirement (aka somebody should hopefully take it). There are packages depending on it. -- 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: Orphaned python2-matplotlib
> "MH" == Miro Hrončok writes: MH> I've orphaned python2-matplotlib. Nobody replied to my previous MH> heads up e-mails. So that nobody is confused by this, the python2-matplotlib package was previously an EPEL-only stub package maintained by me that existed so packagers could simply depend on python2-matplotlib in both Fedora and EPEL. (See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages.) The orphaning of this package had the result of removing my access from the package entirely, on all branches. Fortunately I have sufficient privileges so I gave access back to myself, and then removed everything which was checked into HEAD and went back to the original dead.package file with "This is an EPEL-only package." I cannot remove the errant F29 branch which was created but I will try to get it all blocked the way it was previously. - J< ___ 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: Resurrection of the NeuroFedora SIG
Good to know. A good article post at Fedora Magazin will be more useful. On Sun, Sep 30, 2018 at 4:24 PM Ankur Sinha wrote: > Hello, > > https://fedoraproject.org/wiki/SIGs/NeuroFedora > > I've recently resurrected the NeuroFedora SIG. Many thanks to Igor and > the others who'd worked on it in the past and have given us a firm base > to build on. > > The goal > - > > The (current) goal of the NeuroFedora SIG is to make Fedora an easy to > use platform for neuroscientists. > > Neuroscience is an extremely multidisciplinary field. It brings together > mathematicians, chemists, biologists, physicists, psychologists, > engineers (electrical and others) computer scientists and more. A > lot of software is used nowadays in Neuroscience: > > - data collection, analysis, and sharing > - lots of image processing (a lot of ML is used here, think Data Science) > - simulation of brain networks (https://neuron.yale.edu/neuron/, > http://nest-simulator.org/) > - dissemination of scientific results (peer reviewed and otherwise, > think LaTeX) > > https://github.com/asoplata/open-computational-neuroscience-resources/ > provides a great overview of the computational side of neuroscience. It > isn't just about understanding how the brain functions, we also want to > understand how it processes information---how it "computes". > > (Some of you will already be aware of the Human Brain Project, a > flagship EU project: https://www.humanbrainproject.eu/en/) > > Now, given that a large proportion of neuroscientists are not trained > in computer science, a lot of time and effort is spent setting up > systems, installing software (often from source). This can be hard for > people not well-versed in build systems and so on. > > So, at NeuroFedora, we will try provide a ready to use Fedora based > system for neuroscientists to work with, so they can quickly get their > environment set up and work on the science. > > > Please join us! > --- > > If you are interested in neuroscience, please consider joining the SIG. > Packaging software is only *one* way in which one can contribute. > Writing docs and answering questions about the software in NeuroFedora > are other ways too, for example. > > You can get in touch with us here: > > https://fedoraproject.org/wiki/SIGs/NeuroFedora#Communication_and_getting_help > > What's in it for you? > - > > In general, it will increase your awareness of neuroscience (which is a > fascinating field---but of course, I am biased). We also hope to use the > Fedora classroom sessions to host beginner level classes on using the > software we package. If you'd like to get into neuroscience research > work, it's an excellent opportunity to learn. > > Fedora and Science > --- > > In general, furthering Open Science is quite in line with our goals of > further FOSS---Open science shares the philosophy of FOSS. The data, the > tools, the results, should be accessible to all to understand, use, > learn from, and develop. > > I've just written to the Mindshare team asking if we can get the various > Science related SIGs together and do more. You can find my e-mail here: > > https://lists.fedoraproject.org/archives/list/mindsh...@lists.fedoraproject.org/thread/7UYIFRQGZI5O4KNTVOGSG7Y4MYJKI57O/ > > Please feel free to join the discussion. > > -- > Thanks, > Regards, > > Ankur Sinha "FranciscoD" > > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > 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: Fedora Packaging Guidelines on docs.fedoraproject.org
On Mon, Oct 01, 2018 at 09:47:37AM -0500, Jason L Tibbitts III wrote: > > "AS" == Ankur Sinha writes: > > AS> Thank you---that's really neat! Would other relatively static pages > AS> such as these also be migrated? > > Those are outside the scope of the packaging committee. They could > certainly be migrated in a similar fashion, but they wouldn't live in > the packaging committee's repository and I don't think the packaging > committee would be the entity that would initiate such a move. > > Personally I believe that the pages you mention are not static at all > and are better located where they can be edited by the community, and > that's exactly what the wiki is for. The new format far better fits the > packaging guidelines where edits were restricted. +1 I think we instead should make sure that all docs under docs.fp.o contain good links to those pages on the wiki. 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: Fedora Packaging Guidelines on docs.fedoraproject.org
> "AS" == Ankur Sinha writes: AS> Thank you---that's really neat! Would other relatively static pages AS> such as these also be migrated? Those are outside the scope of the packaging committee. They could certainly be migrated in a similar fashion, but they wouldn't live in the packaging committee's repository and I don't think the packaging committee would be the entity that would initiate such a move. Personally I believe that the pages you mention are not static at all and are better located where they can be edited by the community, and that's exactly what the wiki is for. The new format far better fits the packaging guidelines where edits were restricted. - J< ___ 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: fedpkg clone doesn*t work
problem solved for my by adding the rsa key in paguera, now i have access in fedorapeople also. https://docs.pagure.org/pagure/usage/first_steps.html ___ 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 Monday's FESCo Meeting (2018-10-01)
I'm in meetings all day today and will be unable to attend the FESCo meeting. I'll attempt to vote in all the tickets in today's agenda. -- Jared Smith On Mon, Oct 1, 2018 at 10:09 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on > irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2018-10-01 15:00 UTC' > > > Links to all issues to be discussed can be found at: > https://pagure.io/fesco/report/meeting_agenda > > = Followups = > > #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking > .fesco 1974 > https://pagure.io/fesco/issue/1974 > > #topic #1927 F29 Self Contained Change: Origin 3.10 > .fesco 1927 > https://pagure.io/fesco/issue/1927 > > = Open Floor = > > For more complete details, please visit each individual issue. The > report of the agenda items can be found at > https://pagure.io/fesco/report/meeting_agenda > > If you would like to add something to this agenda, you can reply to > this e-mail, file a new issue at https://pagure.io/fesco, e-mail me > directly, or bring it up at the end of the meeting, during the open > floor topic. Note that added topics may be deferred until the > following meeting. > > 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 > ___ 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
Schedule for Monday's FESCo Meeting (2018-10-01)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-10-01 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking .fesco 1974 https://pagure.io/fesco/issue/1974 #topic #1927 F29 Self Contained Change: Origin 3.10 .fesco 1927 https://pagure.io/fesco/issue/1927 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. 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: Non-responsive maintainer for python-dateutil
> On 1. Oct 2018, at 12:00, Emmanuel Seyman wrote: > > * Joseph D. Wagner [01/10/2018 02:47] : >> >> Per policy for non-responsive maintainers >> (https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers) > > Folks, when you're asking us if anyone knows how to contact the maintainer, > you might want to consider actually giving us his name (both real and FAS). > >> There has been an outstanding update request since March 24, 2018. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1560212 > > As noted two weeks ago, Haïkel is highly availible by private email and IRC > and is very supportive of anyone wanting to co-maintain packages with him. > > Emmanuel If a co-maintainer is desperately needed here, I can step in. I have same dependencies of my own that need python-dateutil. Feel free to contact me, FAS account is bkircher. BK ___ 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: Non-responsive maintainer for python-dateutil
* Joseph D. Wagner [01/10/2018 02:47] : > > Per policy for non-responsive maintainers > (https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers) Folks, when you're asking us if anyone knows how to contact the maintainer, you might want to consider actually giving us his name (both real and FAS). > There has been an outstanding update request since March 24, 2018. > > https://bugzilla.redhat.com/show_bug.cgi?id=1560212 As noted two weeks ago, Haïkel is highly availible by private email and IRC and is very supportive of anyone wanting to co-maintain packages with him. Emmanuel ___ 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
Non-responsive maintainer for python-dateutil
Per policy for non-responsive maintainers (https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers) There has been an outstanding update request since March 24, 2018. https://bugzilla.redhat.com/show_bug.cgi?id=1560212 Joseph D. Wagner ___ 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: Running a test from dist-git
Hi, On Thu, Sep 27, 2018 at 11:32 PM Richard W.M. Jones wrote: > As directed by: > > https://fedoraproject.org/wiki/CI/Tests > > I tried to add a test to libguestfs dist-git: > > > https://src.fedoraproject.org/rpms/libguestfs/blob/master/f/tests/tests.yml > > It's very simple initially. It just needs to run > ‘libguestfs-test-tool’ (a program installed by the libguestfs package > which does some self-tests). Ideally as non-root, but I think I've > set it up to run as root to start with. > Cool :) > > I did a scratch build initially, but it seems like the tests only run > from what's been pushed to dist-git. That is correct. Tests are not bundled into the src.rpm. > In any case the test didn't look > as if it had run. So I pushed the test to dist-git -- see above -- > and did another scratch build. However I've still no real idea if the > test really ran. > > I got an email containing this link: > > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/846/pipeline/ Nice, seems fedora notifications works again :) > > > which looks like there are lots of failures, but it's also not clear > if the test ran / tried to run / didn't run / if this link has nothing > to do tests. > Yeah, sorry for that, must have been som outage. I agree seeing that is not very helpful, to somebody not experienced in the CI pipeline. Also rescheduling anything else as a pull-request testing is not easily possible currently :( In the future this should be possible via fedpkg. > > So, that was the end of my experiment. Not a very good result :-( > For this time I rescheduled the run: https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/850/pipeline Seems it will end up with something more meaningful this time ... HTH, /M > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.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 > -- Miroslav Vadkerti :: Principal QE :: BaseOS QE Security IRC mvadkert #osci #baseosci #qe :: GPG 0x7B5B2E95 Desk Phone +420 532 294 129 :: Mobile +420 773 944 252 Red Hat Czech s.r.o, Purkyňova 99/71, 612 00, Brno, CR ___ 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-20180930.n.0 compose check report
No missing expected images. Failed openQA tests: 32/133 (x86_64), 2/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180924.n.2): ID: 287032 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287032 ID: 287035 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287035 ID: 287053 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/287053 ID: 287060 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287060 ID: 287063 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/287063 ID: 287064 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/287064 ID: 287065 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287065 ID: 287077 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/287077 ID: 287078 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287078 ID: 287079 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/287079 ID: 287082 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/287082 ID: 287085 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287085 ID: 287095 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/287095 ID: 287099 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/287099 ID: 287100 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/287100 ID: 287102 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/287102 ID: 287103 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/287103 ID: 287104 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/287104 ID: 287105 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/287105 ID: 287106 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/287106 ID: 287121 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/287121 ID: 287122 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/287122 ID: 287123 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/287123 ID: 287124 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/287124 ID: 287125 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/287125 ID: 287131 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/287131 ID: 287135 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/287135 ID: 287155 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/287155 ID: 287160 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/287160 ID: 287161 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/287161 ID: 287162 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/287162 ID: 287168 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/287168 ID: 287169 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/287169 Old failures (same test failed in Rawhide-20180924.n.2): ID: 287096 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/287096 ID: 287148 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/287148 Soft failed openQA tests: 1/133 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Rawhide-20180924.n.2): ID: 287058 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/287058 ID: 287059 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/287059 ID: 287109 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/287109 Passed openQA tests: 81/133 (x86_64), 20/24 (i386) New passes (same test did not pass in Rawhide-20180924.n.2): ID: 287031 Test: x86_64 Server-boot-iso install
