[Bug 1723904] perl-FFI-CheckLib-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1723904 --- Comment #3 from Fedora Update System --- FEDORA-2019-441dc1a4d8 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-441dc1a4d8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1723904] perl-FFI-CheckLib-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1723904 --- Comment #2 from Fedora Update System --- FEDORA-2019-622d40ab09 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-622d40ab09 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
On Wed, Jun 26, 2019 at 12:17 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote: > > On Mon, Jun 24, 2019 at 23:17:30 -0500, > > Justin Forbes wrote: > > > > > > It is not a violent cheat. It was proposed this way 2 years ago. At > > > the time a SIG was created to maintain i686 so that it could continue > > > as a secondary arch. They are inactive. See the post in the SIG there. > > > When a call for a status was made (as the only traffic on their list > > > so far this year), it got a single reply from someone saying that they > > > would no longer have 32bit hardware as of August. > > > > I'm the one who responded. > > FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. > They're Atom N270 based, so 32-bit only. I'd like to run the most recent > Fedora on them, but I don't have much time to devote to debugging > i686-specific issues. If the proposal remains to be only about dropping i686 kernel (and image) builds, you should be able to get latest Fedora (userspace without latest kernel) by installing Fedora 30 and upgrading to whatever version you want in the future. It's possible that amount of packages built for i686 will be somehow limited at some point, but I don't expect that to happen anytime soon. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1723904] perl-FFI-CheckLib-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1723904 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-FFI-CheckLib-0.25-1.fc ||31 --- Comment #1 from Petr Pisar --- An enhancement suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] Where am I?
Hi all, I've been very unwell since my return to Australia, so if there is anything urgent you need to me took at please contact me directly to notify me - I'm not looking at pagure this week. Sorry about this :( — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: gcc/g++ compiler memory exhaustion on build vms
> On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser > wrote: > Please quantify: What is the byte size of the .s file? > First hint: give the virtual machine enough resources! > Either RAM, or "swap" (paging) space. The .s got up to about 375M before that particular g++ compile process died. The jobs are submitted with the usual suspects: koji or fedpkg. I don't think we have any control over the resources allocatedto the vm's or containers the jobs land on (and we shouldn't). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc/g++ compiler memory exhaustion on build vms
On 6/26/19 00:25 UTC, Philip Kovacs via devel wrote: I am finding that one of my c++ packages has compilation units that generate very large assembly (.s) files -- so large that any attempt to build them in memory (e.g. with -pipe) causes memory exhaustion. The only way I have found to reliably get the build to run to completion is by using -save-temps to force g++ to save the .s assembly files to disk. Please quantify: What is the byte size of the .s file? First hint: give the virtual machine enough resources! Either RAM, or "swap" (paging) space. Also, -pipe itself uses at most (16 * 4KiB) more memory. Memory (RAM) exhaustion is caused by having all the (.data+.bss) of both the compiler and the assembler resident at the same time. (Most of this will be the symbol table for the assembler.) Even then, if you have enough swap space (shown by the utility program /usr/sbin/swapon, also by /usr/bin/top | grep Swap) then compilation will succeed, although much more slowly due to demand paging. You can increase swap space by using one or more "instantiated" files in the filesystem; see "man swapon". It may be possible to use the gcc option -ffunction-sections (possibly combined with a filter using /usr/bin/sed, etc.) as a hint to the assembler to discard the symbols for local labels upon reaching the end of each function. For particular cases, you can use "gcc --verbose ...", or even "strace -f -o strace.out -e trace=execve -s 500 gcc ...", to recover command sequences that may be edited according to desire. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
On 6/25/19 2:52 PM, Paul Wouters wrote: Note, it is a bit worrying that systemd depends on this package, which wasn't updated in 5 years, and for which the upstream changelog mostly states "bug fixes". I don't see a problem with that. What do you expect to change in a qrcode generator? Although I'm kind of curious why there is a major version bump. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: soname version bump for zita-convolver
Il giorno lun, 24/06/2019 alle 19.09 +0200, Igor Gnatenko ha scritto: > Hi Guido, > > On Mon, Jun 24, 2019 at 6:59 PM Guido Aulisi > wrote: > > Hello, > > I'm going to update zita-convolver library to version 4 in the next > > weeks, it will be a rather slow job because of holidays :-) > > > > According to dnf this update will impact the packages listed below: > > > > guitarix-0:0.37.3-3.fc30.x86_64 > > jconvolver-0:0.9.2-17.fc30.x86_64 > > ladspa-zam-plugins-0:3.10-5.fc30.x86_64 > > lv2-guitarix-plugins-0:0.37.3-3.fc30.x86_64 > > lv2-ir-plugins-0:1.3.4-4.fc30.x86_64 > > lv2-x42-plugins-0:0.10.0-0.1.20190507.fc31.x86_64 > > lv2-zam-plugins-0:3.10-5.fc30.x86_64 > > pulseeffects-0:4.5.0-1.fc30.i686 > > pulseeffects-0:4.5.0-1.fc30.x86_64 > > zam-plugins-0:3.10-5.fc30.x86_64 > > zita-convolver-devel-0:3.1.0-17.fc30.i686 > > zita-convolver-devel-0:3.1.0-17.fc30.x86_64 > > > > I can rebuild most of them, but not pulseeffects, I've got no > > commit > > privileges on that. > > Please ping me on IRC or over the email and I'll take care of it. Hi Igor, I made the upgrade and now only pulseeffects needs to be rebuilt, it wasn't a hard work at the end... Thank you for your help rebuilding that package. Ciao Guido ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1724012] ack-3.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1724012 --- Comment #1 from Upstream Release Monitoring --- One or more of the new sources for this package are identical to the old sources. It's likely this package does not use the version macro in its Source URLs. If possible, please update the specfile to include the version macro in the Source URLs -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1724012] New: ack-3.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1724012 Bug ID: 1724012 Summary: ack-3.0.1 is available Product: Fedora Version: rawhide Status: NEW Component: ack Keywords: FutureFeature, Triaged Assignee: robinlee.s...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.0.1 Current version/release in rawhide: 3.0.0-2.fc31 URL: http://search.cpan.org/dist/ack/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/15/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-06-26 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/26/report-389-ds-base-1.4.1.4-20190625git71138c0.fc30.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: gcc/g++ compiler memory exhaustion on build vms
On Tue, Jun 25, 2019 at 7:15 PM Philip Kovacs via devel
wrote:
> I am finding that one of my c++ packages has compilation units that generate
> very large assembly (.s)
> files -- so large that any attempt to build them in memory (e.g. with -pipe)
> causes memory exhaustion.
> The only way I have found to reliably get the build to run to completion is
> by using -save-temps to force
> g++ to save the .s assembly files to disk. I also have to remove any (make)
> parallelism in the builds.
>
> I am doing this:
>
> %configure \
> CXXFLAGS="${CXXFLAGS} -save-temps" \
> ...
>
> and using make (-j1 implied) instead of make_build.
>
> Just curious if anyone has a better suggestion here.
I've got a few packages with that problem, too. Besides the
approaches you listed above, I've done all of the following at one
point or another (just for the affected files; no need to pessimize
everything):
- Reduce optimization level from -O2 to -O1 or -O0.
- Reduce debugging info level from -g (== -g2) to -g1 or -g0.
- Pass -Wl,--no-keep-memory and -Wl,--reduce-memory-overheads to the linker.
That last one is because the linker runs out of memory while linking
polymake on 32-bit platforms.
Good luck!
--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
I - and a people around me - have plenty of 32-bit hardware. In case of e.g. volunteer youth work. When you need a dozen or two of PCs where do you get them from? They are those old machines you no longer use; the one your uncle gave you when he bought new laptop; the friend's one that broke but you managed to paritally fix it ... that's how you accumulate dozens of machines through the years so you can use them now. Nobody will ever just buy you a bunch of modern laptops just because you prepared something cool for the kids. And I'd love to run Fedora on them, since I know the OS the best and I'm developing on it. I'm able to automatize "cluster" installations or configurations fo those machines without learning much new. I already said I wouldn't like to see i686 support dropped, when the discussion was on the table last time. However I learned back then from someone's reply, what I think should be a golden rule around here. There can't be a project without developer / maintainer. Do *YOU* want to maintain it? No? Then who should? We are a community of volunteers. You can't force anybody here to maintain it for you. i686 will be missed by me. But I'm both not able to maintain & bugfix the (32-bit) kernel, nor I'm willing to devote it my time to learn and do it. It's same as any other orphaned package. No one willing to maintain it? FTBFS? Say "bye" to that package. Pitiful, but easy as that. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Jun 26, 2019 at 12:16 AM Dominik 'Rathann' Mierzejewski wrote: > > On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote: > > On Mon, Jun 24, 2019 at 23:17:30 -0500, > > Justin Forbes wrote: > > > > > > It is not a violent cheat. It was proposed this way 2 years ago. At > > > the time a SIG was created to maintain i686 so that it could continue > > > as a secondary arch. They are inactive. See the post in the SIG there. > > > When a call for a status was made (as the only traffic on their list > > > so far this year), it got a single reply from someone saying that they > > > would no longer have 32bit hardware as of August. > > > > I'm the one who responded. > > FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. > They're Atom N270 based, so 32-bit only. I'd like to run the most recent > Fedora on them, but I don't have much time to devote to debugging > i686-specific issues. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
gcc/g++ compiler memory exhaustion on build vms
I am finding that one of my c++ packages has compilation units that generate
very large assembly (.s)files -- so large that any attempt to build them in
memory (e.g. with -pipe) causes memory exhaustion.The only way I have found to
reliably get the build to run to completion is by using -save-temps to forceg++
to save the .s assembly files to disk. I also have to remove any (make)
parallelism in the builds.
I am doing this:
%configure \ CXXFLAGS="${CXXFLAGS} -save-temps" \ ...
and using make (-j1 implied) instead of make_build.
Just curious if anyone has a better suggestion here.
Phil___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
Am Dienstag, den 25.06.2019, 17:52 -0400 schrieb Paul Wouters: > This was a mistake on my end. I thought I was the owner of the > package, but I think I was only the owner of it back in el6. I assume > systemd then wasn't depending on it. I saw a PR the other day, assumed > it was to me as package owner, and saw no reason to not upgrade since > it was long over due. I didn't realise this would break systemd. > > Note, it is a bit worrying that systemd depends on this package, which > wasn't updated in 5 years, and for which the upstream changelog mostly > states "bug fixes". > > nirik untagged the package for me. I pinged Zbyszek to coordinate > things. I've reverted the commits for f29 and f30 (no updates were > issued for these branches yet) > > Ironically, this seems to not be the first time this happened either. > I see someone else made the exact same mistake in January 2018 and > reverted their changes to the package. So let's see if we can fix this > now in rawhide so it does not happen again in another year. > > Paul I've fixed the package in a way so-name bumps can be detected easily. If bootstrapping for such a bump (the next one) is needed one can do that now by simply editing some lines of the spec-file. During that fix, I've rebuilt systemd and the other consumers of qrencode against the new so-name. Cheers Björn signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Rawhide-20190625.n.0 compose check report
On Tue, 2019-06-25 at 17:45 +, Fedora compose checker wrote: > Missing expected images: > > Atomichost raw-xz x86_64 > Atomichost qcow2 x86_64 > > Compose FAILS proposed Rawhide gating check! > 3 of 47 required tests failed, 4 results missing > openQA tests matching unsatisfied gating requirements shown with **GATING** > below So, quite a few of these failures were down to some appearance changes in GNOME; I've updated the needles and am re-running those tests in prod now. Dusty, Colin, and atomic@ : you got this mail because fedfind / check- compose considered the Atomic Host images to be "missing", and I just implemented a thing in check-compose yesterday to send you reports when there is an Atomic-related failure (like we used to do with the separate Fedora-Atomic composes): https://pagure.io/fedora-qa/check-compose/issue/2 there is of course a bug there - fedfind shouldn't consider Atomic Host to be expected for Rawhide any more. I noticed that problem for F30+ updates composes and fixed it prior to rolling out the new check- compose, but didn't notice it also needed fixing for Rawhide and Branched. I will fix that now and send a new fedfind out. Here are some notes on the real failures: > Failed openQA tests: 18/137 (x86_64), 3/23 (i386), 1/2 (arm) > > ID: 415492Test: x86_64 Server-dvd-iso modularity_tests > URL: https://openqa.fedoraproject.org/tests/415492 This fails every day because of https://bugzilla.redhat.com/show_bug.cgi?id=1691030 . I wonder if we should adjust the test not to expect it at this point, since it's been broken for three months. > ID: 415528Test: x86_64 KDE-live-iso desktop_update_graphical > URL: https://openqa.fedoraproject.org/tests/415528 This one is a test issue, KDE just keeps changing how updates and notifications work and it's driving me nuts. https://bugzilla.redhat.com/show_bug.cgi?id=1716005 does not help either. I'll keep trying to make this reliable. > ID: 415532Test: x86_64 KDE-live-iso apps_startstop > URL: https://openqa.fedoraproject.org/tests/415532 Both failures here are test issues (one not waiting long enough before closing the app, one got sandbagged by an 'updates available' notification popping up over the button it was trying to press, thanks again KDE...) > ID: 415534Test: arm Minimal-raw_xz-raw.xz > install_arm_image_deployment_upload > URL: https://openqa.fedoraproject.org/tests/415534 This has just been failing forever, it's probably just emulation issues. We should probably take this test out as I never have time to maintain it. Ideally we want to run 32-bit ARM tests on aarch64 hosts, but haven't got around to that yet either. > ID: 415591Test: x86_64 universal upgrade_server_domain_controller > URL: https://openqa.fedoraproject.org/tests/415591 > ID: 415608Test: x86_64 universal upgrade_realmd_client > URL: https://openqa.fedoraproject.org/tests/415608 These two go together...I need to look into it further but it looks like perhaps DNS stops working on the server after the upgrade, as the client's attempt to refresh repos when it goes to run its own upgrade fails. > ID: 415601Test: x86_64 universal install_kickstart_firewall_disabled > **GATING** > URL: https://openqa.fedoraproject.org/tests/415601 This is https://bugzilla.redhat.com/show_bug.cgi?id=1722979 , mkolman has a fix for it under review ATM. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote: > On Mon, Jun 24, 2019 at 23:17:30 -0500, > Justin Forbes wrote: > > > > It is not a violent cheat. It was proposed this way 2 years ago. At > > the time a SIG was created to maintain i686 so that it could continue > > as a secondary arch. They are inactive. See the post in the SIG there. > > When a call for a status was made (as the only traffic on their list > > so far this year), it got a single reply from someone saying that they > > would no longer have 32bit hardware as of August. > > I'm the one who responded. FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. They're Atom N270 based, so 32-bit only. I'd like to run the most recent Fedora on them, but I don't have much time to devote to debugging i686-specific issues. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
This was a mistake on my end. I thought I was the owner of the package, but I think I was only the owner of it back in el6. I assume systemd then wasn't depending on it. I saw a PR the other day, assumed it was to me as package owner, and saw no reason to not upgrade since it was long over due. I didn't realise this would break systemd. Note, it is a bit worrying that systemd depends on this package, which wasn't updated in 5 years, and for which the upstream changelog mostly states "bug fixes". nirik untagged the package for me. I pinged Zbyszek to coordinate things. I've reverted the commits for f29 and f30 (no updates were issued for these branches yet) Ironically, this seems to not be the first time this happened either. I see someone else made the exact same mistake in January 2018 and reverted their changes to the package. So let's see if we can fix this now in rawhide so it does not happen again in another year. Paul On Tue, Jun 25, 2019 at 4:33 PM Miro Hrončok wrote: > qrencode was bumped from 3.4.4 to 4.0.2. > > It has a bumped soname from libqrencode.so.3 to libqrencode.so.4. > > systemd once again cannot be installed and all my packages fail to resolve > build > dependencies. > > Please, announce those changes and coordinate! > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
On 25. 06. 19 23:30, mcatanz...@gnome.org wrote: Let's ensure this at least doesn't happen for the same library again and again. In [1], change SHOULD NOT -> MUST NOT. That is unfortunately problematic, for various reasons discussed at FPC level, however even if we do change this to MUST, it will change nothing. > Require maintainers (or provenpackagers) to fix violations like [2] when > unannounced soname bumps occur. That would be nice, however, after several years I've realized that we cannot really require maintainers to do anything :( -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
On Tue, Jun 25, 2019 at 11:21 PM Miro Hrončok wrote: > > qrencode was bumped from 3.4.4 to 4.0.2. > > It has a bumped soname from libqrencode.so.3 to libqrencode.so.4. This might be a good time to remind people that globbing out shared libraries like this: https://src.fedoraproject.org/rpms/qrencode/blob/master/f/qrencode.spec#_63 is even strongly discouraged by the current Packaging Guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files - to help prevent packagers from accidentally bumping SONAMEs without noticing it. Fabio > systemd once again cannot be installed and all my packages fail to resolve > build > dependencies. > > Please, announce those changes and coordinate! > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
Let's ensure this at least doesn't happen for the same library again and again. In [1], change SHOULD NOT -> MUST NOT. Require maintainers (or provenpackagers) to fix violations like [2] when unannounced soname bumps occur. (If anyone wants to write a script to detect such problems proactively, even better.) If we don't fix [2] the problem will just occur again. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files [2] https://src.fedoraproject.org/rpms/qrencode/blob/f48205000af5397008dbd645abb941e0dbb49636/f/qrencode.spec#_63 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1723962] New: perl-Test-Refcount-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1723962 Bug ID: 1723962 Summary: perl-Test-Refcount-0.09 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Refcount Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, kwiz...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.09 Current version/release in rawhide: 0.08-15.fc31 URL: http://search.cpan.org/dist/Test-Refcount/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/11914/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[HEADS UP] Unannounced soname bump of qrencode
qrencode was bumped from 3.4.4 to 4.0.2. It has a bumped soname from libqrencode.so.3 to libqrencode.so.4. systemd once again cannot be installed and all my packages fail to resolve build dependencies. Please, announce those changes and coordinate! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need you
Hi, I can take python-pdfkit. Because business as usual. Upstream is active and there's a new version provided on PyPi. No idea why this package is orphaned. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity vs. libgit
On Tue, Jun 25, 2019 at 8:45 PM Stephen Gallagher wrote: > > > On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote: >> > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson < >> adamw...@fedoraproject.org> >> > wrote: >> > >> > > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote: >> > > > But ... if it's not for different version streams, then what *is it* >> > > for? 樂 >> > > > (What about the plans to offer different versions of e.g. NodeJS via >> > > > streams? Is that wrong then, too?) >> > > > >> > > > Being able to offer different versions is the only useful use-case >> I can >> > > > think of, and if that's not the intended usage ... I don't know why >> we >> > > need >> > > > it, or why somebody should use it at all ... >> > > >> > > Eh, I should probably butt out before I get things too far wrong. >> Let's >> > > wait for a licensed Modularity Person to show up and explain :) >> > > Stephen? Someone? >> > > >> > >> > Sorry, I've been on PTO. >> > >> > The idea behind a stream is that all updates within that stream are >> > intended to be fully backwards-compatible. In some cases (e.g. Node.js >> > major releases) this means that the version number is an appropriate >> way to >> > identify the stream. However, that's not always the case. Some projects >> > follow different versioning schemes and the version number is not >> actually >> > representative of the API stability (such as Cockpit, for example). >> > >> > So the stream naming is really dependent on what makes sense to the >> > upstream project. If upstream follows semver.org versioning (like >> Node.js), >> > then using the major version number as a stream is exactly right. For a >> > more complicated example, the IDM (aka FreeIPA) module in RHEL 8 chose >> to >> > use a stream called "DL-1" (domain level one). This is because it's a >> glue >> > project and a lot of its underlying pieces have differing version >> numbers, >> > but the whole stream is designed to support the ABI meeting a >> specification >> > they dubbed "DL-1". So any update, regardless of version bump, that >> retains >> > that compatibility is free to go into that stream. >> >> Well, the libgit streams wouldn't technically violate that, would they? >> That's sort of the point: they got in trouble by *following* that rule. >> When a new version came out that was API-incompatible, it showed up in >> a new stream. If it had been put in an existing stream and all the >> other streams had been rebuilt, things wouldn't have broken the way >> they did. >> > > Right, this was information I was missing a week ago. I think libgit2's > usage of the module streams here is *correct*, except for the part where > they're trying to change the default in a released Fedora, which is in > violation of the stable updates policy. > We are NOT changing default version of libgit2. We are changing dependency of some other tools to use new version of libgit2. >> So I'm still not confident about the story here. Let's take something >> that does follow semver: it's not going to change API compatibility as >> *often* as libgit2, but ultimately it's gonna happen. And in Rawhide, >> presumably, when a new major version comes out, we want installs to >> move to that new major version; that's how we've always done things in >> the past, that's what Rawhide is for. >> >> So what's the story there? How is that supposed to work? >> > > We have an open RFE for DNF to support recognizing a change in default > streams and switching over. It is complicated and we're still working out > the details. Please stay tuned. (Sorry, I can't find the BZ offhand, but > hopefully someone else can chime in with it). > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2019-06-26 from 18:00:00 to 19:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. Agenda is in the https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next Source: https://apps.fedoraproject.org/calendar/meeting/9364/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora Atomic Host Two Week Release Announcement: 29.20190625.0
On 6/25/19 1:38 PM, nore...@fedoraproject.org wrote: > > A new Fedora Atomic Host update is available via an OSTree update: > > Version: 29.20190625.0 > Commit(x86_64): > c50cc86ad7972f85853f1deafda3899eb86a0e5220c613744eed64320298716e > Commit(aarch64): > 0e82ac50808a1513cab1f8ad4c6262c091b19f39e3dfad8f22c2252aec38fd34 > Commit(ppc64le): > 72c06a8c8c18ff47ae9f7385a322dee325480ccc8a9276eafe9ac18b9a296422 > > > 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-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0.aarch64.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0.aarch64.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190625.0.iso > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0.ppc64le.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0.ppc64le.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190625.0.iso > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0.x86_64.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0.x86_64.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190625.0.x86_64.vagrant-libvirt.box > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190625.0.x86_64.vagrant-virtualbox.box > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190625.0.iso > > Respective signed CHECKSUM files can be found here: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0-aarch64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190625.0-aarch64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0-ppc64le-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190625.0-ppc64le-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0-x86_64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190625.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 >
Re: Modularity vs. libgit
On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson wrote: > On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote: > > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson < > adamw...@fedoraproject.org> > > wrote: > > > > > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote: > > > > But ... if it's not for different version streams, then what *is it* > > > for? 樂 > > > > (What about the plans to offer different versions of e.g. NodeJS via > > > > streams? Is that wrong then, too?) > > > > > > > > Being able to offer different versions is the only useful use-case I > can > > > > think of, and if that's not the intended usage ... I don't know why > we > > > need > > > > it, or why somebody should use it at all ... > > > > > > Eh, I should probably butt out before I get things too far wrong. Let's > > > wait for a licensed Modularity Person to show up and explain :) > > > Stephen? Someone? > > > > > > > Sorry, I've been on PTO. > > > > The idea behind a stream is that all updates within that stream are > > intended to be fully backwards-compatible. In some cases (e.g. Node.js > > major releases) this means that the version number is an appropriate way > to > > identify the stream. However, that's not always the case. Some projects > > follow different versioning schemes and the version number is not > actually > > representative of the API stability (such as Cockpit, for example). > > > > So the stream naming is really dependent on what makes sense to the > > upstream project. If upstream follows semver.org versioning (like > Node.js), > > then using the major version number as a stream is exactly right. For a > > more complicated example, the IDM (aka FreeIPA) module in RHEL 8 chose to > > use a stream called "DL-1" (domain level one). This is because it's a > glue > > project and a lot of its underlying pieces have differing version > numbers, > > but the whole stream is designed to support the ABI meeting a > specification > > they dubbed "DL-1". So any update, regardless of version bump, that > retains > > that compatibility is free to go into that stream. > > Well, the libgit streams wouldn't technically violate that, would they? > That's sort of the point: they got in trouble by *following* that rule. > When a new version came out that was API-incompatible, it showed up in > a new stream. If it had been put in an existing stream and all the > other streams had been rebuilt, things wouldn't have broken the way > they did. > Right, this was information I was missing a week ago. I think libgit2's usage of the module streams here is *correct*, except for the part where they're trying to change the default in a released Fedora, which is in violation of the stable updates policy. > > So I'm still not confident about the story here. Let's take something > that does follow semver: it's not going to change API compatibility as > *often* as libgit2, but ultimately it's gonna happen. And in Rawhide, > presumably, when a new major version comes out, we want installs to > move to that new major version; that's how we've always done things in > the past, that's what Rawhide is for. > > So what's the story there? How is that supposed to work? > We have an open RFE for DNF to support recognizing a change in default streams and switching over. It is complicated and we're still working out the details. Please stay tuned. (Sorry, I can't find the BZ offhand, but hopefully someone else can chime in with it). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190625.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 3 of 47 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 18/137 (x86_64), 3/23 (i386), 1/2 (arm) ID: 415492 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/415492 ID: 415500 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/415500 ID: 415501 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/415501 ID: 415510 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/415510 ID: 415517 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/415517 ID: 415528 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/415528 ID: 415532 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/415532 ID: 415533 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/415533 ID: 415534 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/415534 ID: 415585 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/415585 ID: 415589 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/415589 ID: 415591 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/415591 ID: 415592 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/415592 ID: 415594 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/415594 ID: 415597 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/415597 ID: 415600 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/415600 ID: 415601 Test: x86_64 universal install_kickstart_firewall_disabled **GATING** URL: https://openqa.fedoraproject.org/tests/415601 ID: 415604 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/415604 ID: 415605 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/415605 ID: 415608 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/415608 ID: 415615 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/415615 ID: 415625 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/415625 Soft failed openQA tests: 3/23 (i386), 2/137 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 415495 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/415495 ID: 415496 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/415496 ID: 415514 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/415514 ID: 415515 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/415515 ID: 415519 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/415519 Passed openQA tests: 107/137 (x86_64), 17/23 (i386) Skipped gating openQA tests: 4/137 (x86_64) ID: 415505 Test: x86_64 Workstation-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/415505 ID: 415506 Test: x86_64 Workstation-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/415506 ID: 415508 Test: x86_64 Workstation-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/415508 ID: 415509 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/415509 Skipped non-gating openQA tests: 7 of 162 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Atomic Host Two Week Release Announcement: 29.20190625.0
A new Fedora Atomic Host update is available via an OSTree update: Version: 29.20190625.0 Commit(x86_64): c50cc86ad7972f85853f1deafda3899eb86a0e5220c613744eed64320298716e Commit(aarch64): 0e82ac50808a1513cab1f8ad4c6262c091b19f39e3dfad8f22c2252aec38fd34 Commit(ppc64le): 72c06a8c8c18ff47ae9f7385a322dee325480ccc8a9276eafe9ac18b9a296422 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-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0.aarch64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0.aarch64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190625.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0.ppc64le.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0.ppc64le.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190625.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0.x86_64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0.x86_64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190625.0.x86_64.vagrant-libvirt.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190625.0.x86_64.vagrant-virtualbox.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190625.0.iso Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190625.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190625.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190625.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190625.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190625.0-x86_64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190625.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190625.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
Re: Modularity vs. libgit
On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote: > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson > wrote: > > > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote: > > > But ... if it's not for different version streams, then what *is it* > > for? 樂 > > > (What about the plans to offer different versions of e.g. NodeJS via > > > streams? Is that wrong then, too?) > > > > > > Being able to offer different versions is the only useful use-case I can > > > think of, and if that's not the intended usage ... I don't know why we > > need > > > it, or why somebody should use it at all ... > > > > Eh, I should probably butt out before I get things too far wrong. Let's > > wait for a licensed Modularity Person to show up and explain :) > > Stephen? Someone? > > > > Sorry, I've been on PTO. > > The idea behind a stream is that all updates within that stream are > intended to be fully backwards-compatible. In some cases (e.g. Node.js > major releases) this means that the version number is an appropriate way to > identify the stream. However, that's not always the case. Some projects > follow different versioning schemes and the version number is not actually > representative of the API stability (such as Cockpit, for example). > > So the stream naming is really dependent on what makes sense to the > upstream project. If upstream follows semver.org versioning (like Node.js), > then using the major version number as a stream is exactly right. For a > more complicated example, the IDM (aka FreeIPA) module in RHEL 8 chose to > use a stream called "DL-1" (domain level one). This is because it's a glue > project and a lot of its underlying pieces have differing version numbers, > but the whole stream is designed to support the ABI meeting a specification > they dubbed "DL-1". So any update, regardless of version bump, that retains > that compatibility is free to go into that stream. Well, the libgit streams wouldn't technically violate that, would they? That's sort of the point: they got in trouble by *following* that rule. When a new version came out that was API-incompatible, it showed up in a new stream. If it had been put in an existing stream and all the other streams had been rebuilt, things wouldn't have broken the way they did. So I'm still not confident about the story here. Let's take something that does follow semver: it's not going to change API compatibility as *often* as libgit2, but ultimately it's gonna happen. And in Rawhide, presumably, when a new major version comes out, we want installs to move to that new major version; that's how we've always done things in the past, that's what Rawhide is for. So what's the story there? How is that supposed to work? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity vs. libgit
On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson wrote: > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote: > > > > But ... if it's not for different version streams, then what *is it* > for? 樂 > > (What about the plans to offer different versions of e.g. NodeJS via > > streams? Is that wrong then, too?) > > > > Being able to offer different versions is the only useful use-case I can > > think of, and if that's not the intended usage ... I don't know why we > need > > it, or why somebody should use it at all ... > > Eh, I should probably butt out before I get things too far wrong. Let's > wait for a licensed Modularity Person to show up and explain :) > Stephen? Someone? > Sorry, I've been on PTO. The idea behind a stream is that all updates within that stream are intended to be fully backwards-compatible. In some cases (e.g. Node.js major releases) this means that the version number is an appropriate way to identify the stream. However, that's not always the case. Some projects follow different versioning schemes and the version number is not actually representative of the API stability (such as Cockpit, for example). So the stream naming is really dependent on what makes sense to the upstream project. If upstream follows semver.org versioning (like Node.js), then using the major version number as a stream is exactly right. For a more complicated example, the IDM (aka FreeIPA) module in RHEL 8 chose to use a stream called "DL-1" (domain level one). This is because it's a glue project and a lot of its underlying pieces have differing version numbers, but the whole stream is designed to support the ABI meeting a specification they dubbed "DL-1". So any update, regardless of version bump, that retains that compatibility is free to go into that stream. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1723904] New: perl-FFI-CheckLib-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1723904 Bug ID: 1723904 Summary: perl-FFI-CheckLib-0.25 is available Product: Fedora Version: rawhide Status: NEW Component: perl-FFI-CheckLib Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.25 Current version/release in rawhide: 0.24-2.fc31 URL: http://search.cpan.org/dist/FFI-CheckLib/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/13614/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: [Fedocal] Reminder meeting : Modularity Team (weekly)
#fedora-meeting-3: Weekly Meeting of the Modularity Team Meeting started by contyk at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-3/2019-06-25/modularity.2019-06-25-15.00.log.html Meeting summary --- * Roll Call (contyk, 15:00:04) * Redefine default for branch ref: (contyk, 15:03:02) * We would propose solving the use case with special modulemd variables; we will discuss this more in the ticket (contyk, 15:16:23) * What is the process to change default profile name with zero down time? (contyk, 15:16:49) * AGREED: Profiles cannot be removed during the lifetime of the stream in order to avoid breaking scripts. Options may exist for exceptional cases on an individual basis. (contyk, 15:41:06) * Next week's chair (contyk, 15:41:19) * ACTION: langdon will chair next week (contyk, 15:43:13) * Open floor (contyk, 15:43:19) Meeting ended at 15:55:50 UTC. Action Items * langdon will chair next week Action Items, by person --- * langdon * langdon will chair next week People Present (lines said) --- * contyk (81) * sgallagh (51) * langdon (34) * zodbot (14) * ignatenkobrain (8) * x3mboy (8) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 31 Rawhide 20190625.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 31 Rawhide 20190625.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20190621.n.0: anaconda-31.16-1.fc31.src, 20190625.n.0: anaconda-31.17-1.fc31.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/31 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190625.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
On 6/24/19 3:52 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jun 24, 2019 at 10:35:40AM -0700, Kevin Fenzi wrote: >> On 6/24/19 10:00 AM, Justin Forbes wrote: >>> On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek >>> wrote: >> >> ...snip... >> Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"? >>> >>> Changed on the wiki. >> >> Note that as far as I recall, this also means containers, as we need a >> kernel to build those, right? > > I'm don't know about all the possible ways we build containers in > Fedora, but intrinsically, there's certainly no reason to require an > amd64 kernel to build a 32-bit image. (*) > > Zbyszek > > (*) E.g. > dnf -y --releasever=31 --installroot=/var/lib/machines/f28-32 \ > --disablerepo='*' --enablerepo=fedora --enablerepo=updates install \ > systemd passwd dnf fedora-release vim-minimal --forcearch=i686 > still works. Sure, but thats not how we make official containers. Also, what about the i686 tree on mirrors? Not producing that would save a fair bit of compose time...on the other hand, if we do produce it, users could upgrade from old releases. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
On Mon, 24 Jun 2019 at 23:25, Ralf Corsepius wrote: > On 6/21/19 7:26 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels > > > > == Summary == > > Stop building i686 kernels, reduce the i686 package to a > > kernel-headers package that can be used to build 32bit versions of > > everything else. > > How does this affect the i386 as secondary architecture? > > Actually, I feel this proposal is a violoent cheat and should actually > be entitled: Drop i386 as secondary architecture. > > Two years ago you complained bitterly that removing i686 was bad and you wanted it kept. We then did the work towards getting the i686 sub-committee set up and sponsored so that you and others could take it from there. At the time it was set up it was clearly outlined that if it wasn't kept up, if it didn't have regular meetings and reports like the ARM and other groups do.. it would go away. Since then very little has been done with no regular reports and little traffic when people asked for help. This isn't a cheat. This is a clear consequence outlined 2 years ago. https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/VQQ6OHMXR4RGRR75EIQHOFU36UOZX7JP/ > Ralf > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump in iptables
On 25. 06. 19 13:02, Miro Hrončok wrote: Almost all of my packages started to fail in koschcei because of: nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Please, coordinate better next time :( The following packages probably need rebuilds: collectd connman iproute keepalived miniupnpd perl-IPTables-libiptc systemd I've attempted to rebuild systemd, but there is a dependency loop: Error: Problem 1: package gnutls-dane-3.6.8-1.fc31.x86_64 requires libunbound.so.8()(64bit), but none of the providers can be installed - package gnutls-devel-3.6.8-1.fc31.x86_64 requires libgnutls-dane.so.0()(64bit), but none of the providers can be installed - package gnutls-devel-3.6.8-1.fc31.x86_64 requires gnutls-dane(x86-64) = 3.6.8-1.fc31, but none of the providers can be installed - package unbound-libs-1.8.3-4.fc30.x86_64 requires systemd, but none of the providers can be installed - conflicting requests - nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Problem 2: package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02()(64bit), but none of the providers can be installed - package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02(Base)(64bit), but none of the providers can be installed - package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02(DM_1_02_97)(64bit), but none of the providers can be installed - package device-mapper-libs-1.02.158-1.fc31.x86_64 requires device-mapper = 1.02.158-1.fc31, but none of the providers can be installed - package cryptsetup-devel-2.2.0-0.2.fc31.x86_64 requires libcryptsetup.so.12()(64bit), but none of the providers can be installed - package device-mapper-1.02.158-1.fc31.x86_64 requires systemd >= 189-3, but none of the providers can be installed - conflicting requests - nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Problem 3: package gnutls-devel-3.6.8-1.fc31.x86_64 requires libgnutls-dane.so.0()(64bit), but none of the providers can be installed - package gnutls-devel-3.6.8-1.fc31.x86_64 requires gnutls-dane(x86-64) = 3.6.8-1.fc31, but none of the providers can be installed - package gnutls-dane-3.6.8-1.fc31.x86_64 requires libunbound.so.8()(64bit), but none of the providers can be installed - package libmicrohttpd-devel-1:0.9.64-1.fc31.x86_64 requires pkgconfig(gnutls), but none of the providers can be installed - package unbound-libs-1.8.3-4.fc30.x86_64 requires systemd, but none of the providers can be installed - conflicting requests - nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 I suggest we untag the iptables build. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: Golang 1.13
https://fedoraproject.org/wiki/Changes/golang1.13 == Summary == Rebase of Golang package to upcoming version 1.13 in Fedora 31, including rebuild of all dependent packages(pre-release version of Go will be used for rebuild, if released version will not be available at the time of the mass rebuild). == Owner == * Name: [[User:Jcajka| Jakub Čajka]] * Email: jca...@redhat.com == Detailed Description == Rebase of Golang package to upcoming version 1.13 in Fedora 31. Golang 1.13 is schedule to be released in Aug. Due to current nature and state of Go packages, rebuild of dependent package will be required to pick up the changes. With this rebase we will slightly deviate from upstream default config. By setting GOSUMDB=off and GOPROXY=direct, instead of them set to the default Google's services(or any other provider). This will still preserve the ability of users to set the nobs to value of their liking. By setting this we will prevent unintended (personal) information leaks. There will be no impact on users of the compiler. == Benefit to Fedora == Staying closely behind upstream by providing latest release of golang, which includes performance improvements and improvements in support for currently supported platforms among other bug fixes and new features. For complete list of changes see upstream change notes at https://tip.golang.org/doc/go1.13 . In result Fedora will be providing solid development platform for Go language. == Scope == * Proposal owners: Rebase golang package in f31, help with resolving possible issues found during package rebuilds. * Other developers: fix possible issues with help from golang maintainers * Release engineering: Rebuild of dependent packages as part of planned mass-rebuild. https://pagure.io/releng/issue/8481 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == None == How To Test == ;0. :a)Install golang 1.13 from rawhide and use it to build your application(s)/package(s). :b)Scratch build against rawhide. ;1. :Your application/package built using golang 1.13 should work as expected. == User Experience == None == Dependencies == (see wiki page) Not all of listed require re-build as they might not ship binaries. == Contingency Plan == * Contingency mechanism:Reverting to golang version 1.12.X if significatnt issues are discovered. * Contingency deadline: Beta Freeze(?) * Blocks release? No * Blocks product? No == Documentation == https://tip.golang.org/doc/go1.13 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: Golang 1.13
https://fedoraproject.org/wiki/Changes/golang1.13 == Summary == Rebase of Golang package to upcoming version 1.13 in Fedora 31, including rebuild of all dependent packages(pre-release version of Go will be used for rebuild, if released version will not be available at the time of the mass rebuild). == Owner == * Name: [[User:Jcajka| Jakub Čajka]] * Email: jca...@redhat.com == Detailed Description == Rebase of Golang package to upcoming version 1.13 in Fedora 31. Golang 1.13 is schedule to be released in Aug. Due to current nature and state of Go packages, rebuild of dependent package will be required to pick up the changes. With this rebase we will slightly deviate from upstream default config. By setting GOSUMDB=off and GOPROXY=direct, instead of them set to the default Google's services(or any other provider). This will still preserve the ability of users to set the nobs to value of their liking. By setting this we will prevent unintended (personal) information leaks. There will be no impact on users of the compiler. == Benefit to Fedora == Staying closely behind upstream by providing latest release of golang, which includes performance improvements and improvements in support for currently supported platforms among other bug fixes and new features. For complete list of changes see upstream change notes at https://tip.golang.org/doc/go1.13 . In result Fedora will be providing solid development platform for Go language. == Scope == * Proposal owners: Rebase golang package in f31, help with resolving possible issues found during package rebuilds. * Other developers: fix possible issues with help from golang maintainers * Release engineering: Rebuild of dependent packages as part of planned mass-rebuild. https://pagure.io/releng/issue/8481 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == None == How To Test == ;0. :a)Install golang 1.13 from rawhide and use it to build your application(s)/package(s). :b)Scratch build against rawhide. ;1. :Your application/package built using golang 1.13 should work as expected. == User Experience == None == Dependencies == (see wiki page) Not all of listed require re-build as they might not ship binaries. == Contingency Plan == * Contingency mechanism:Reverting to golang version 1.12.X if significatnt issues are discovered. * Contingency deadline: Beta Freeze(?) * Blocks release? No * Blocks product? No == Documentation == https://tip.golang.org/doc/go1.13 -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Tue, 2019-06-25 at 07:16 -0400, Nico Kadel-Garcia wrote: > On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen > wrote: > > On 6/19/19 1:51 PM, Aleš Matěj wrote: > > > > At this point, the drpm library is the only blocker for zstd > > > > payloads, > > > > since createrepo_c needs to be able to handle zstd drpms. > > > > > > I looked into the drpm library and I should be able to add the > > > zstd support > > > (and make sure it works with createrepo_c) > > > > > > Working on it now. > > > > FWIW, as drpm links to librpm anyway, it should be possible for > > drpm to > > just use the file API from rpm to gain support for everything that > > rpm > > does instead of duplicating the effort for all the compression > > types. > > > > If there's something broken or missing that prevents this from > > working, > > we could always address that... > > > > - Panu - > > This whole zstd replacement seems like a hazardous idea, because of > backporting SRPMs to older operating systems for EPEL compilation. > It's possible, but awkward, to chew through the git repos to deduce > whch git branch was used and reference that, rather than directly > extract from the SRPM. It would mean that unless this compression is > only applied to limited uses such as drpm, then older OS releases > would not be able to read the modern SRPM by default. Backwards > compatibility is not why people write new software, but broad > accessibility of the source code seems a vital feature to preserve > for > what should be rock stable build environments downstream. > > I, for one, have done considerable backporting of Fedora SRPMs of > python modules to RHEL and CentOS environments. I'd hate to add > another step to extract them on RHEL or CentOS or to build from them > in "mock". I'd also hate for "rpm2cpio" to break: I hope adding zstd > compatibility to the older versions of that tool, as well, is not > difficult. This is change is strictly only about binary rpm payload compression method change not at all about SRPMs. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
On Mon, Jun 24, 2019 at 23:17:30 -0500, Justin Forbes wrote: It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August. I'm the one who responded. I still have one machine that runs i686, but not x86_64. I'm hoping it keeps working until August, when I can afford to buy the rest of my power 9 based Blackbird to replace it. I have one other machine that I use on occasion that boots with an i686 kernel, because I used that when I first got it to use the same arch for all of my machines at that time. And I have been deferring doing a cross arch upgrade, but will in August. In theory I have another laptop with a bad keyboard, that can't use x86_64, but that I think would run current Fedora i686 kernels. But I haven't powered it on in years. I have done bisects for i686 issues in the past. I haven't had to in a while (at least a year for an i686 specific issue). People will actually get until spring if this passes, if they don't use rawhide. The hardware I have that is stuck on i686 is around 15 years old. I don't know other people who run hardware that old. I'm sure there are some, but probably not many. I would also expect new shiny software (i.e. Fedora) and ancient hardware is an odd combination. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump in iptables
On 25. 06. 19 13:31, Miro Hrončok wrote: On 25. 06. 19 13:02, Miro Hrončok wrote: Almost all of my packages started to fail in koschcei because of: nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Please, coordinate better next time :( The following packages probably need rebuilds: collectd connman iproute keepalived miniupnpd perl-IPTables-libiptc systemd I've attempted to rebuild systemd, but there is a dependency loop: Error: Problem 1: package gnutls-dane-3.6.8-1.fc31.x86_64 requires libunbound.so.8()(64bit), but none of the providers can be installed - package gnutls-devel-3.6.8-1.fc31.x86_64 requires libgnutls-dane.so.0()(64bit), but none of the providers can be installed - package gnutls-devel-3.6.8-1.fc31.x86_64 requires gnutls-dane(x86-64) = 3.6.8-1.fc31, but none of the providers can be installed - package unbound-libs-1.8.3-4.fc30.x86_64 requires systemd, but none of the providers can be installed - conflicting requests - nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Problem 2: package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02()(64bit), but none of the providers can be installed - package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02(Base)(64bit), but none of the providers can be installed - package cryptsetup-libs-2.2.0-0.2.fc31.x86_64 requires libdevmapper.so.1.02(DM_1_02_97)(64bit), but none of the providers can be installed - package device-mapper-libs-1.02.158-1.fc31.x86_64 requires device-mapper = 1.02.158-1.fc31, but none of the providers can be installed - package cryptsetup-devel-2.2.0-0.2.fc31.x86_64 requires libcryptsetup.so.12()(64bit), but none of the providers can be installed - package device-mapper-1.02.158-1.fc31.x86_64 requires systemd >= 189-3, but none of the providers can be installed - conflicting requests - nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Problem 3: package gnutls-devel-3.6.8-1.fc31.x86_64 requires libgnutls-dane.so.0()(64bit), but none of the providers can be installed - package gnutls-devel-3.6.8-1.fc31.x86_64 requires gnutls-dane(x86-64) = 3.6.8-1.fc31, but none of the providers can be installed - package gnutls-dane-3.6.8-1.fc31.x86_64 requires libunbound.so.8()(64bit), but none of the providers can be installed - package libmicrohttpd-devel-1:0.9.64-1.fc31.x86_64 requires pkgconfig(gnutls), but none of the providers can be installed - package unbound-libs-1.8.3-4.fc30.x86_64 requires systemd, but none of the providers can be installed - conflicting requests - nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 I suggest we untag the iptables build. https://bugzilla.redhat.com/show_bug.cgi?id=1723777 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, Jun 19, 2019 at 9:31 AM Panu Matilainen wrote: > > On 6/19/19 1:51 PM, Aleš Matěj wrote: > > > >> At this point, the drpm library is the only blocker for zstd payloads, > >> since createrepo_c needs to be able to handle zstd drpms. > > > > I looked into the drpm library and I should be able to add the zstd support > > (and make sure it works with createrepo_c) > > > > Working on it now. > > FWIW, as drpm links to librpm anyway, it should be possible for drpm to > just use the file API from rpm to gain support for everything that rpm > does instead of duplicating the effort for all the compression types. > > If there's something broken or missing that prevents this from working, > we could always address that... > > - Panu - This whole zstd replacement seems like a hazardous idea, because of backporting SRPMs to older operating systems for EPEL compilation. It's possible, but awkward, to chew through the git repos to deduce whch git branch was used and reference that, rather than directly extract from the SRPM. It would mean that unless this compression is only applied to limited uses such as drpm, then older OS releases would not be able to read the modern SRPM by default. Backwards compatibility is not why people write new software, but broad accessibility of the source code seems a vital feature to preserve for what should be rock stable build environments downstream. I, for one, have done considerable backporting of Fedora SRPMs of python modules to RHEL and CentOS environments. I'd hate to add another step to extract them on RHEL or CentOS or to build from them in "mock". I'd also hate for "rpm2cpio" to break: I hope adding zstd compatibility to the older versions of that tool, as well, is not difficult. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[HEADS UP] Unannounced soname bump in iptables
Almost all of my packages started to fail in koschcei because of: nothing provides libip4tc.so.0()(64bit) needed by systemd-242-3.git7a6d834.fc31.x86_64 Please, coordinate better next time :( The following packages probably need rebuilds: collectd connman iproute keepalived miniupnpd perl-IPTables-libiptc systemd -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: what to do when original upstream recover from death?
On Thu, Jun 06, 2019 at 12:55:49PM +0200, Petr Stodulka wrote: > My question is, do you have any related experience to the topic? I already > had some exprience with death upstreams, but this is really new to me. > As well, I am curious whether I did mistake when I switched to the > upstream[1] regarding the situation there was about the project. The upstream itself is nothing... it's all about users and trust. Try to talk with downstream (another distros) people -- it's better to coordinate the conclusion. It's always downstream decision to select the right upstream and it's better if all distros use the same upstream. Karel -- Karel Zak http://karelzak.blogspot.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage
On 25. 06. 19 12:07, Pierre-Yves Chibon wrote: On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote: On 25. 06. 19 9:50, Pierre-Yves Chibon wrote: I would say the scoping should happen (e.g. in copr) first, then we'll know what the scope (and hence feasibility) of this change truly is. What will the scoping actually tell us? If it tells us that X hundred packages need to add BR for python3-test, we'll just do that and report the list to upstream. We can do that during the mass rebuild. If there would indeed be X hundred packages affected, would this move still make sense? The python3-test subpackage is even larger than most of the rest of python3 combined, and the vast majority of it is irrelevant to other packages. Such usage would indicate to me that some work needs to be done within the ecosystem to respect its official status as internal-only. (Perhaps, in that case, a move to python3- devel could be considered instead.) Good questions. What number of affected packages do you think would be crucial? I say X hundred, because I don't anticipate it will go to thousands. However with 3000 Python packages, couple hundreds is IMHO not a big deal. Note that this is build dependency, not a runtime one. Nevertheless, there has been a great deal of effort recently to shrink buildroots and speed up build times. Having to add BR: python3-test to packages would mean adding a download of ~9MiB and an installation of ~3K files to every single affected package's build time. IMO this needs to be fully scoped before consideration. Wait a minute, adding a BR python3-test would mean an additional 9MiB ok, but currently these files are part of python3-libs which *every packages* get. In other words, for the packages that require python3-test the amount of data downloaded doesn't change while for all the packages that do *not* require python3-test, the amount of data is reduced. This sounds like a win to me :) Unfortunately, this is not correct. python3-test already is large. We just move a small bit of python3-libs (test.support) and we move it to python3-test for consistency. test.support is 396K installed (for Python 3.8). Arf, then it's a lesser win than I thought. Have you considered doing a python3-test-support subpackage? This would allow the separate package and thus give you the information you're looking for as well as avoid downloading the entire python3-test for these few files. The purpose of this change is to make packaging of Python easier and avoid problems, when the test.support module cannot be properly used without the rest of the test module. What you are proposing will make packaging more complicated and would not eliminate the problems at all. I think we are talking about couple packages here. Would it make sense to have a number and say that if more than X packages suddenly need to add BR for python3-test, we revert the change and consider a different approach? BTW python3-test is now buildrequired by 7 packages: python-bz2file python-honcho python-iniparse python-kitchen python-typing-extensions python-urwid python-zodbpickle -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage
On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote: > On 25. 06. 19 9:50, Pierre-Yves Chibon wrote: > > > > > > > I would say the scoping should happen (e.g. in copr) first, then > > > > > > > we'll > > > > > > > know what the scope (and hence feasibility) of this change truly > > > > > > > is. > > > > > > > > > > > > What will the scoping actually tell us? If it tells us that X > > > > > > hundred packages > > > > > > need to add BR for python3-test, we'll just do that and report the > > > > > > list to > > > > > > upstream. We can do that during the mass rebuild. > > > > > > > > > > If there would indeed be X hundred packages affected, would this move > > > > > still make sense? The python3-test subpackage is even larger than > > > > > most > > > > > of the rest of python3 combined, and the vast majority of it is > > > > > irrelevant to other packages. Such usage would indicate to me that > > > > > some work needs to be done within the ecosystem to respect its > > > > > official > > > > > status as internal-only. (Perhaps, in that case, a move to python3- > > > > > devel could be considered instead.) > > > > > > > > Good questions. What number of affected packages do you think would be > > > > crucial? > > > > I say X hundred, because I don't anticipate it will go to thousands. > > > > However > > > > with 3000 Python packages, couple hundreds is IMHO not a big deal. Note > > > > that > > > > this is build dependency, not a runtime one. > > > > > > Nevertheless, there has been a great deal of effort recently to shrink > > > buildroots and speed up build times. Having to add BR: python3-test to > > > packages would mean adding a download of ~9MiB and an installation of > > > ~3K files to every single affected package's build time. IMO this > > > needs to be fully scoped before consideration. > > > > Wait a minute, adding a BR python3-test would mean an additional 9MiB ok, > > but > > currently these files are part of python3-libs which *every packages* get. > > In other words, for the packages that require python3-test the amount of > > data > > downloaded doesn't change while for all the packages that do *not* require > > python3-test, the amount of data is reduced. > > This sounds like a win to me :) > > Unfortunately, this is not correct. > > python3-test already is large. > > We just move a small bit of python3-libs (test.support) and we move it to > python3-test for consistency. > > test.support is 396K installed (for Python 3.8). Arf, then it's a lesser win than I thought. Have you considered doing a python3-test-support subpackage? This would allow the separate package and thus give you the information you're looking for as well as avoid downloading the entire python3-test for these few files. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage
On 25. 06. 19 9:50, Pierre-Yves Chibon wrote: I would say the scoping should happen (e.g. in copr) first, then we'll know what the scope (and hence feasibility) of this change truly is. What will the scoping actually tell us? If it tells us that X hundred packages need to add BR for python3-test, we'll just do that and report the list to upstream. We can do that during the mass rebuild. If there would indeed be X hundred packages affected, would this move still make sense? The python3-test subpackage is even larger than most of the rest of python3 combined, and the vast majority of it is irrelevant to other packages. Such usage would indicate to me that some work needs to be done within the ecosystem to respect its official status as internal-only. (Perhaps, in that case, a move to python3- devel could be considered instead.) Good questions. What number of affected packages do you think would be crucial? I say X hundred, because I don't anticipate it will go to thousands. However with 3000 Python packages, couple hundreds is IMHO not a big deal. Note that this is build dependency, not a runtime one. Nevertheless, there has been a great deal of effort recently to shrink buildroots and speed up build times. Having to add BR: python3-test to packages would mean adding a download of ~9MiB and an installation of ~3K files to every single affected package's build time. IMO this needs to be fully scoped before consideration. Wait a minute, adding a BR python3-test would mean an additional 9MiB ok, but currently these files are part of python3-libs which *every packages* get. In other words, for the packages that require python3-test the amount of data downloaded doesn't change while for all the packages that do *not* require python3-test, the amount of data is reduced. This sounds like a win to me :) Unfortunately, this is not correct. python3-test already is large. We just move a small bit of python3-libs (test.support) and we move it to python3-test for consistency. test.support is 396K installed (for Python 3.8). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
On Mon, Jun 24, 2019 at 9:32 PM Chris Adams wrote: > > Once upon a time, Kevin Fenzi said: > > On 6/24/19 10:00 AM, Justin Forbes wrote: > > > On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > ...snip... > > > > >> Maybe the Change could be renamed to reflect the full impact: > > >> "No more i686 kernels or images"? > > > > > > Changed on the wiki. > > > > Note that as far as I recall, this also means containers, as we need a > > kernel to build those, right? > > If there are no i686 images, and no i686 containers, and anaconda can't > install i686 userspace with x86_64 kernel... is there any regular way to > consume i686 applications? It seems like the only reason to continue > building i686 RPMs would be for multilib (and their build dependencies), > which is a small subset of the total RPMs. Third parties using the userspace with their own kernels, I know there were groups using a custom kernel with i686 for various OLPC use cases still. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage
On Mon, Jun 24, 2019 at 07:37:19PM -0400, Yaakov Selkowitz wrote: > On Tue, 2019-06-25 at 00:26 +0200, Miro Hrončok wrote: > > On 25. 06. 19 0:18, Yaakov Selkowitz wrote: > > > On Mon, 2019-06-24 at 23:09 +0200, Miro Hrončok wrote: > > > > On 24. 06. 19 22:25, Yaakov Selkowitz wrote: > > > > > On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote: > > > > > > On 24. 06. 19 22:06, Yaakov Selkowitz wrote: > > > > > > > On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote: > > > > > > > > https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage > > > > > > > > > > > > > > > > == Summary == > > > > > > > > > > > > > > > > Move test.support from python3-libs to > > > > > > > > python3-test subpackage. > > > > > > > > > > > > > > > > == Owner == > > > > > > > > * Name: [[User:lbalhar| Lumír Balhar]] > > > > > > > > * Email: [mailto:lbal...@redhat.com| lbal...@redhat.com] > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > > > > > > > > > > > Python test modules should be used only for testing Python > > > > > > > > itself. > > > > > > > > However, some packages have buildtime or runtime dependency on > > > > > > > > parts > > > > > > > > of Python test modules. The aim of this change is to move the > > > > > > > > most > > > > > > > > popular Python test module test.support from > > > > > > > > python3-libs to python3-test > > > > > > > > subpackage > > > > > > > > which will help us discover packages which depend on it and also > > > > > > > > identify parts of the module which might be useful to move to > > > > > > > > standard > > > > > > > > library. > > > > > > > > > > > > > > The main reason for this change is to *experiment* and see what > > > > > > > breaks > > > > > > > when it is moved? Why can't that be done in copr instead? > > > > > > > > > > > > The main reason for this change is to make packaging of Python > > > > > > easier (and more > > > > > > explicit) and less error prone in the future. Discovering packages > > > > > > that need > > > > > > test.support is a secondary goal that help upstream but does not > > > > > > help Fedora much. > > > > > > > > > > > > Should the change be reworded so this is more clear? > > > > > > > > > > I would say the scoping should happen (e.g. in copr) first, then we'll > > > > > know what the scope (and hence feasibility) of this change truly is. > > > > > > > > What will the scoping actually tell us? If it tells us that X hundred > > > > packages > > > > need to add BR for python3-test, we'll just do that and report the list > > > > to > > > > upstream. We can do that during the mass rebuild. > > > > > > If there would indeed be X hundred packages affected, would this move > > > still make sense? The python3-test subpackage is even larger than most > > > of the rest of python3 combined, and the vast majority of it is > > > irrelevant to other packages. Such usage would indicate to me that > > > some work needs to be done within the ecosystem to respect its official > > > status as internal-only. (Perhaps, in that case, a move to python3- > > > devel could be considered instead.) > > > > Good questions. What number of affected packages do you think would be > > crucial? > > I say X hundred, because I don't anticipate it will go to thousands. > > However > > with 3000 Python packages, couple hundreds is IMHO not a big deal. Note > > that > > this is build dependency, not a runtime one. > > Nevertheless, there has been a great deal of effort recently to shrink > buildroots and speed up build times. Having to add BR: python3-test to > packages would mean adding a download of ~9MiB and an installation of > ~3K files to every single affected package's build time. IMO this > needs to be fully scoped before consideration. Wait a minute, adding a BR python3-test would mean an additional 9MiB ok, but currently these files are part of python3-libs which *every packages* get. In other words, for the packages that require python3-test the amount of data downloaded doesn't change while for all the packages that do *not* require python3-test, the amount of data is reduced. This sounds like a win to me :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
Hi, Ralf, one of the goals of the change process (mailing list announcements and discussion we have right here) is to identify various impacts of the change and also to find better wording for it (including the title). So you shouldn't feel cheated, just contribute your thoughts and suggest the corrections. On Tue, Jun 25, 2019 at 4:36 AM Ralf Corsepius wrote: > > On 6/21/19 7:26 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels > > > > == Summary == > > Stop building i686 kernels, reduce the i686 package to a > > kernel-headers package that can be used to build 32bit versions of > > everything else. > > How does this affect the i386 as secondary architecture? > > Actually, I feel this proposal is a violoent cheat and should actually > be entitled: Drop i386 as secondary architecture. I think that "No More i686 Kernels or bootable images" describes the change better. I searched through docs [1], [2], [3] and didn't find the definition for the secondary architecture which would fit the current case, thus "Drop as secondary architecture" would be confusing here. We do keep the i686 user-space packages, which means that we don't drop the architecture completely. And I think it makes sense to highlight it, especially with the recent news on the topic from Ubuntu world. [1] https://fedoraproject.org/wiki/Architectures#Structure [2] https://developer.fedoraproject.org/deployment/secondary_architectures/about.html [3] https://fedoraproject.org/wiki/Architectures/x86 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
