Reliability test for hard drives and SSD
Hi there! Good news for all interested in hardware compatibility and reliability. I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool! The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors. Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation. Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and others who had made this work possible by contribution to the database! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Kernel marking files in /boot as %ghost
> What is the result you expect from this email? You filed a bug, it was closed because the packaging was done intentionally and there is no other solution when considering the original reasons for the change. I'm not sure if you want the original change reverted entirely or what you would like to see, but "I don't like this" isn't really productive. Also, using rpm -qV as an indication that kernel installation is correct and bootable is simply never going to work anyway. The initramfs is generated at kernel installation time, and therefore has to be marked as %ghost. If that is missing, your machine doesn't boot with that kernel. If the grub config file doesn't get updated, your machine doesn't boot with that kernel. Not having initramfs or grub updated because of scriptlets not executing is expected, kernel image and configuration files etc. are however not. I am hoping for a discussion on how to potentially do this better without working around important rpm features. > What suggestion do you have for a solution? Stating the obvious, but why not install files to /boot in the first place as it was before. It seems the only logical thing to do until grub and other utilities learn how to read from other places. Also it seems like I am not the right person to answer that question since I still don't understand what are the benefits of having these files installed to /usr/lib/modules and also having them installed by default? If I understand correctly the only purpose they serve is to copy them back to /boot from some kind of /usr system image when restoring the system. This doesn't seem to me as a reason to install them by default in /usr in the first place. How about installing the files to /boot by default and making an optional subpackage named something like "kernel-stateless" with copies of these files. That way whatever needs its presence can depend on this subpackage. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: News in opencv package
On Sat, 2018-03-03 at 00:58 +0100, Till Hofmann wrote: > > On 03/02/2018 08:31 PM, Sérgio Basto wrote: > > On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote: > > > On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: > > > > > > > > player will fail due a glibc problem > > > > > > Can you elaborate? You've tried a build and it blew up? > > > > > > I am starting to get rather worried about this new glibc that > > > landed > > > yesterday. I think it might be breaking several things. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1 > > > > player is FTBFS since glibc 2.27, is not new . > > > > > > I was just going to take a look, but it seems like Rich already fixed > player last week: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1036515 > https://src.fedoraproject.org/rpms/player/c/d9eb02da8958a22915a6fd0b2 > 4f99397b0ac84e4?branch=master Cool , so as owner of fawkes you can built it , at least for F28 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1551174] New: perl-Test2-Suite-0.000102 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1551174 Bug ID: 1551174 Summary: perl-Test2-Suite-0.000102 is available Product: Fedora Version: rawhide Component: perl-Test2-Suite 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 Latest upstream release: 0.000102 Current version/release in rawhide: 0.000100-1.fc28 URL: http://search.cpan.org/dist/Test2-Suite/ 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/9536/ -- 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
Re: News in opencv package
On 03/02/2018 08:31 PM, Sérgio Basto wrote: > On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote: >> On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: >>> >>> player will fail due a glibc problem >> >> Can you elaborate? You've tried a build and it blew up? >> >> I am starting to get rather worried about this new glibc that landed >> yesterday. I think it might be breaking several things. > > https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1 > > player is FTBFS since glibc 2.27, is not new . > > I was just going to take a look, but it seems like Rich already fixed player last week: https://koji.fedoraproject.org/koji/buildinfo?buildID=1036515 https://src.fedoraproject.org/rpms/player/c/d9eb02da8958a22915a6fd0b24f99397b0ac84e4?branch=master Regards, Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28-20180302.n.0 compose check report
Missing expected images: Atomic qcow2 x86_64 Atomic raw-xz x86_64 Failed openQA tests: 16/127 (x86_64), 7/24 (i386), 1/2 (arm) ID: 196778 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/196778 ID: 196791 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/196791 ID: 196793 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/196793 ID: 196794 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/196794 ID: 196807 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/196807 ID: 196808 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/196808 ID: 196809 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/196809 ID: 196810 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/196810 ID: 196811 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/196811 ID: 196812 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/196812 ID: 196813 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/196813 ID: 196814 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/196814 ID: 196824 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/196824 ID: 196825 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/196825 ID: 196833 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/196833 ID: 196846 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/196846 ID: 196847 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/196847 ID: 196852 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/196852 ID: 196863 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/196863 ID: 196895 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/196895 ID: 196896 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/196896 ID: 196901 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/196901 ID: 196907 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/196907 ID: 196914 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/196914 Soft failed openQA tests: 7/127 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 196786 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/196786 ID: 196787 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/196787 ID: 196835 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/196835 ID: 196849 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/196849 ID: 196858 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/196858 ID: 196861 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/196861 ID: 196871 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/196871 ID: 196889 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/196889 ID: 196891 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/196891 Passed openQA tests: 82/127 (x86_64), 15/24 (i386) Skipped openQA tests: 20 of 153 -- 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
Re: why do I keep getting Broken dependencies: nfs-ganesha emails
On 03/02/2018 12:48 PM, Kaleb S. KEITHLEY wrote: > > E.g.: > ... > On x86_64: > nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires > libntirpc.so.1.6(NTIRPC_1.6.0)(64bit) > ... > > > I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and > even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining > about -0.4rc5. > > Is something stuck somewhere that it is complaining about this obsolete > build? No, you only build -1 in rawhide/f29. branched/f28 was still using the rc5 one until you built -2 today: > ➜ ~ koji list-tag-history --package=nfs-ganesha --tag=f28 ...snip... > Fri Feb 9 05:06:18 2018: nfs-ganesha-2.6.0-0.4rc5.fc28 tagged into f28 by > autopen [still active] > Fri Mar 2 04:43:10 2018: nfs-ganesha-2.6.0-2.fc28 tagged into f28 by autopen > [still active] > ➜ ~ koji list-tag-history --package=nfs-ganesha --tag=f29 > Tue Feb 20 02:28:06 2018: nfs-ganesha-2.6.0-0.4rc5.fc28 tagged into f29 by > mohanboddu [still active] > Tue Feb 20 05:31:30 2018: nfs-ganesha-2.6.0-1.fc28 tagged into f29 by autopen > [still active] > Tue Feb 20 13:17:42 2018: nfs-ganesha-2.6.0-0.5rc5.fc29 tagged into f29 by > autopen [still active] > Fri Feb 23 07:57:35 2018: nfs-ganesha-2.6.0-1.fc29 tagged into f29 by autopen > [still active] > Fri Mar 2 04:40:52 2018: nfs-ganesha-2.6.0-2.fc29 tagged into f29 by autopen > [still active] So, it should go away with tomorrow's f28 compose 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
Re: Re: Frequently broken Rawhide/Branched composes
On 03/02/2018 08:42 AM, Nicolas Mailhot wrote: > Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit : ...snip... >> That'd actually give us the opportunity to clean up more our repos no? >> :) > > Explain that to someone who had several hours/days of builds rejected > because of a broken obsolete package somewhere in the repo :( Well, it wouldn't be rejected, it just would be held. * Get your side tag * Do all your bootstrapping builds and rebuilding things that depend on it in the side tag. * submit it, and it gets checked Say there's one old package that doesn't build anymore against the new stack. You could either wait for it to get fixed or decide the rest of the builds are too important and wave the test to move them in. There would still be some breakage there (the one old package), but at least we would have record of who said that was ok so we could talk to them, and it's a deliberate decision. 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
Re: Why size of repositories metadata is too high in Fedora?
On Fri, Mar 2, 2018, at 3:29 PM, Andrew Lutomirski wrote: > I feel like that discussion is ignoring a third option: keep file deps > built preprocess the repo metadata to turn each file dep that is > uniquely satisfied by a single package into a direct dependency on > that package. This discussion is, but that was my first thought too; see https://github.com/projectatomic/rpm-ostree/issues/1127 I actually started writing just a little bit of code for it; I don't really have anything to show yet, but if I do I'll post it. It will clearly complement zsync or similar by being a lot less data to sync. (I think it's a lot more practical than anything requiring changes to librepo today anyways) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
why do I keep getting Broken dependencies: nfs-ganesha emails
E.g.: ... On x86_64: nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires libntirpc.so.1.6(NTIRPC_1.6.0)(64bit) ... I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining about -0.4rc5. Is something stuck somewhere that it is complaining about this obsolete build? -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildError: package PKGNAME not in list for tag f29-pending
On 03/02/2018 01:22 AM, Jan Chaloupka wrote: > Hi, > > anyone knows cause of the build error message? Getting the message for > 70 Go packages when building for rawhide. FYI, this was due to the new go macros treating everything as lower space, when these 70 packages had upper case in the name. 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
Re: Why size of repositories metadata is too high in Fedora?
> On Mar 2, 2018, at 6:42 AM, Matthew Millerwrote: > >> On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote: >> I don't know, I just ran "dnf upgrade" and it took metadata in >> mentioned size, Fedora developers should answer to these questions. > > A very large chunk of it is this: > https://pagure.io/packaging-committee/issue/714 > > I feel like that discussion is ignoring a third option: keep file deps built preprocess the repo metadata to turn each file dep that is uniquely satisfied by a single package into a direct dependency on that package. Obviously, once the package is actually installed, rpm would record the actual deps, but that's only for the packages that are installed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Frequently broken Rawhide/Branched composes
On 03/01/2018 07:40 PM, Kevin Kofler wrote: > And how do you propose doing that? The only reliable way to hold packages > that break the compose would be to actually try to run the whole compose > process after every package build. That just does not scale. The composes > are only daily for a reason. Running a compose for every package build would > use a lot of resources and would also take very long, delaying the tagging > of the package into Rawhide for an insane amount of time (at least hours). The vast majority of issues are related to a package update causing broken deps for something needed in something release blocking. So, I would start there and setup gating to check for broken deps and require waving that test or fixing the deps. The next most common issue is core tools changing that we use to compose (lorax, anaconda, kernel, glibc). For those we are intending to try and make 'quick composes' that compose something quickly and test it to catch common/simple issues. Then we go from there. > If you propose just doing some fast automated tests catching some issues, > that will never reliably catch all issues breaking the composes, and so my > proposals to increase the robustness of the compose process will still be > relevant. The only way to know for sure whether the compose will succeed is > to run it (and even that will not necessarily catch non-deterministic > failures). The problems I see with just shipping whatever we compose: * It means things will likely be broken longer as there is less urgency to fix them quickly. * There's cascading issues where issue A stops composing of items 1, 2, 3, 4 and each of those have further issues, so it means we don't even know what all is broken. * Shipping things out means we can't easily untag or revert packages with using Epoch's much more commonly. * It will mean we are not in fact always shipping alpha quality, we could be shipping anything. * reactive just is a lot harder in the end, IMHO. > It is just defensive programming to not fail the whole process on any small > issue that you cannot avoid (with the resources that are available). Not if you aren't sure of the thing you are producing. > > By the way, in the distant past, if some (or even all) live image compose(s) > failed, the compose would just get published without that/those live > image(s) (in the worst case, with an empty Live directory). Not ideal (and > keeping the last successful build of each image as I suggest doing would be > an improvement on that, Koji should be enough to fulfill the copyleft > licenses' source distribution requirements), but at least the package repo > went out a lot more often than nowadays. Well, I think the last few weeks have been particularly bad... it's not always like this (or even ever). > > > I am not asking you to ship bug-free composes. (I know that's impossible. > ;-) ) I am just asking you to take less than a week to get a compose with an > already built critical fix out. :-) Well, I am not sure I would call that a critical fix, but to each their own. 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
Re: News in opencv package
On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote: > On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: > > > > player will fail due a glibc problem > > Can you elaborate? You've tried a build and it blew up? > > I am starting to get rather worried about this new glibc that landed > yesterday. I think it might be breaking several things. https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1 player is FTBFS since glibc 2.27, is not new . -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Thu, 2018-03-01 at 18:44 -0700, stan wrote: > On Thu, 01 Mar 2018 14:29:45 - > "Farhad Mohammadi Majd"wrote: > > > Hello, in Debian (9, stable), size of all the official repositories > > metadata is maximum 10MB, while in Fedora, today I ran "dnf update" > > for first time after installing Fedora 27 > > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two > > official repositories! > > > > It is really too high, why there is such difference? why don't > > optimize it and fix this problem? > > I don't have any intimate knowledge of this. But you are comparing > apples and oranges. Apt and dnf. Either the format of the meta data > must be very different for the two, or apt must send much less meta > data. > > You aren't alone in complaining about this. Whenever an update occurs, > all the meta data has to be downloaded again. Well, not 'all' of it. The first run of dnf downloads an especially large amount of metadata as it gets the metadata for the frozen release repository ('fedora'). That never changes, so it only ever needs to get downloaded once. Subsequent runs will only need to update the metadata for the 'updates' and 'updates-testing' repositories, which is smaller. -- 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
Re: News in opencv package
On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: > > player will fail due a glibc problem Can you elaborate? You've tried a build and it blew up? I am starting to get rather worried about this new glibc that landed yesterday. I think it might be breaking several things. -- 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
Re: Appstream metadata compose failures
On Fri, 2018-03-02 at 11:28 +0100, Kalev Lember wrote: > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if maintainers could have a look and see if they can > make their packages pass! Hi, even not a maintainer, why is evolution-rss in the list, please? There is no "Vetos" section on that page for it, neither I noticed anything in a scratch build log I ran for rawhide, finished few minutes ago. https://koji.fedoraproject.org/koji/taskinfo?taskID=25422190 Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: News in opencv package
On Fri, 2018-03-02 at 10:29 -0800, Adam Williamson wrote: > On Fri, 2018-03-02 at 10:05 -0800, Adam Williamson wrote: > > On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote: > > > > > > On 03/02/2018 12:24 PM, Josef Ridky wrote: > > > > Hi folks, > > > > > > > > I would like to inform you, that new version of opencv package > > > > (3.4.1) will be available in rawhide and Fedora 28. > > > > All packages, that requires opencv should be rebuild. > > > > > > > > > > It would be nice if the announcement would have been made a week > > > in > > > advance, as stated in the guidelines, and as currently discussed > > > in the > > > other thread. > > > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_. > > > 2F_master > > > > Also note that Beta freeze is on 2018-03-06, so you are leaving > > maintainers of dependent packages only about 3 days to do their > > rebuilds for F28. :( > > In fact, 3.4.1 has not yet been built for F28, now I check. Would you > consider not doing it at present, given the F28 schedule? Thanks. > > I am rebuilding dependencies for F29 (was doing for F28 also, but > obviously will stop that). dnf repoquery --disablerepo='*' --enablerepo=rawhide --alldeps -- whatrequires 'libopencv*' --srpm --quiet | sed 's|\(-[^-]\+\)\{2\}.src||' OpenImageIO YafaRay digikam fawkes frei0r-plugins gmic libfreenect mlt mrpt nomacs opencv os-autoinst php-facedetect player simarrange simon siril player will fail due a glibc problem -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 962 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 852 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 823 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9 thttpd-2.25b-24.el6 434 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac libbsd-0.8.3-2.el6 163 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92 libmspack-0.6-0.1.alpha.el6 82 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e optipng-0.7.6-6.el6 54 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462 heimdal-7.5.0-1.el6 49 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4 rootsh-1.5.3-17.el6 18 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635 jhead-3.00-9.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26 exim-4.90.1-2.el6 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c8346d8e5 mbedtls-2.7.0-1.el6 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-76121890f9 seamonkey-2.49.2-2.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6ac908eac8 openjpeg2-2.3.0-6.el6 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829 freexl-1.0.5-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136 drupal7-7.57-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing dpm-xrootd-3.6.4-5.el6 openvpn-2.4.5-1.el6 Details about builds: dpm-xrootd-3.6.4-5.el6 (FEDORA-EPEL-2018-b22a063e36) XROOT interface to the Disk Pool Manager (DPM) Update Information: Bugfix release, no major changes. openvpn-2.4.5-1.el6 (FEDORA-EPEL-2018-a95abc37cf) A full-featured SSL VPN solution Update Information: Releasing upstream openvpn-2.4.5, which contains several bug-fixes and feature improvements. Details can can be found here in the [upstream change log](https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst). **Please note** the separate list of [deprecated options](https://community.openvpn.net/openvpn/wiki/DeprecatedOptions). Several options are going to be removed in the coming releases. And also start planning your migration away from the Blowfish/BF-CBC cipher. OpenVPN 2.4 provides by a quite easy way to do the cipher migration gradually. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 1089 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 852 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 434 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d libbsd-0.8.3-1.el7 331 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe mod_cluster-1.3.3-10.el7 163 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23 libmspack-0.6-0.1.alpha.el7 100 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece nagios-4.3.4-5.el7 50 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65 rootsh-1.5.3-17.el7 24 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1 jhead-3.00-7.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b exim-4.90.1-2.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e50c94a832 seamonkey-2.49.2-2.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-525417d3d4 mbedtls-2.7.0-1.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3 knot-resolver-2.1.0-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7a74678b1 openjpeg2-2.3.0-6.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39 uwsgi-2.0.16-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c mingw-wavpack-5.1.0-4.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91 freexl-1.0.5-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4 drupal7-7.57-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing argbash-2.6.0-1.el7 dpm-xrootd-3.6.4-5.el7 openvpn-2.4.5-1.el7 pagekite-0.5.9.2-1.el7 php-bartlett-php-compatinfo-db-1.30.0-1.el7 python-libcloud-2.2.1-5.el7 synergy-1.8.8-3.el7 waiverdb-0.9.0-1.el7 yubikey-piv-manager-1.4.2-3.el7 Details about builds: argbash-2.6.0-1.el7 (FEDORA-EPEL-2018-193b444e50) Bash argument parsing code generator Update Information: Update to 2.6.0 Adds preliminary bash-completion support dpm-xrootd-3.6.4-5.el7 (FEDORA-EPEL-2018-76ef623773) XROOT interface to the Disk Pool Manager (DPM) Update Information: Bugfix release, no major changes. openvpn-2.4.5-1.el7 (FEDORA-EPEL-2018-57e2736a0c) A full-featured SSL VPN solution Update Information: Releasing upstream openvpn-2.4.5, which contains several bug-fixes and feature improvements. Details can can be found here in the [upstream change log](https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst). **Please note** the separate list of [deprecated options](https://community.openvpn.net/openvpn/wiki/DeprecatedOptions). Several options are going to be removed in the coming releases. And also start planning your migration away from the Blowfish/BF-CBC cipher. OpenVPN 2.4 provides by a quite easy way to do the cipher migration gradually. References: [ 1 ] Bug #1526743 - Permissions on /etc/openvpn/server break default client-config-dir https://bugzilla.redhat.com/show_bug.cgi?id=1526743 pagekite-0.5.9.2-1.el7 (FEDORA-EPEL-2018-a7578c5325) Makes localhost servers visible to the world Update Information: New package - pagekite: makes localhost servers visible to the world References: [ 1 ] Bug #910699 - Review Request: pagekite - makes localhost servers visible to the world https://bugzilla.redhat.com/show_bug.cgi?id=910699 php-bartlett-php-compatinfo-db-1.30.0-1.el7 (FEDORA-EPEL-2018-d1dc597e20) Reference Database to be used with php-compatinfo library
Re: News in opencv package
On Fri, 2018-03-02 at 10:05 -0800, Adam Williamson wrote: > On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote: > > > > On 03/02/2018 12:24 PM, Josef Ridky wrote: > > > Hi folks, > > > > > > I would like to inform you, that new version of opencv package (3.4.1) > > > will be available in rawhide and Fedora 28. > > > All packages, that requires opencv should be rebuild. > > > > > > > It would be nice if the announcement would have been made a week in > > advance, as stated in the guidelines, and as currently discussed in the > > other thread. > > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master > > Also note that Beta freeze is on 2018-03-06, so you are leaving > maintainers of dependent packages only about 3 days to do their > rebuilds for F28. :( In fact, 3.4.1 has not yet been built for F28, now I check. Would you consider not doing it at present, given the F28 schedule? Thanks. I am rebuilding dependencies for F29 (was doing for F28 also, but obviously will stop that). -- 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
Re: News in opencv package
On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote: > > On 03/02/2018 12:24 PM, Josef Ridky wrote: > > Hi folks, > > > > I would like to inform you, that new version of opencv package (3.4.1) will > > be available in rawhide and Fedora 28. > > All packages, that requires opencv should be rebuild. > > > > It would be nice if the announcement would have been made a week in > advance, as stated in the guidelines, and as currently discussed in the > other thread. > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master Also note that Beta freeze is on 2018-03-06, so you are leaving maintainers of dependent packages only about 3 days to do their rebuilds for F28. :( -- 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
Re: Why size of repositories metadata is too high in Fedora?
On Fri, Mar 2, 2018 at 12:40 PM, Neal Gompawrote: > On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia wrote: >> On Thu, Mar 1, 2018 at 9:46 AM, chicago wrote: >>> Good question. What is in this 20+58MB? Is it all text? Does most of it it >>> change infrequently?/Maybe we can diff it? >> >> Most of it is pretty stable. But it's database-stored, and it's >> compressed. Both cause the overall files to change and be awkward to >> incrementally update, even if only one RPM actually changed. >> >> This is an old issue. One can reduce the download size needed and >> expand the local disk and computational requirements by adding >> delta-update and repodata merge tools, much as "deltarpms" did for the >> RPM's themselves. It helps, but it's also adding local CPU burden, and >> filesystem churn on the upstream repos to try and maintain that binary >> data as well as the original repodata. In My Honest Opinion, this is >> not going away until the whole "let's keep this all in one database" >> approach is discarded and individual small metadata files for each >> RPM, which can be surveyed and updated individually, replace the >> repodata. That is much more like apt, and it's unlikely in the >> foreseeable feature. > > APT hasn't done it this way in years. They've been actively reducing > the number of files because it makes it punishing for mirrors and is > rife for synchronization errors. I'm old. ;-) And... interesting. The trade-off between "I can incrementally update this by updating small files" versus I have an efficient but monolithic database and have to update that atomically" can be fun to select. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garciawrote: > On Thu, Mar 1, 2018 at 9:46 AM, chicago wrote: >> Good question. What is in this 20+58MB? Is it all text? Does most of it it >> change infrequently?/Maybe we can diff it? > > Most of it is pretty stable. But it's database-stored, and it's > compressed. Both cause the overall files to change and be awkward to > incrementally update, even if only one RPM actually changed. > > This is an old issue. One can reduce the download size needed and > expand the local disk and computational requirements by adding > delta-update and repodata merge tools, much as "deltarpms" did for the > RPM's themselves. It helps, but it's also adding local CPU burden, and > filesystem churn on the upstream repos to try and maintain that binary > data as well as the original repodata. In My Honest Opinion, this is > not going away until the whole "let's keep this all in one database" > approach is discarded and individual small metadata files for each > RPM, which can be surveyed and updated individually, replace the > repodata. That is much more like apt, and it's unlikely in the > foreseeable feature. APT hasn't done it this way in years. They've been actively reducing the number of files because it makes it punishing for mirrors and is rife for synchronization errors. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Thu, Mar 1, 2018 at 9:46 AM, chicagowrote: > Good question. What is in this 20+58MB? Is it all text? Does most of it it > change infrequently?/Maybe we can diff it? Most of it is pretty stable. But it's database-stored, and it's compressed. Both cause the overall files to change and be awkward to incrementally update, even if only one RPM actually changed. This is an old issue. One can reduce the download size needed and expand the local disk and computational requirements by adding delta-update and repodata merge tools, much as "deltarpms" did for the RPM's themselves. It helps, but it's also adding local CPU burden, and filesystem churn on the upstream repos to try and maintain that binary data as well as the original repodata. In My Honest Opinion, this is not going away until the whole "let's keep this all in one database" approach is discarded and individual small metadata files for each RPM, which can be surveyed and updated individually, replace the repodata. That is much more like apt, and it's unlikely in the foreseeable feature. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1550752] perl-Locale-Codes-3.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550752 Fedora Update Systemchanged: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Locale-Codes-3.56-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-437212397f -- 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
Re: Draft: Macros to tell what Python versions to package for
> "MH" == Miro Hrončokwrites: MH> I expect it to be called for both 2 and 3 unconditionally. Hiding MH> the condition in the maro makes things too magical for me. I don't think that stance holds up well as we increasingly hide things in macros and will continue to hide even more. (I'd like to see even more hidden with macros, up to having whole classes of specfiles completely generated by macros.) And I can certainly understand the git branch thing, but if we universally adopt and integrate %{with python3} as the conditional and you're manually passing --without python3 then why would you really want %py3_build to be executed unconditionally? The principle of least surprise would suggest that it isn't executed. - J< ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2018-03-02)
Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.log.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Draft: Macros to tell what Python versions to package for
> "PV" == Petr Viktorinwrites: PV> %install PV> %install PV> %if %{with python2} PV> %py2_install PV> %endif PV> %if %{with python3} PV> %py3_install PV> %endif So... why not just make %py2_install and %py3_install just do the %{with python*} internally, so the result is just %install %py2_install %py3_install And things just work. That way you only need the conditionals when you're doing something not covered by the macros. - J< ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Re: Frequently broken Rawhide/Branched composes
Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit : > On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote: > > Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit : > > > > > > I disagree entirely with the above. I think the solution is to > > > gate > > > packages coming into rawhide and hold or reject those that break > > > the > > > compose until they are fixed. > > > > While I don't disagree with the sentiment there needs to be a > > mechanism > > to handle bootstraps, where there are known-broken repository > > statuses > > between the beginning of the operation, when first bootstapped > > pavkages > > are injected, and the end, when several rebuild passes managed to > > get > > them all in fully build status. > > Wouldn't side-tags in koji handle this? Imagining there was a tool to > let packagers create/merge them as they need. Maybe. Let's just say, than after working for a few months with go, I've severely revised my understanding of bootstrapping complexity, both on the number of packages it may involve and the number of build phases it may need before succeeding. > > Also, how would you handle obsolete forgotten stray packages that > > linger > > in the repo (because they've not been killed properly, or a tool bug > > resulted in their non removal)? Gating gives any such package the > > power > > to block all updates in more critical packages > > That'd actually give us the opportunity to clean up more our repos no? > :) Explain that to someone who had several hours/days of builds rejected because of a broken obsolete package somewhere in the repo :( -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: News in opencv package
On 03/02/2018 12:24 PM, Josef Ridky wrote: > Hi folks, > > I would like to inform you, that new version of opencv package (3.4.1) will > be available in rawhide and Fedora 28. > All packages, that requires opencv should be rebuild. > It would be nice if the announcement would have been made a week in advance, as stated in the guidelines, and as currently discussed in the other thread. https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master For completeness' sake, here's the list of packages: $ dnf repoquery --disablerepo='*' --enablerepo='fedora' --releasever=rawhide --alldeps --whatrequires 'libopencv*' OpenImageIO-0:1.8.8-2.fc28.i686 OpenImageIO-0:1.8.8-2.fc28.x86_64 OpenImageIO-iv-0:1.8.8-2.fc28.x86_64 OpenImageIO-utils-0:1.8.8-2.fc28.x86_64 YafaRay-0:3.3.0-7.fc28.x86_64 YafaRay-lib-0:3.3.0-7.fc28.x86_64 digikam-0:5.8.0-4.fc28.x86_64 digikam-libs-0:5.8.0-4.fc28.i686 digikam-libs-0:5.8.0-4.fc28.x86_64 fawkes-firevision-0:1.0.1-13.fc28.i686 fawkes-firevision-0:1.0.1-13.fc28.x86_64 fawkes-guis-0:1.0.1-13.fc28.i686 fawkes-guis-0:1.0.1-13.fc28.x86_64 frei0r-plugins-opencv-0:1.6.1-4.fc28.x86_64 gmic-0:2.1.8-2.fc28.i686 gmic-0:2.1.8-2.fc28.x86_64 libfreenect-opencv-0:0.5.5-4.fc28.i686 libfreenect-opencv-0:0.5.5-4.fc28.x86_64 mlt-0:6.6.0-3.fc28.i686 mlt-0:6.6.0-3.fc28.x86_64 mrpt-2d-slam-0:1.4.0-6.fc28.x86_64 mrpt-apps-0:1.4.0-6.fc28.x86_64 mrpt-base-0:1.4.0-6.fc28.i686 mrpt-base-0:1.4.0-6.fc28.x86_64 mrpt-camera-calibration-0:1.4.0-6.fc28.x86_64 mrpt-gridmap-navigation-0:1.4.0-6.fc28.x86_64 mrpt-libs-0:1.4.0-6.fc28.i686 mrpt-libs-0:1.4.0-6.fc28.x86_64 mrpt-navlog-viewer-0:1.4.0-6.fc28.x86_64 mrpt-rawlog-viewer-0:1.4.0-6.fc28.x86_64 mrpt-reactive-navigation-0:1.4.0-6.fc28.x86_64 mrpt-robotic-arm-kinematics-0:1.4.0-6.fc28.x86_64 mrpt-scene-viewer-0:1.4.0-6.fc28.x86_64 mrpt-stereo-camera-calibration-0:1.4.0-6.fc28.x86_64 nomacs-0:3.8.0-1.fc28.i686 nomacs-0:3.8.0-1.fc28.x86_64 opencv-0:3.3.1-4.fc28.i686 opencv-0:3.3.1-4.fc28.x86_64 opencv-contrib-0:3.3.1-4.fc28.i686 opencv-contrib-0:3.3.1-4.fc28.x86_64 opencv-core-0:3.3.1-4.fc28.i686 opencv-core-0:3.3.1-4.fc28.x86_64 opencv-devel-0:3.3.1-4.fc28.i686 opencv-devel-0:3.3.1-4.fc28.x86_64 os-autoinst-0:4.5-4.20180208gitab8eeda.fc28.x86_64 php-facedetect-0:1.1.0-10.fc28.x86_64 player-0:3.1.0-4.fc27.i686 player-0:3.1.0-4.fc27.x86_64 python2-opencv-0:3.3.1-4.fc28.x86_64 python2-openimageio-0:1.8.8-2.fc28.x86_64 python3-opencv-0:3.3.1-4.fc28.x86_64 simarrange-0:0.0-16.20170316git8238ce5.fc28.x86_64 simon-0:0.4.1-15.fc28.x86_64 simon-libs-0:0.4.1-15.fc28.i686 simon-libs-0:0.4.1-15.fc28.x86_64 siril-0:0.9.8-1.fc28.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Thu, 2018-03-01 at 14:46 +, chicago wrote: > Good question. What is in this 20+58MB? Is it all text? Does most of > it it change infrequently?/Maybe we can diff it? I don't know, I just ran "dnf upgrade" and it took metadata in mentioned size, Fedora developers should answer to these questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Draft: Macros to tell what Python versions to package for
On 2.3.2018 16:23, Richard W.M. Jones wrote: On Fri, Mar 02, 2018 at 10:36:36AM +0100, Miro Hrončok wrote: Hello Pythonistas, I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at: https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros All you have to do to test it, is add the following block to your spec (that won't be needed once this is actually implemented): %if 0%{?fedora} %global py3_must 1 %global py3_may 1 %global py2_may 1 %endif %if 0%{?rhel} && 0%{?rhel} <= 7 %global py3_may 1 %global py2_may 1 %endif %if 0%{?rhel} > 7 ... (use your best judgment here) %endif Could you please provide feedback? Ask questions? There is a note at the bottom of the draft about how you could possibly start dropping Python 2 subpackages from Fedora. Thanks for doing this, it is much needed. I'm not really convinced by the *_may macros. If I've gone to the trouble of getting the subpackage snippets correct for both of python2 & python3, why wouldn't I just enable them in all possible situations? I can't see a situation where we've got possible subpackages but we don't want to build them (except for where python2/3 is not available in the distro and so they can't be built). You might want to remove python2 subpackage from Fedora because it's not needed by anything. Ultimately, removing leaf python2 subpackages is also our goal. If we only provide a macro that says "it is possible", people will keep using it until judgment day. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On Fri, Mar 2, 2018 at 8:10 AM, Kalev Lemberwrote: > On 03/02/2018 02:56 PM, Robert-André Mauchin wrote: > > qdirstat.desktop > > Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/ > 32x32/ > > apps/qdirstat.png, Has no Icon > > > > Well, what if upstream doesn't provide bigger icons? > > I believe the answer is to work with upstream to provide updated icons. > > I would personally be a bit more lax with what icon sizes we allow, but > right now we require at least a 64x64px icon. Since the freedesktop minimum[1] is a 48x48 icon, perhaps it would be best to be aligned with it. Thanks, Richard [1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On 03/02/2018 03:59 PM, Dennis Gilmore wrote: > El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió: >> Hi, >> >> hughsie just did a new appstream-data compose for F29 and I noticed >> there's quite a large number of packages failing in the logs: >> >> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html >> >> Would be awesome if maintainers could have a look and see if they can >> make their packages pass! >> > We were supposed to make builds fail if the appstream metadata failed, > why has that not been done? Sorry, I dropped the ball on this. I believe we need a brp script for rpmbuild that runs: DESTDIR=%{buildroot} appstream-util check-root and errors out if it fails. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
Richard Hughes wrote: > 64x64 is a very low bar indeed, compared to all of the other > platforms, e.g. Windows Store or the Apple AppStore. All that's going to happen with such a requirement is that specfiles are going to run the icon through scale2x or hq2x if you're lucky, through a dumb ImageMagick convert resize if you're not. You cannot expect the packager to draw a new icon for upstream software. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió: > Hi, > > hughsie just did a new appstream-data compose for F29 and I noticed > there's quite a large number of packages failing in the logs: > > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if maintainers could have a look and see if they can > make their packages pass! > We were supposed to make builds fail if the appstream metadata failed, why has that not been done? Dennis 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
[HEAD UP] soname bump Re: News in opencv package
Hi, Josef thanks for your work. As request we inform that is a soname bump , hopefully shouldn't change much since version 3.3.1 and bring a lot of security fixes Thanks, On Fri, 2018-03-02 at 06:24 -0500, Josef Ridky wrote: > Hi folks, > > I would like to inform you, that new version of opencv package > (3.4.1) will be available in rawhide and Fedora 28. > All packages, that requires opencv should be rebuild. > > Regards > > Josef Ridky > Associate Software Engineer > Core Services Team > Red Hat Czech, s.r.o. > -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On 2 March 2018 at 14:10, Kalev Lemberwrote: > I believe the answer is to work with upstream to provide updated icons. Right, or patch them in the srpm. Working upstream is obviously better than all the distros having to do the same thing... > I would personally be a bit more lax with what icon sizes we allow, but > right now we require at least a 64x64px icon. 64x64 is a very low bar indeed, compared to all of the other platforms, e.g. Windows Store or the Apple AppStore. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On 2 March 2018 at 14:44, Robert-André Mauchinwrote: > Also, with what command can I check if my package is now ok? From memory, I think you can do "appstream-builder name-of-the-file.rpm" and if it makes it into the example.xml.gz file then it passed all the checks. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On vendredi 2 mars 2018 15:10:59 CET Kalev Lember wrote: > On 03/02/2018 02:56 PM, Robert-André Mauchin wrote: > > > qdirstat.desktop > > Failed to load icon: icon was too small 32x32: > > /usr/share/icons/hicolor/32x32/ apps/qdirstat.png, Has no Icon > > > > Well, what if upstream doesn't provide bigger icons? > > > I believe the answer is to work with upstream to provide updated icons. > > I would personally be a bit more lax with what icon sizes we allow, but > right now we require at least a 64x64px icon. > > -- > Kalev > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Also, with what command can I check if my package is now ok? Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote: > I don't know, I just ran "dnf upgrade" and it took metadata in > mentioned size, Fedora developers should answer to these questions. A very large chunk of it is this: https://pagure.io/packaging-committee/issue/714 -- Matthew MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Call for users of darkserver
On Thu, 01 Mar 2018 19:30:28 +0100, Pierre-Yves Chibon wrote: > On Fri, Feb 16, 2018 at 03:04:11PM +0100, Jan Kratochvil wrote: > > On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote: > > It seems to me interactive crash core file analysis is just not a goal of > > ABRT > > (which is what was the goal of darkserver). > > Did it ever meet this goal? I do not know. > I never quite understood how it works, being far from this field, so I'm happy > to be enlighten on the topic. Darkserver itself will just give you a rpm build for given build-id. So with a core file (containing the build-ids) and a small shell script you can reconstruct system (chroot) where you can load the core file for more thorough crash analysis. > > And currently after my reassignment in Red Hat I currently do not have any > > ABRT bugreports to investigate so I am currently not involved in this > > darkserver/ABRT build-id crash reproducibility (I may be again later). > > Would you know if anyone in your old team would be interested by this? It is not specific to GDB team. I am curious how all the Fedora package developers deal with ABRT-filed Bugs where the backtrace contained therein is not sufficient to understand the problem but one may be able to understand it accessing more data with GDB using the core file. The backtrace contained in the ABRT bugreport can rarely really debug the problem. Sure even the core file is not always sufficient but it gives more chance to debug the crash (which requires an darkserver-like functionality). But then I usually cannot get even just the core file from ABRT users so this is why I ask how other package (*) maintainers deal with the ABRT bugreports. (*) It may be confusing I am GDB package maintainer when GDB is used for the crash analysis. But here I talk about GDB as any other program (like bash, firefox etc.) as even GDB crashes like any other program (bash, firefox, etc.). > I'm trying to assess if there is actually an interest for it. > You said you were interested by it but aren't working on this topic anymore, I > don't think anybody else than you noticed it not working over the course of > last > year. Yes, because I think nobody knows one could troubleshoot ABRT-bugreported problems better than with the information filed by ABRT into Bugzilla. > So I wonder if we shouldn't just call it a day, It won't change the current state of bugs troubleshooting. But Fedora should not forget the Bugs troubleshooting could be improved. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Kernel marking files in /boot as %ghost
On Fri, Mar 2, 2018 at 1:11 AM, Samuel Rakitničanwrote: > Dear list, > > I've stumbled upon a serious issue that has not been discussed before. > Somewhere around May 2015 kernel files was moved to > /usr/lib/modules/, which are then copied to /boot in post > scriptlets [1]. The issue is that such files are marked with %ghost because > they don't exist initially and are being copied when installed. Now because > of that rpm (rpm -qV) can't verify the files attributes correctly and heck > even doesn't point out if they don't exist at all as it is the case if dnf > fails in the middle of transaction. Because of that I've opened a bug report > [2], but it was closed because that was supposedly intended, but looking at > mailing list archive, I don't see this particular issue being raised and > frankly in my opinion marking files that are responsible to boot the system > as %ghost should not happen. %ghost should be used only when there is not any > other option left in case when files truly doesn't exist and its integrity > could not be verified in advance. What is the result you expect from this email? You filed a bug, it was closed because the packaging was done intentionally and there is no other solution when considering the original reasons for the change. I'm not sure if you want the original change reverted entirely or what you would like to see, but "I don't like this" isn't really productive. Also, using rpm -qV as an indication that kernel installation is correct and bootable is simply never going to work anyway. The initramfs is generated at kernel installation time, and therefore has to be marked as %ghost. If that is missing, your machine doesn't boot with that kernel. If the grub config file doesn't get updated, your machine doesn't boot with that kernel. What suggestion do you have for a solution? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On 03/02/2018 02:56 PM, Robert-André Mauchin wrote: > qdirstat.desktop > Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/ > apps/qdirstat.png, Has no Icon > > Well, what if upstream doesn't provide bigger icons? I believe the answer is to work with upstream to provide updated icons. I would personally be a bit more lax with what icon sizes we allow, but right now we require at least a 64x64px icon. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Appstream metadata compose failures
On vendredi 2 mars 2018 11:28:40 CET Kalev Lember wrote: > Hi, > > hughsie just did a new appstream-data compose for F29 and I noticed > there's quite a large number of packages failing in the logs: > > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if maintainers could have a look and see if they can > make their packages pass! > > -- > Thanks, > Kalev > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org qdirstat.desktop Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/ apps/qdirstat.png, Has no Icon Well, what if upstream doesn't provide bigger icons? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1547165] perl-ExtUtils-CBuilder should require gcc
https://bugzilla.redhat.com/show_bug.cgi?id=1547165 Petr Pisarchanged: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #10 from Petr Pisar --- I finished adding ExtUtils::CBuilder dependency to spec files. I omitted some of them where it came as a transitive dependency of some other already used XS-builder used module because I do not feel competent nor motivate to hunt the specific piece of line responsible for executing gcc in foreign packages. I fell little bit uneasy with this change. -- 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
Re: 389-ds-base and freeipa on 32 bit arches
On Fri, Feb 23, 2018 at 6:39 PM, Jared K. Smithwrote: > Can you give any more details on 32-bit ARM in particular -- is it just > i686 that is experiencing issues, or have you seen similar memory > corruption issues on 32-bit ARM as well? > Just another gentle ping -- do we have any more information here that can help FESCo as it makes a decision about this issue? -Jared ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[389-devel] Please review: Issue 49572 - ns_job_wait race on condvar
Hi team, please, review a small fix for nunc-stance tests: https://pagure.io/389-ds-base/issue/49572 https://pagure.io/389-ds-base/pull-request/49592 Thanks, Simon ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Thu, 2018-03-01 at 14:46 +, chicago wrote: > Good question. What is in this 20+58MB? Is it all text? Does most of > it it change infrequently?/Maybe we can diff it? I don't know, I just ran "dnf upgrade" and it took metadata in mentioned size, Fedora developers should answer to these questions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Need assistance to build openvdb for both Blender and LuxRender
On 03/02/2018 01:04 PM, Mamoru TASAKA wrote: /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In function 'void exportFloatGrid()': /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: error: 'py::numeric' has not been declared py::numeric::array::set_module_and_type("numpy", "ndarray"); ^~~ make[2]: *** [openvdb/python/CMakeFiles/pyopenvdb.dir/build.make:66: openvdb/python/CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o] Error 1 make[2]: *** Waiting for unfinished jobs I don't know why make does not stop immediately here (-k option implicitly specified??) Fedora builders use -j40 or something similar, so you tend to get lots of output from other jobs running parallel after the first error. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1550959] New: perl-CGI-Application-4.61 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550959 Bug ID: 1550959 Summary: perl-CGI-Application-4.61 is available Product: Fedora Version: rawhide Component: perl-CGI-Application Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, ktdre...@ktdreyer.com, perl-devel@lists.fedoraproject.org Latest upstream release: 4.61 Current version/release in rawhide: 4.60-1.fc29 URL: http://search.cpan.org/dist/CGI-Application/ 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/16959/ -- 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
Re: Need assistance to build openvdb for both Blender and LuxRender
Luya Tshimbalanga wrote on 03/02/2018 03:00 PM: Hello team, openvdb currently failed for some odd reasons (https://koji.fedoraproject.org/koji/taskinfo?taskID=25408808) on both Rawhide and F28 in order to rebuild for boost 1.66. Looking for tail result from build.log, it seems the mockbuild hit a bug: https://koji.fedoraproject.org/koji/getfile?taskID=25408809=DEFAULT=build.log=-4000 Can someone investigate the cause? Thanks Actually the above build.log says: make[2]: Entering directory '/builddir/build/BUILD/openvdb-5.0.0' [ 36%] Building CXX object openvdb/python/CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o cd /builddir/build/BUILD/openvdb-5.0.0/openvdb/python && /usr/bin/c++ -DOPENVDB_3_ABI_COMPATIBLE -Dpyopenvdb_EXPORTS -I/builddir/build/BUILD/openvdb-5.0.0 -isystem /usr/include/OpenEXR -i system /usr/include/python2.7 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -spe cs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wl ,--as-needed -fPIC -DOPENVDB_PRIVATE -DOPENVDB_USE_BLOSC -o CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o -c /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc make[2]: Leaving directory '/builddir/build/BUILD/openvdb-5.0.0' /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In function 'void exportFloatGrid()': /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: error: 'py::numeric' has not been declared py::numeric::array::set_module_and_type("numpy", "ndarray"); ^~~ make[2]: *** [openvdb/python/CMakeFiles/pyopenvdb.dir/build.make:66: openvdb/python/CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o] Error 1 make[2]: *** Waiting for unfinished jobs I don't know why make does not stop immediately here (-k option implicitly specified??) The above error message seems the same as: https://github.com/dreamworksanimation/openvdb/issues/170 Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1550943] perl-Net-CardDAVTalk-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550943 Petr Pisarchanged: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version|perl-Net-CardDAVTalk-0.09-1 |perl-Net-CardDAVTalk-0.09-1 |.fc29 |.fc28 Resolution|--- |NEXTRELEASE Last Closed||2018-03-02 06:35:31 -- 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
Re: Why size of repositories metadata is too high in Fedora?
On Fri, Mar 2, 2018 at 5:05 AM, Pavel Raiskupwrote: > On Friday, March 2, 2018 2:44:19 AM CET stan wrote: >> On Thu, 01 Mar 2018 14:29:45 - >> "Farhad Mohammadi Majd" wrote: >> >> > Hello, in Debian (9, stable), size of all the official repositories >> > metadata is maximum 10MB, while in Fedora, today I ran "dnf update" >> > for first time after installing Fedora 27 >> > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two >> > official repositories! >> > >> > It is really too high, why there is such difference? why don't >> > optimize it and fix this problem? >> >> I don't have any intimate knowledge of this. But you are comparing >> apples and oranges. Apt and dnf. Either the format of the meta data >> must be very different for the two, or apt must send much less meta >> data. > > Yes, IMO the amount of information in metadata creates the difference. > >> You aren't alone in complaining about this. Whenever an update occurs, >> all the meta data has to be downloaded again. People on limited >> quantity connections find this onerous. There has been discussion of >> making the meta data update an incremental update, but the format of >> meta data doesn't lend itself well to doing this. And the delta files >> would put a lot of extra files on repo hosts. > > I doubt delta files for metadata would cause significant storage problems > (compare that with the size of RPMs). You don't have to keep the deltas > forever, it would be matter of quality of implementation.. > > Do we have some RFE bug for this, or some feature page? This is #1 issue in > yum/dnf world for quite some time. > There's an ongoing discussion in rpm-ecosystem@[1] and infrastructure@[2] about an optimized delta repodata format. So... It's coming. :) [1]: http://lists.rpm.org/pipermail/rpm-ecosystem/2018-February/000541.html [2]: https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/4TJOGXT35Q2UHWYQA66FCCHCF5DOEXO5/ -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
News in opencv package
Hi folks, I would like to inform you, that new version of opencv package (3.4.1) will be available in rawhide and Fedora 28. All packages, that requires opencv should be rebuild. Regards Josef Ridky Associate Software Engineer Core Services Team Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1550943] perl-Net-CardDAVTalk-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550943 Petr Pisarchanged: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Net-CardDAVTalk-0.09-1 ||.fc29 --- Comment #1 from Petr Pisar --- An enhancement release. It changes existing functions and adds new dependencies. Safer for Fedora ≥ 28 only. -- 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
Re: Draft: Macros to tell what Python versions to package for
On 2.3.2018 11:54, Petr Viktorin wrote: I like to use bconds, i.e. "%if %{with python2}". They're easy to override for local builds, allowing easy experimentation with, for example, dropping Python 2. I'd be happy if our official recommendation used bconds. If we want people to copy-paste something, let's make it good. Also, "with_python2" is the current de-facto best practice. It's a good, descriptive name, and people are used to it. The "%if 0%{?py3_may}" is not as descriptive. If that is used throughout the specfile, people will need to know/read the docs – or just consider it magic. So, I'd prefer adding macros that set "with_python2" bconds, and using that throughout the specfile. For a more concrete idea, would something like this work? Naming to be bikeshedded of course. # Build for python2 if it MUST be done %py2_bcond_if required # Build for python3 if it MAY be done %py3_bcond_if available %build %{?with_python2:py2_build} %{?with_python3:py3_build} %install %if %{with python2} %py2_install %endif %if %{with python3} %py3_install %endif That looks good! (And some kind of %py_build_all and %py_install_all as the next baby step? Or am I reinventing a wheel with that line of thought?) That would be awesome, but let's keep that for another discussion maybe? Also, I'd like to do some wordsmithing on the proposal when the technicalities are sorted out, so the following is obvious to people who just skim it: - This new complexity is *only* meant for packagers who share specs across distros; others can stop reading now. - FYI, we would love it if you dropped your py2 subpackage from Fedora. Yes, yes! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Draft: Macros to tell what Python versions to package for
On 2.3.2018 11:50, Pavel Raiskup wrote: On Friday, March 2, 2018 11:32:40 AM CET Miro Hrončok wrote: On 2.3.2018 11:25, Pavel Raiskup wrote: On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote: I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at: https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros [..snip..] Could you please provide feedback? Ask questions? What's the real usecase for *_must? This tells you that according to the guidelines for given distro, if upstream supports this python version, you MUST package for it. Some packages might want to only package their Python library for the stacks where it's required. FWIW, I don't think macros should be used to _enforce_ guidelines (should be rather convenient things which everyone loves to use). But no problem, as long as I don't have to use that. Just saying that it might be a bit confusing when reading the (draft) wiki... They don't enforce anything. They just make it possible to get the value defined by the guideline in a technical manner and do with the value whatever you please. It's still up to the packager to decide what to do when py3_must is 1 or when it's not. If the wiki is confusing, I can try to reword the description. However I'm afraid everybody will just jump to the table anyway. Why the py2_must is not defined for epel7 and epel6? Because there is no such guideline. It is completely OK to package for python3 only on EPELs. I always only needed to see whether (a) python2 runtime is available, (b) python3 is available. So more readable and understandable approach (to me) would be to have only the %pyX_may (or %py3_available). But I'm probably not experienced enough, so I'm only curious :-). For that, yes. here may == available. We can discuss the naming if it sounds weird. E.g. last time (argparse-manpage) I went with: %if 0%{?fedora} %bcond_without python2 %bcond_without python3 %else %if 0%{?rhel} > 7 %bcond_withpython2 %bcond_without python3 %else %bcond_without python2 %bcond_withpython3 %endif %endif Which allows me to do things like: %if %{with python2} %endif Or: BuildRequires: %{?with_python3:foo} %{?with_python2:bar} .. and which brings the convenient --with{,out}-python{2,3} options for custom re-builds. Could we have something similar in the draft, too? We can definitively make those with statemetns, however we cannot make it with_python2 and with_python3, because we might destroy current specfiles with that. So we would need to have: %if %{with python2_must} %endif Or: BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar} And specifying those on the command line would be rather unreadable. What does --with-python2-may even mean? --with-py3 or --with-py3-available doesn't soudd that bad, but .. I wouldn't worry about existing spec files.. and I would stick with --with-python2 (and friends). Existing spec files should not depend on the distro-default value, since no distro so far defined that; which means that whatever value is defined in spec file will _just_ override the new system default. For the few remaining packages (are there any?), well, there go proven packagers...? I hear you. I like the idea Petr just sent to python-devel, so lets continue from there. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Draft: Macros to tell what Python versions to package for
I like to use bconds, i.e. "%if %{with python2}". They're easy to override for local builds, allowing easy experimentation with, for example, dropping Python 2. I'd be happy if our official recommendation used bconds. If we want people to copy-paste something, let's make it good. Also, "with_python2" is the current de-facto best practice. It's a good, descriptive name, and people are used to it. The "%if 0%{?py3_may}" is not as descriptive. If that is used throughout the specfile, people will need to know/read the docs – or just consider it magic. So, I'd prefer adding macros that set "with_python2" bconds, and using that throughout the specfile. For a more concrete idea, would something like this work? Naming to be bikeshedded of course. # Build for python2 if it MUST be done %py2_bcond_if required # Build for python3 if it MAY be done %py3_bcond_if available %build %{?with_python2:py2_build} %{?with_python3:py3_build} %install %if %{with python2} %py2_install %endif %if %{with python3} %py3_install %endif (And some kind of %py_build_all and %py_install_all as the next baby step? Or am I reinventing a wheel with that line of thought?) Also, I'd like to do some wordsmithing on the proposal when the technicalities are sorted out, so the following is obvious to people who just skim it: - This new complexity is *only* meant for packagers who share specs across distros; others can stop reading now. - FYI, we would love it if you dropped your py2 subpackage from Fedora. On 03/02/18 10:36, Miro Hrončok wrote: Hello Pythonistas, I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at: https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros All you have to do to test it, is add the following block to your spec (that won't be needed once this is actually implemented): %if 0%{?fedora} %global py3_must 1 %global py3_may 1 %global py2_may 1 %endif %if 0%{?rhel} && 0%{?rhel} <= 7 %global py3_may 1 %global py2_may 1 %endif %if 0%{?rhel} > 7 ... (use your best judgment here) %endif Could you please provide feedback? Ask questions? There is a note at the bottom of the draft about how you could possibly start dropping Python 2 subpackages from Fedora. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
[Bug 1550943] New: perl-Net-CardDAVTalk-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550943 Bug ID: 1550943 Summary: perl-Net-CardDAVTalk-0.09 is available Product: Fedora Version: rawhide Component: perl-Net-CardDAVTalk 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 Latest upstream release: 0.09 Current version/release in rawhide: 0.08-2.fc28 URL: http://search.cpan.org/dist/Net-CardDAVTalk/ 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/12579/ -- 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
[Bug 1550942] New: Upgrade perl-Lucy to 0.6.2
https://bugzilla.redhat.com/show_bug.cgi?id=1550942 Bug ID: 1550942 Summary: Upgrade perl-Lucy to 0.6.2 Product: Fedora Version: rawhide Component: perl-Lucy Assignee: lkund...@v3.sk Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org Latest Fedora delivers 0.6.1 version. Upstream released 0.6.2. When you have free time, please upgrade it -- 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
[Bug 1550940] New: Upgrade perl-CGI-Simple to 1.13
https://bugzilla.redhat.com/show_bug.cgi?id=1550940 Bug ID: 1550940 Summary: Upgrade perl-CGI-Simple to 1.13 Product: Fedora Version: rawhide Component: perl-CGI-Simple Assignee: tcall...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Latest Fedora delivers 1.115 version. Upstream released 1.13. When you have free time, please upgrade it -- 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
Re: Draft: Macros to tell what Python versions to package for
On 2.3.2018 11:25, Pavel Raiskup wrote: On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote: I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at: https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros [..snip..] Could you please provide feedback? Ask questions? What's the real usecase for *_must? This tells you that according to the guidelines for given distro, if upstream supports this python version, you MUST package for it. Some packages might want to only package their Python library for the stacks where it's required. Why the py2_must is not defined for epel7 and epel6? Because there is no such guideline. It is completely OK to package for python3 only on EPELs. I always only needed to see whether (a) python2 runtime is available, (b) python3 is available. So more readable and understandable approach (to me) would be to have only the %pyX_may (or %py3_available). But I'm probably not experienced enough, so I'm only curious :-). For that, yes. here may == available. We can discuss the naming if it sounds weird. E.g. last time (argparse-manpage) I went with: %if 0%{?fedora} %bcond_without python2 %bcond_without python3 %else %if 0%{?rhel} > 7 %bcond_withpython2 %bcond_without python3 %else %bcond_without python2 %bcond_withpython3 %endif %endif Which allows me to do things like: %if %{with python2} %endif Or: BuildRequires: %{?with_python3:foo} %{?with_python2:bar} .. and which brings the convenient --with{,out}-python{2,3} options for custom re-builds. Could we have something similar in the draft, too? We can definitively make those with statemetns, however we cannot make it with_python2 and with_python3, because we might destroy current specfiles with that. So we would need to have: %if %{with python2_must} %endif Or: BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar} And specifying those on the command line would be rather unreadable. What does --with-python2-may even mean? You can always define your with_python2 based on values of py2_may, py2_must and fedora version. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Appstream metadata compose failures
Hi, hughsie just did a new appstream-data compose for F29 and I noticed there's quite a large number of packages failing in the logs: https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html Would be awesome if maintainers could have a look and see if they can make their packages pass! -- Thanks, Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1550755] perl-Mozilla-CA-20180117 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550755 Petr Pisarchanged: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Mozilla-CA-20180117-1. ||fc29 Resolution|--- |RAWHIDE Last Closed||2018-03-02 05:25:07 --- Comment #1 from Petr Pisar --- No significant changes in binary package. Because we use system certificate storage instead, Rawhide is enough. -- 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
Re: Why size of repositories metadata is too high in Fedora?
Good question. What is in this 20+58MB? Is it all text? Does most of it it change infrequently?/Maybe we can diff it? signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Why size of repositories metadata is too high in Fedora?
On Friday, March 2, 2018 2:44:19 AM CET stan wrote: > On Thu, 01 Mar 2018 14:29:45 - > "Farhad Mohammadi Majd"wrote: > > > Hello, in Debian (9, stable), size of all the official repositories > > metadata is maximum 10MB, while in Fedora, today I ran "dnf update" > > for first time after installing Fedora 27 > > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two > > official repositories! > > > > It is really too high, why there is such difference? why don't > > optimize it and fix this problem? > > I don't have any intimate knowledge of this. But you are comparing > apples and oranges. Apt and dnf. Either the format of the meta data > must be very different for the two, or apt must send much less meta > data. Yes, IMO the amount of information in metadata creates the difference. > You aren't alone in complaining about this. Whenever an update occurs, > all the meta data has to be downloaded again. People on limited > quantity connections find this onerous. There has been discussion of > making the meta data update an incremental update, but the format of > meta data doesn't lend itself well to doing this. And the delta files > would put a lot of extra files on repo hosts. I doubt delta files for metadata would cause significant storage problems (compare that with the size of RPMs). You don't have to keep the deltas forever, it would be matter of quality of implementation.. Do we have some RFE bug for this, or some feature page? This is #1 issue in yum/dnf world for quite some time. Pavel > I think you can be assured that if there was a simple optimization that > could take care of this, it would have already been applied. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1550752] perl-Locale-Codes-3.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550752 --- Comment #2 from Fedora Update System--- perl-Locale-Codes-3.56-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-437212397f -- 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
[Bug 1550752] perl-Locale-Codes-3.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1550752 Petr Pisarchanged: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Locale-Codes-3.56-1.fc ||29 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora ≥ 27. -- 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
Re: Re: Frequently broken Rawhide/Branched composes
On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote: > Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit : > > > > I disagree entirely with the above. I think the solution is to gate > > packages coming into rawhide and hold or reject those that break the > > compose until they are fixed. > > While I don't disagree with the sentiment there needs to be a mechanism > to handle bootstraps, where there are known-broken repository statuses > between the beginning of the operation, when first bootstapped pavkages > are injected, and the end, when several rebuild passes managed to get > them all in fully build status. Wouldn't side-tags in koji handle this? Imagining there was a tool to let packagers create/merge them as they need. > Also, how would you handle obsolete forgotten stray packages that linger > in the repo (because they've not been killed properly, or a tool bug > resulted in their non removal)? Gating gives any such package the power > to block all updates in more critical packages That'd actually give us the opportunity to clean up more our repos no? :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Draft: Macros to tell what Python versions to package for
Hello Pythonistas, I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at: https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros All you have to do to test it, is add the following block to your spec (that won't be needed once this is actually implemented): %if 0%{?fedora} %global py3_must 1 %global py3_may 1 %global py2_may 1 %endif %if 0%{?rhel} && 0%{?rhel} <= 7 %global py3_may 1 %global py2_may 1 %endif %if 0%{?rhel} > 7 ... (use your best judgment here) %endif Could you please provide feedback? Ask questions? There is a note at the bottom of the draft about how you could possibly start dropping Python 2 subpackages from Fedora. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
BuildError: package PKGNAME not in list for tag f29-pending
Hi, anyone knows cause of the build error message? Getting the message for 70 Go packages when building for rawhide. Regards Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1544589] perl-SNMP-Info-3.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1544589 Jitka Plesnikovachanged: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-SNMP-Info-3.47-1.fc29 ||perl-SNMP-Info-3.47-1.fc28 Resolution|--- |RAWHIDE Assignee|w...@gouldfamily.org|jples...@redhat.com Last Closed||2018-03-02 04:12:46 -- 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
Re: Re: Frequently broken Rawhide/Branched composes
Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit : > > I disagree entirely with the above. I think the solution is to gate > packages coming into rawhide and hold or reject those that break the > compose until they are fixed. While I don't disagree with the sentiment there needs to be a mechanism to handle bootstraps, where there are known-broken repository statuses between the beginning of the operation, when first bootstapped pavkages are injected, and the end, when several rebuild passes managed to get them all in fully build status. Also, how would you handle obsolete forgotten stray packages that linger in the repo (because they've not been killed properly, or a tool bug resulted in their non removal)? Gating gives any such package the power to block all updates in more critical packages Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1549346] perl-Plack-Middleware-RemoveRedundantBody-0.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1549346 Jitka Plesnikovachanged: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-Plack-Middleware-Remov ||eRedundantBody-0.07-1.fc29 ||perl-Plack-Middleware-Remov ||eRedundantBody-0.07-1.fc28 Resolution|--- |RAWHIDE Assignee|dd...@cpan.org |jples...@redhat.com Last Closed||2018-03-02 03:54:44 -- 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
Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)
On Fri, Mar 02, 2018 at 06:10:16AM +0100, Ralf Corsepius wrote: > On 02/28/2018 05:43 PM, Adam Williamson wrote: > > On Wed, 2018-02-28 at 12:14 +0100, Ralf Corsepius wrote: > > > On 02/27/2018 07:27 PM, Richard Shaw wrote: > > > > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson > > > >> wrote: > > > > > > > > > > > > Once again, folks, *please* announce your soname bumps, and > > > > co-ordinate > > > > rebuilds. (In fact it looks like Zdenek is the maintainer of both > > > > packages and could have rebuilt cups-filters, but just forgot to). > > > > > > > > > > > > Is it time to update the packaging guidelines to enforce setting a > > > > "%global sover " and using it in %files? > > > > > > > > If nothing else it should at least be documented as a best practice. > > > > > > I would be very opposed to this. > > > > > > Even though some folks want rawhide to appear a release, rawhide is not > > > a release. So SONAME breakages are expected to happen in rawhide and > > > maintainers supposed to be reacted upon. > > > > This is not true and I have *specifically* pointed you at the policy > > page which says it is not true, more than once. > > And I have to reiterate my mantra: This plan is a non-realistic illusion. It > simply does not work and will not work. > > > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master > > > > For updates to rawhide packages, Maintainers SHOULD: > > > > Try not to push a clearly broken build (breaks the default > > buildroot package set, etc) > > Note the "SHOULD" - This is the reflection of what I said above. The SHOULD is necessary as otherwise we'll never be able to do soname bumps, but that doesn't say: be reckless and ignore the people you're giving work to. I think we all agree soname bumps happen and are necessary, what we try to advocate is that they don't happen by accident, that the packager pushing it knows what they are doing and announce it to the people it impacts. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Frequently broken Rawhide/Branched composes
On Fri, Mar 02, 2018 at 04:40:03AM +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > >> Something needs to be done to make the compose process more robust, e.g.: > >> * running createrepo on a stable release, so that we do not have to be > >> able > >> to init a chroot of the target system to compose a repository. A broken > >> dependency, even in systemd or rpm, should NEVER be a reason for the > >> repository to fail to compose. > >> * publishing individual deliverables one at a time, i.e.: > >> 1. compose the repositories, > >> 2. sync the repositories out to the mirrors, > >> 3. build the images (atomic ostrees, live images etc.) one at a time, > >> 4. sync those images that succeeded out to the mirrors, keep the old > >> versions of the other ones (the matching SRPMs are in Koji anyway, > >> so it does not matter if the SRPMs in the tree don't match) > >> etc. > > > > I disagree entirely with the above. I think the solution is to gate > > packages coming into rawhide and hold or reject those that break the > > compose until they are fixed. I think being proactive is VASTLY better > > than being reactive. Not breaking something in the first place is much > > easier to deal with than trying to fix it later. > > And how do you propose doing that? The only reliable way to hold packages > that break the compose would be to actually try to run the whole compose > process after every package build. That just does not scale. The composes > are only daily for a reason. Running a compose for every package build would > use a lot of resources and would also take very long, delaying the tagging > of the package into Rawhide for an insane amount of time (at least hours). Well, do you remember Will Woods' talk at DevConf? They managed to do a compose in a matter of minutes, so down the line this may be doable. In the mean while, baby steps. Yes running fast automated tests won't catch all the issues for every issues it will catch is one that will no need to be dealt with later. Once we have the mechanisms in place to gate packages entering rawhide, it will be easier to improve the gating tools. We could even do as everybody else is doing, start with some tests, fix a bug that got through, add the corresponding tests to prevent it from happening again, repeat... :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [RFC] Packages which are not installable (obsoleted by other pacakges)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-03-01 at 12:56 -0800, Kevin Fenzi wrote: > On 03/01/2018 08:46 AM, Igor Gnatenko wrote: > > I ran some check on latest compose and found that quite a few > > packages > > in repo can't be installed due to being obsoleted. What do we do > > about > > those packages? Should I submit bugs for each of them? > > I would say so yes. Then after some time just retire the rest. Ack, submitted 30 bugs. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqZBY8ACgkQaVcUvRu8 X0yyqRAArZwz+RFcUCfXZidxSUKs7wkFCxDCJmSv073/UX8LbOEBwE45gtuFIFZh rHcTJRX7/Ajy4mo1cbhuK1Z3iTALpoBlIiYrZPRf6SRS4lyfknKXhzHS43Z+xptB +3AjmOtEwwtJKf0Uw89Q8iuIAQLEFZgX8z1awPp3Czil2DQklojtVcKY4uo+q7Oo If7jh4nFVIXsYSVoYBbJB6uHhxGZiI86rdA9bO9LyHCX06MmA2ph8z0PhgsiS3pL 5qV0uE77JWi/9wNTwdAd5aZgdckcFbXMhq2i834j7sRgc+u8tA6w9cTC9TLcpE2F foZliV2d4UMhgixd++/F//IR3KqgNeBcCNWQUT8XToxhu9nfI4wp/g0GlRiAhzdN j1PUdAP6441aOPF0SlFSLVeK9ONLqUDgG8vfjOtMOVLxA+UiZCQs4Ui+b7KPhf/V /I9TW88Uaa4PjN2HpG4JVByr9p7FgkQtayF5mXwhmxNxABEt3J+ESmJB7oBWJFdw 9blCub/zGvwfAlhkmWR00DNxwPU1y9BGVRZUb2b0hmbzF+d0+B32euhMZKroCmUB BQLfAOv4irqC20Jz431etyCW9bvRkBchQjk1vd4Fj1XJCmPSR7hKzKz50iFg3z9f 56jGQZIMTdhKSBaoI9VC/yW2p07I3+rAajMVDsxldpg3FNA3oAg= =nnoA -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org