Re: I found 2 problems on remove python2-foo packages
On Mon, Jun 3, 2019 at 10:51 AM Sérgio Basto wrote:
>
> Hi,
> These removed python2 packages are breaking upgrade path
>
> 1- when you remove python2-foo , you should add to main package
> Obsoletes: python2-foo
If I may suggest, *absolutely not*. "Obsoletes: python2-foo"
specifically means that it includes and provides "python2-foo"
functionality, and "python3-foo" packages *do not* provide this. There
are a very few tools that put things in "/usr/bin" for typical use,
such as the "rpm" package itself which might benefit from such
options. But I think it's quite dangerous to replace them willy-nilly
due to compatibility for old packages which would have their
requirements replaced with something quite incompatible without
notification.
> 2- IMHO you should just remove python2-foo only on latest branches,
> please don't forget epel7 case, so please add something like :
> %if 0%{?fedora} >= 30
> %endif
Much too late for this release, I think. And dangerous for third party
python modules that have not been upgraded to python3 to break them
without notice. I think it would be much safer, if desired to force
migration, to use this:
%global pypi_name foo
%if 0%{?fedora} >= 30 || 0%{?rhel} >= 8
Conflicts: python2-%{pypi_name} >= %{verson}-%{release}
%endif
This would avoid touching older versions of the python2-foo modules
for compatibility with old packages, and block ongoing updates until
the older modules can be replaced. There are a potential few conflicts
that drop binaries in "/usr/bin/foo", tools such as "awscli". Those
might need review on a case by case basis, but they often have a
package without "python2-" in the name, and don't face the same
"python2/python3-" package split issue.
Does this make sense to you
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mock - signal reaction
Dne 03. 06. 19 v 13:00 Kamil Dudka napsal(a): >> Now I'm working on signal SIGTERM handling and I would like to kill all >> processes related to the main mock process. >> What do you think is it a good >> idea to kill all processes, or do we want to kill the main process only? >> And what about SIGINT so-called KeyInterrupt in python? Same reaction? > Your question is missing some context. Are you trying to improve signal > handling in your own code that uses mock, or are you trying to improve > signal handling in the implementation of mock itself? I will try to clarify this. In past, when you send SIGKILL to Mock, then only Mock terminated. It leaves behind any running rpmbuild or dnf. Jan is working on fix for this use case: https://github.com/rpm-software-management/mock/issues/153 As part of this work, we asked ourself the question: should mock clean up after itself when exiting? But I wonder what should be correct/expected behaviour? E.g., is someone running daemons in mock using 'chroot' or 'shell' command and would be surprised if Mock will kill it when Mock will terminate? Or we can assume that when Mock terminate then nothing should be running in the chroot? What are your use-cases? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Replacing glibc langpacks
Dne 27. 05. 19 v 11:34 Florian Weimer napsal(a): > I'm investigating whether it makes sense to switch to a scheme where the > glibc locale data is built from source, during package installation, > based on the langpack configuration system. This is similar to what > Debian does. I cannot comment on this one, but Debian world also have this: https://manpages.ubuntu.com/manpages/precise/man8/localepurge.8.html and I used to use this a lot and it saved a lot of disk space on target instance. It will not help you with installer size thou. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On 6/4/19 9:56 AM, Daniel Mach wrote: Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a): On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote: Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a): If we did this, wouldn't it make it very difficult to use tools like mock on RHEL / CentOS 7 to build for Fedora 3x? Speaking of Mock: Either the RPM on host need to understand the new format/compression **or** the packages in @buildsys group (including transitional deps) have to be in old format - then you can build for Fedora 3x using bootstrap feature. I need to underline this, it would be really really really bad if we were not able to --installroot fedora chroots at least on RHEL 8. How likely is a backport of zstd support into RPM in EL7+? RHEL 8 should be quite easy - get zstd package into RHEL and recompile rpm with zstd support. RHEL 7 is a different story. The patch doesn't apply directly and a backport would be needed. Panu, how difficult it would be to backport the zstd support to RHEL 7 RPM? Technically, backporting rpmio backends is almost trivial, even to much older rpm versions. Getting new features into older RHEL is a much bigger problem. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Plan to retire python-marrow-mailer and python-marrow-util
Hello. I plan to retire python-marrow-mailer and python-marrow-util packages. python-marrow-util is archived upstream [0] without replacement and it's incompatible with Python 3.8 [1]. python-marrow-mailer is also inactive in upstream (last commit from december 2016) [2]. marrow-mailer depends on marrow-util but nothing else in Fedora depends on both of them. Lumír [0] https://github.com/marrow/util [1] https://bugzilla.redhat.com/show_bug.cgi?id=1716508 [2] https://github.com/marrow/mailer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: I found 2 problems on remove python2-foo packages
The python2-foo removed packages be added to the fedora-obsoletes package. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
borgbackup license change
A few weeks ago I noticed that borgbackup bundles some libraries and copied some external code effectively changing the license of the final executable code. This change was not announced upstream so it went unnoticed when updated versions of borgbackup were pushed to Fedora's git. I just fixed the license tag: BSD -> "BSD AND zlib" If we need to bundle python3-msgpack (Fedora 30 + rawhide) the license tag becomes "BSD AND ASL AND zlib". We can drop the msgpack bundling when the next major version of borgbackup is published. Also I submitted upstream fixes to unbundle xxhash so hopefully you'll see less bundling whenever 1.2.0 is released. Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
lmdb fails to map large DBs on i686/s390x
Hi, I've been having some issues with LMDB on i686/s390x when building python-zarr and its dependants. I filed a bug report [1], but the maintainer suggested asking here to get more reach. I have replicated my original message from the report below: The documentation for LMDB [2] states that the map size should be "chosen as large as possible". Consequently, the zarr developers have chosen a map size of 2**40 on 64-bit systems and 2**28 on 32-bit systems [3]. When the package is built on a 64-bit system [4], everything works fine. However, if the build is run on a 32-bit system [5], it fails with a MemoryError. I have narrowed this down to the mmap call at [6] which attempts to map the backing file into memory. AFAICT, the mapped size is far below the RAM on the build machine as well as far below the normal 32-bit VM limit. So I don't know why the call is failing. I can reproduce this in mock with the fedora-rawhide-i386 config, but what's weird is it also fails in the fedora-rawhide-s390x config. This machine has 16G of RAM, so it's enough for 2**28, but not 2**40. So it fails on 32-bit x86 with more than enough RAM, works on 64-bit x86 with nowhere near enough RAM, yet fails with 64-bit s390x. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1695525 [2] http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5 [3] https://github.com/zarr-developers/zarr/blob/f6ced1e31b919065f8834d813ec081d2a85195b3/zarr/storage.py#L1585-L1587 [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=33910305 [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=33881973 [6] http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/liblmdb/mdb.c;h=e12af4482a0172da8d759c1da1530339d9095510;hb=2a5eaad6919ce6941dec4f0d5cce370707a00ba7#l4019 -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: lmdb fails to map large DBs on i686/s390x
On 04/06/2019 10:03, Elliott Sales de Andrade wrote: I have narrowed this down to the mmap call at [6] which attempts to map the backing file into memory. AFAICT, the mapped size is far below the RAM on the build machine as well as far below the normal 32-bit VM limit. So I don't know why the call is failing. It's not really about the physical memory because just doing the mmap won't actually read it all in and in any case the kernel will be quite happy to page bits in and out as needed. The issue will be whether there is that much contiguous address space available - on a 32 bit machine 2**28 is, at best, one sixteenth of the potential address space. I say at best because even with the best possible user:kernel split at least some address space is reserved to the kernel although that can be fairly small with some kernel configurations. Then you have to take the memory map into account though, and how address randomisation may have placed other mappings in locations that mean such a large contiguous mapping is not in fact available. Take a look an /proc/NNN/maps for the process when the mmap fails and see if it looks like there it a range of that size that is actually available... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
xtl tests fail on ppc64le/armv7hl with gcc9
Hi, I've had some issues with tests for xtl not working on ppc64le/armv7hl. These tests work fine on Fedora 29, but fail on 30+ [1]. Unfortunately, koschei does not check these platforms, but I'm fairly certain these started failing when gcc was updated to 9.0.0. Upstream is also suspicious that this might be a gcc9 issue [2]. Based on the errors, it's as if the code that's supposed to run to modify strings just isn't run. It's as if the compiler has determined that it should optimize away the relevant code. But somehow this doesn't happen on all platforms. While I am familiar with C and bits of C++, the template usage here is a bit too much for me to figure out. Can anyone familiar with this sort of thing take a look at what might be wrong? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=35079811 [2] https://github.com/QuantStack/xtl/issues/137 -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mock - signal reaction
On Tuesday, June 4, 2019 9:33:33 AM CEST Miroslav Suchý wrote: > Dne 03. 06. 19 v 13:00 Kamil Dudka napsal(a): > > >> Now I'm working on signal SIGTERM handling and I would like to kill all > >> processes related to the main mock process. > >> > >> What do you think is it a good > >> > >> idea to kill all processes, or do we want to kill the main process only? > >> And what about SIGINT so-called KeyInterrupt in python? Same reaction? > > > > Your question is missing some context. Are you trying to improve signal > > handling in your own code that uses mock, or are you trying to improve > > signal handling in the implementation of mock itself? > > > I will try to clarify this. > > In past, when you send SIGKILL to Mock, then only Mock terminated. It leaves > behind any running rpmbuild or dnf. > Jan is working on fix for this use > case: > https://github.com/rpm-software-management/mock/issues/153 > As part of this work, we asked ourself the question: should mock clean up > after itself when exiting? I think it should. But you will need to handle SIGTERM instead of SIGKILL. > But I wonder what should be correct/expected behaviour? E.g., is someone > running daemons in mock using 'chroot' or > 'shell' command and would be > surprised if Mock will kill it when Mock will terminate? Not that I know of. > Or we can assume > that when Mock terminate then nothing should be running in the chroot? Yes please. > What are your use-cases? csmock uses it for fully automated static analysis of RPM packages. Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Qt 5.12.3 coming to rawhide
Hi, I started update process in rawhide to update all Qt modules to 5.12.3 and later I will rebuild all packages depending on Qt private stuff. You may experience build failures until the whole update process is done, which should be hopefully tomorrow. Regards, Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: I found 2 problems on remove python2-foo packages
On Tue, 2019-06-04 at 03:25 -0400, Nico Kadel-Garcia wrote: > If I may suggest, *absolutely not*. "Obsoletes: python2-foo" > specifically means that it includes and provides "python2-foo" > functionality, No , on update just force remove of python2-foo , doesn't provide it . instead dnf broken dep, python2-foo requires foo=n when foo=n+1 . I remembered and as Leigh wrote : "The python2-foo removed packages be added to the fedora-obsoletes package." but not all python2-foo packages are in fedora-obsoletes and we also may not install fedora-obsoletes package ... Best regards, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: I found 2 problems on remove python2-foo packages
On Tue, Jun 4, 2019 at 3:26 AM Nico Kadel-Garcia wrote: > > On Mon, Jun 3, 2019 at 10:51 AM Sérgio Basto wrote: > > > > Hi, > > These removed python2 packages are breaking upgrade path > > > > 1- when you remove python2-foo , you should add to main package > > Obsoletes: python2-foo > > If I may suggest, *absolutely not*. "Obsoletes: python2-foo" > specifically means that it includes and provides "python2-foo" > functionality, and "python3-foo" packages *do not* provide this. There > are a very few tools that put things in "/usr/bin" for typical use, > such as the "rpm" package itself which might benefit from such > options. But I think it's quite dangerous to replace them willy-nilly > due to compatibility for old packages which would have their > requirements replaced with something quite incompatible without > notification. > I think you misunderstand here. Obsoletes does not specifically indicate it is equivalent. It is saying that you're replacing it. You will still get a broken dep chain if something Requires something that was obsoleted. It is absolutely the correct strategy to do Obsoletes (without Provides) here. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire osslsigncode
* Marek Marczykowski-Górecki: > I'd like to request unretire osslsigncode[1]. Originally it was retired > because of being abandoned upstream, but now there is an actively > maintained fork[2] with major release half a year ago and last commit > less than 2 months ago. As I understand[3], original maintainer of > Fedora osslsigncode package is not interested in maintaining it anymore. > I can take it from there, but that would be my first package in Fedora > (although I do maintain RPM packages elsewhere). I have already created > scratch build of it at [4]. How does it differ from pesign? Is it the Java support? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire osslsigncode
On Tue, Jun 4, 2019 at 8:16 AM Florian Weimer wrote: > > * Marek Marczykowski-Górecki: > > > I'd like to request unretire osslsigncode[1]. Originally it was retired > > because of being abandoned upstream, but now there is an actively > > maintained fork[2] with major release half a year ago and last commit > > less than 2 months ago. As I understand[3], original maintainer of > > Fedora osslsigncode package is not interested in maintaining it anymore. > > I can take it from there, but that would be my first package in Fedora > > (although I do maintain RPM packages elsewhere). I have already created > > scratch build of it at [4]. > > How does it differ from pesign? Is it the Java support? > My understanding is that pesign does not do signatures for arbitrary containers, only PE binaries. I'm also uncertain if pesign does Authenticode style signing. I'm not sure if Secure Boot signatures are the same kind of signatures. osslsigncode is a reimplementation of Windows' signtool that can sign Windows installers, PE binaries, and CAB files for driver packages. It's required for shipping signed versions of Fedora Media Writer and the VirtIO drivers for Windows. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire osslsigncode
On Tue, Jun 04, 2019 at 08:20:50AM -0400, Neal Gompa wrote: > On Tue, Jun 4, 2019 at 8:16 AM Florian Weimer wrote: > > > > * Marek Marczykowski-Górecki: > > > > > I'd like to request unretire osslsigncode[1]. Originally it was retired > > > because of being abandoned upstream, but now there is an actively > > > maintained fork[2] with major release half a year ago and last commit > > > less than 2 months ago. As I understand[3], original maintainer of > > > Fedora osslsigncode package is not interested in maintaining it anymore. > > > I can take it from there, but that would be my first package in Fedora > > > (although I do maintain RPM packages elsewhere). I have already created > > > scratch build of it at [4]. > > > > How does it differ from pesign? Is it the Java support? > > > > My understanding is that pesign does not do signatures for arbitrary > containers, only PE binaries. I'm also uncertain if pesign does > Authenticode style signing. I'm not sure if Secure Boot signatures are > the same kind of signatures. > > osslsigncode is a reimplementation of Windows' signtool that can sign > Windows installers, PE binaries, and CAB files for driver packages. > It's required for shipping signed versions of Fedora Media Writer and > the VirtIO drivers for Windows. Yes, exactly. Here drivers are my main concern. To be honest, I'm not sure if pesign wouldn't be enough to sign .sys and .dll files. In theory those should be also timestamped (which is not supported by pesign), but maybe that's only theory? Anyway, as Neal said, there are many more cases not supported by pesign. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
What to do when Fedora CI run failed?
Hello, I have run fedora-rawhide-build-pipeline https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/ that failed in the cloud-image-compose stage, something which (I believe) have very little control over. What is the recommended way to remedy the situation, for example for reruning that pipeline run? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Weak RPM dependencies which are not automatically re-installed on update
Is there a form of weak dependency which is installed when available, but not automatically re-installed on each update? If all the optional components are back after an update, that means that it's quite hard to maintain a minimal system installation. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do when Fedora CI run failed?
On Tue, Jun 04, 2019 at 03:28:12PM +0200, Jan Pazdziora wrote: > > Hello, > > I have run fedora-rawhide-build-pipeline > > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/ > > that failed in the > > cloud-image-compose > > stage, something which (I believe) have very little control over. > > What is the recommended way to remedy the situation, for example for > reruning that pipeline run? My other build on f30 https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f30-build-pipeline/detail/fedora-f30-build-pipeline/491/pipeline/183 resulted in orange exclamation mark status, in spite of the fact that the checkboxes in each of the states are all green. What does it mean and how should I fix it? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, Jun 4, 2019, 15:30 Florian Weimer wrote: > Is there a form of weak dependency which is installed when available, > but not automatically re-installed on each update? > > If all the optional components are back after an update, that means that > it's quite hard to maintain a minimal system installation. > The only permanent way to I found to block installation of certain weak dependencies is to add them to dnf's exclude list ... Fabio > Thanks, > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On 04. 06. 19 15:28, Florian Weimer wrote: Is there a form of weak dependency which is installed when available, but not automatically re-installed on each update? If all the optional components are back after an update, that means that it's quite hard to maintain a minimal system installation. See also https://bugzilla.redhat.com/show_bug.cgi?id=1699672 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote: > > Is there a form of weak dependency which is installed when available, > but not automatically re-installed on each update? > > If all the optional components are back after an update, that means that > it's quite hard to maintain a minimal system installation. > This feature is not yet wired up in DNF. We have all the information we need to make those kinds of decisions, but it currently isn't accounted for. I discussed this with Daniel Mach at openSUSE Conference and he's aware that it's possible and some work could be done to support this depending on demand for the feature. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do when Fedora CI run failed?
On Tue, Jun 4, 2019 at 3:29 PM Jan Pazdziora wrote: > > Hello, > > I have run fedora-rawhide-build-pipeline > > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/ > > that failed in the > > cloud-image-compose > > stage, something which (I believe) have very little control over. > > What is the recommended way to remedy the situation, for example for > reruning that pipeline run? > Hi Jan, you might want to cc the CI list: https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
* Neal Gompa: > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote: >> >> Is there a form of weak dependency which is installed when available, >> but not automatically re-installed on each update? >> >> If all the optional components are back after an update, that means that >> it's quite hard to maintain a minimal system installation. >> > > This feature is not yet wired up in DNF. We have all the information > we need to make those kinds of decisions, but it currently isn't > accounted for. I discussed this with Daniel Mach at openSUSE > Conference and he's aware that it's possible and some work could be > done to support this depending on demand for the feature. Does it sense to reopen bug 1699672, in light of this development? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale packages in Fedora 30
On Sun, 2 Jun 2019 at 15:14, Miro Hrončok wrote: > On 31. 05. 19 16:10, Fabio Valentini wrote: > > On Thu, May 30, 2019 at 8:19 PM Adam Jackson wrote: > >> > >> Since I was looking at a copy of the F30 repo for amd64, here's a list > >> of a bunch of packages whose dist tag suggests they haven't rebuilt > >> successfully in any currently-supported Fedora release. I'm sure some > >> of these are incompletely retired or there's otherwise some good reason > >> for it, this is just to raise visibility. > > > > AFAICT, a lot of these packages should have been retired ages ago. > > > > Is the retirement procedure for long-standing FTBFS packages being done > at all? > > Not at all. See https://pagure.io/releng/issue/7718 > > This has been deployed and should start sending out weekly reminders soon. > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
Dne 04. 06. 19 v 15:48 Neal Gompa napsal(a): > he's aware that it's possible and some work could be > done to support this depending on demand for the feature. I do demand this feature :) I would love to see "dnf mark" command to utilize for this. Something like: dnf mark soft-remove I.e. remove the package and does not install it again unless something pull it back using hard "Requires". -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale packages in Fedora 30
On Tue, Jun 4, 2019, 15:59 Stephen John Smoogen wrote: > > > On Sun, 2 Jun 2019 at 15:14, Miro Hrončok wrote: > >> On 31. 05. 19 16:10, Fabio Valentini wrote: >> > On Thu, May 30, 2019 at 8:19 PM Adam Jackson wrote: >> >> >> >> Since I was looking at a copy of the F30 repo for amd64, here's a list >> >> of a bunch of packages whose dist tag suggests they haven't rebuilt >> >> successfully in any currently-supported Fedora release. I'm sure some >> >> of these are incompletely retired or there's otherwise some good reason >> >> for it, this is just to raise visibility. >> > >> > AFAICT, a lot of these packages should have been retired ages ago. >> > >> > Is the retirement procedure for long-standing FTBFS packages being done >> at all? >> >> Not at all. See https://pagure.io/releng/issue/7718 >> >> > This has been deployed and should start sending out weekly reminders soon. > Great! Thank you :) > > >> -- >> Miro Hrončok >> -- >> Phone: +420777974800 >> IRC: mhroncok >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > > -- > Stephen J Smoogen. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
Germano Massullo wrote: >A dubt about XDG_CURRENT_DESKTOP. Since boinc-client runs as a service >with its own user, I don't think it will be able to read >XDG_CURRENT_DESKTOP defined in other users sessions. Therefore IMHO I >need another kind of solution So the question isn't what desktop the user is using, but rather what desktops, if any, other users on the machine are using. Have you confirmed that you're able to query another user's desktop session once you know which desktop it is? The ability to do such things should be quite limited for security reasons, even though Boinc has a legitimate use case. Björn Persson pgpJQ1ATVgbCA.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson ha scritto: > So the question isn't what desktop the user is using, but rather what > desktops, if any, other users on the machine are using. Well when I started the thread I had not thought that BOINC client service is running on a confined user. > Have you confirmed that you're able to query another user's desktop session > once > you know which desktop it is? I cannot read XDG_CURRENT_DESKTOP of other users. I am actually wondering if checking for specific executables [1] [2] would be the best idea [1]: like for example /usr/bin/plasmashell [2]: or scanning running processes ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, 2019-06-04 at 15:53 +0200, Florian Weimer wrote: > * Neal Gompa: > > > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote: > > > Is there a form of weak dependency which is installed when available, > > > but not automatically re-installed on each update? > > > > > > If all the optional components are back after an update, that means that > > > it's quite hard to maintain a minimal system installation. > > > > > > > This feature is not yet wired up in DNF. We have all the information > > we need to make those kinds of decisions, but it currently isn't > > accounted for. I discussed this with Daniel Mach at openSUSE > > Conference and he's aware that it's possible and some work could be > > done to support this depending on demand for the feature. > > Does it sense to reopen bug 1699672, in light of this development? As a side note, if your goal is "to maintain a minimal system installation", perhaps what you might want is to be able to configure dnf to simply *never* install weak (Recommends) or very weak (Suggests) dependencies. IIRC, this is configurable on SUSE - you can set this as permanent package manager configuration. I'm not sure if it is in DNF, but if not, perhaps it could be? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, Jun 4, 2019, 18:03 Adam Williamson wrote: > On Tue, 2019-06-04 at 15:53 +0200, Florian Weimer wrote: > > * Neal Gompa: > > > > > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer > wrote: > > > > Is there a form of weak dependency which is installed when available, > > > > but not automatically re-installed on each update? > > > > > > > > If all the optional components are back after an update, that means > that > > > > it's quite hard to maintain a minimal system installation. > > > > > > > > > > This feature is not yet wired up in DNF. We have all the information > > > we need to make those kinds of decisions, but it currently isn't > > > accounted for. I discussed this with Daniel Mach at openSUSE > > > Conference and he's aware that it's possible and some work could be > > > done to support this depending on demand for the feature. > > > > Does it sense to reopen bug 1699672, in light of this development? > > As a side note, if your goal is "to maintain a minimal system > installation", perhaps what you might want is to be able to configure > dnf to simply *never* install weak (Recommends) or very weak (Suggests) > dependencies. IIRC, this is configurable on SUSE - you can set this as > permanent package manager configuration. I'm not sure if it is in DNF, > but if not, perhaps it could be? > There is: --setopt=install_weak_deps=False Fabio -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, Jun 4, 2019 at 12:06 PM Fabio Valentini wrote: > > On Tue, Jun 4, 2019, 18:03 Adam Williamson wrote: >> >> On Tue, 2019-06-04 at 15:53 +0200, Florian Weimer wrote: >> > * Neal Gompa: >> > >> > > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote: >> > > > Is there a form of weak dependency which is installed when available, >> > > > but not automatically re-installed on each update? >> > > > >> > > > If all the optional components are back after an update, that means >> > > > that >> > > > it's quite hard to maintain a minimal system installation. >> > > > >> > > >> > > This feature is not yet wired up in DNF. We have all the information >> > > we need to make those kinds of decisions, but it currently isn't >> > > accounted for. I discussed this with Daniel Mach at openSUSE >> > > Conference and he's aware that it's possible and some work could be >> > > done to support this depending on demand for the feature. >> > >> > Does it sense to reopen bug 1699672, in light of this development? >> >> As a side note, if your goal is "to maintain a minimal system >> installation", perhaps what you might want is to be able to configure >> dnf to simply *never* install weak (Recommends) or very weak (Suggests) >> dependencies. IIRC, this is configurable on SUSE - you can set this as >> permanent package manager configuration. I'm not sure if it is in DNF, >> but if not, perhaps it could be? > > > There is: > > --setopt=install_weak_deps=False > The option can also be set in dnf.conf (--setopt= maps to options that you can set there. :) ) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
Germano Massullo skrev: >Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson > ha scritto: >> Have you confirmed that you're able to query another user's desktop session >> once >> you know which desktop it is? > >I cannot read XDG_CURRENT_DESKTOP of other users. I am actually >wondering if checking for specific executables [1] [2] would be the >best idea If you solve that problem, then as the next step you'll want to query the session: Is it active or idle? I'll be surprised if you can do that to another user's session without help from some privileged service. Björn Persson pgpmtxiBKKq1v.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
* Adam Williamson: > As a side note, if your goal is "to maintain a minimal system > installation", perhaps what you might want is to be able to configure > dnf to simply *never* install weak (Recommends) or very weak (Suggests) > dependencies. IIRC, this is configurable on SUSE - you can set this as > permanent package manager configuration. I'm not sure if it is in DNF, > but if not, perhaps it could be? My experience with Debian is that their --no-install-recommends feature is pretty aggressive, so you often end up manually chasing dependencies to get the required feature set if you disable the default of installing weak dependencies. So it's usually more convenient to install them automatically, and the remove select parts you don't want. YMMV, of course. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, 2019-06-04 at 19:06 +0200, Florian Weimer wrote: > * Adam Williamson: > > > As a side note, if your goal is "to maintain a minimal system > > installation", perhaps what you might want is to be able to configure > > dnf to simply *never* install weak (Recommends) or very weak (Suggests) > > dependencies. IIRC, this is configurable on SUSE - you can set this as > > permanent package manager configuration. I'm not sure if it is in DNF, > > but if not, perhaps it could be? > > My experience with Debian is that their --no-install-recommends feature > is pretty aggressive, so you often end up manually chasing dependencies > to get the required feature set if you disable the default of installing > weak dependencies. So it's usually more convenient to install them > automatically, and the remove select parts you don't want. YMMV, of > course. Well, I mean, the 'aggression' or otherwise is determined by the *packages*, not the package manager, surely? It's up to the individual packager where they draw the line between a Requires: and a Recommends:, so long as they abide by distro policy, which has a little to say about this but not a lot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190604.n.0 changes
OLD: Fedora-Rawhide-20190603.n.0 NEW: Fedora-Rawhide-20190604.n.0 = SUMMARY = Added images:7 Dropped images: 15 Added packages: 5 Dropped packages:9 Upgraded packages: 101 Downgraded packages: 0 Size of added packages: 21.81 MiB Size of dropped packages:9.99 MiB Size of upgraded packages: 2.60 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 154.76 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXDE live i386 Path: Spins/i386/iso/Fedora-LXDE-Live-i386-Rawhide-20190604.n.0.iso Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190604.n.0-sda.raw.xz Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20190604.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190604.n.0.s390x.tar.xz Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20190604.n.0-sda.raw.xz Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190604.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20190604.n.0.s390x.tar.xz = DROPPED IMAGES = Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190603.n.0.x86_64.vagrant-libvirt.box Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20190603.n.0.x86_64.tar.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190603.n.0.s390x.vmdk Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-Rawhide-20190603.n.0.iso Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190603.n.0.s390x.qcow2 Image: Mate live i386 Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-Rawhide-20190603.n.0.iso Image: Xfce live i386 Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20190603.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190603.n.0.s390x.raw.xz Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20190603.n.0.ppc64le.tar.xz Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20190603.n.0.iso Image: LXDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20190603.n.0-sda.raw.xz Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190603.n.0.x86_64.vagrant-virtualbox.box Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20190603.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20190603.n.0.iso Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20190603.n.0.iso = ADDED PACKAGES = Package: R-sodium-1.1-1.fc31 Summary: A Modern and Easy-to-Use Crypto Library RPMs:R-sodium Size:1.65 MiB Package: foliate-1.1.0-1.fc31 Summary: Simple and modern GTK eBook reader RPMs:foliate Size:370.13 KiB Package: httpd-2.4.39-4.module_f31+4477+190d928f Summary: Apache HTTP Server RPMs:httpd httpd-devel httpd-filesystem httpd-manual httpd-tools mod_ldap mod_md mod_proxy_html mod_session mod_ssl Size:14.44 MiB Package: mod_http2-1.15.1-1.module_f31+4477+190d928f Summary: module implementing HTTP/2 for Apache 2 RPMs:mod_http2 Size:903.61 KiB Package: nginx-1:1.17.0-1.module_f31+4491+eae5a6af Summary: A high performance web server and reverse proxy server RPMs:nginx nginx-all-modules nginx-filesystem nginx-mod-http-image-filter nginx-mod-http-perl nginx-mod-http-xslt-filter nginx-mod-mail nginx-mod-stream Size:4.47 MiB = DROPPED PACKAGES = Package: aeskulap-0.2.2-0.37.beta2.fc30 Summary: Full open source replacement for commercially available DICOM viewers RPMs:aeskulap aeskulap-doc Size:2.42 MiB Package: dvdbackup-0.4.2-12.fc30 Summary: Command line tool for ripping video DVDs RPMs:dvdbackup Size:355.95 KiB Package: emacs-pymacs-0.25-8.fc25 Summary: Emacs and Python integration framework RPMs:emacs-pymacs emacs-pymacs-el Size:311.97 KiB Package: gnome-dvb-daemon-0.2.91-0.12.20160917git2d32148.fc29 Summary: Digital Television manager RPMs:gnome-dvb-daemon Size:2.95 MiB Package: gnome-shell-extension-panel-osd-1-0.27.20180616giteb0d3c2.fc30 Summary: Configure the place where notifications are shown RPMs:gnome-shell-extension-panel-osd Size:35.36 KiB Package: python-fmn-2.1.1-3.fc30 Summary: A system for generic fedmsg-driven notifications for end users RPMs:python2-fmn Size:2.51 MiB Package: rubygem-chunky_png-1.2.7-3.fc21 Summary: Pure ruby library for read/write, chunk-level access to PNG files RPMs:rubygem-chunky_png Size:674.27 KiB Package: rubygem-compass-960-plugin-0.10.4
Re: Weak RPM dependencies which are not automatically re-installed on update
On 6/4/19 11:27 AM, Neal Gompa wrote: The option can also be set in dnf.conf (--setopt= maps to options that you can set there.:) ) This is one option, but it hides them entirely. I would like an option that still shows possible weak dependencies without installing them. Example: --setopt=install_weak_deps=False and --setopt=show_weak_deps=True ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190604.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 1 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 14/146 (x86_64), 1/2 (arm), 2/24 (i386) ID: 408902 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/408902 ID: 408919 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/408919 ID: 408924 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/408924 ID: 408943 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/408943 ID: 408945 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/408945 ID: 408955 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/408955 ID: 409005 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/409005 ID: 409009 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/409009 ID: 409010 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/409010 ID: 409011 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/409011 ID: 409012 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/409012 ID: 409014 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/409014 ID: 409017 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/409017 ID: 409020 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/409020 ID: 409028 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/409028 ID: 409035 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/409035 ID: 409045 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/409045 Soft failed openQA tests: 70/146 (x86_64), 18/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 408874 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/408874 ID: 408875 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/408875 ID: 408876 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/408876 ID: 408877 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/408877 ID: 408884 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/408884 ID: 408885 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/408885 ID: 408886 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/408886 ID: 408887 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/408887 ID: 408889 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/408889 ID: 408901 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/408901 ID: 408905 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/408905 ID: 408906 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/408906 ID: 408907 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/408907 ID: 408908 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/408908 ID: 408909 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/408909 ID: 408917 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/408917 ID: 408925 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/408925 ID: 408929 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/408929 ID: 408956 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/408956 ID: 408957 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/408957 ID: 408959 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/408959 ID: 408960 Test: x86_64 universal install_repository_http_graphical URL: ht
Re: Weak RPM dependencies which are not automatically re-installed on update
Miroslav Suchý wrote: > I would love to see "dnf mark" command to utilize for this. Something > like: dnf mark soft-remove I.e. remove the package and does not install it > again unless something pull it back using hard "Requires". Why would we require explicit marking? There is no technical reason to. Just implement the logic I described in: https://github.com/openSUSE/libsolv/issues/168#issuecomment-349738465 Requiring explicit marking would be no better than requiring an explicit excludes= in the dnf.conf, i.e., no real improvement over the current broken status quo. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
Florian Weimer wrote: > Does it sense to reopen bug 1699672, in light of this development? It would also make sense to get the upstream issue: https://github.com/openSUSE/libsolv/issues/168 reopened. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
On Tue, Jun 4, 2019 at 5:36 PM Kevin Kofler wrote: > > Florian Weimer wrote: > > Does it sense to reopen bug 1699672, in light of this development? > > It would also make sense to get the upstream issue: > https://github.com/openSUSE/libsolv/issues/168 > reopened. > That will not get reopened, because at the libsolv level, it won't know these things. We know this in DNF through the SWDB. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Jason L Tibbitts III wrote: > One problem is that I don't think anyone wants to see any quantifiable > regression in overall package size. Spins still struggle to fit within > fixed media sizes as the package set grows ever larger. The RPM compression method is pretty irrelevant to Spin sizes because Spins are typically live media and so use the live media's compression, not the RPM compression. All the RPMs are already unpacked and recompressed using the live media compression technology (currently xz). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weak RPM dependencies which are not automatically re-installed on update
Florian Weimer wrote: > Is there a form of weak dependency which is installed when available, > but not automatically re-installed on each update? The only workaround for that broken DNF behavior that packagers can in some cases use at this time is to use boolean Supplements instead of a simple Recommends or Supplements. E.g., if you have a package foo that has an optional subpackage foo-bar making use of a third package bar, it is often reasonable to change: foo Recommends: foo-bar or: foo-bar Supplements: foo to: foo-bar Supplements: (foo and bar) So you will get the subpackage dragged in only if you already have bar and so are likely to want foo to work together with it. This is particularly useful for desktop integration packages, e.g., the libyui-gtk and libyui-qt backends work this way. Another example is plasma-discover-flatpak, which Supplements: (plasma-discover and flatpak). But there are cases where there is no useful package bar to key on like that, so this workaround is not universally applicable. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Mon, Jun 3, 2019 at 7:01 PM Jason L Tibbitts III wrote: > > > "PM" == Panu Matilainen writes: > > PM> Note that rpm doesn't support parallel zstd compression, and while > PM> it does for xz, that's not even utilized in Fedora. > > Doing parallel xz compression has a surprising cost in compression ratio > which gets worse as the thread count increases (because it just splits > the input into independent blocks and compresses them separately). I > did start on a feature to have it enabled but then abandoned that after > realizing that it didn't really work as I'd hoped. Which is also why parallel xz compression doesn't produce reproducible results. > That said, I do wonder how difficult it would be to do parallel zstd > compression/decompression within RPM. If it were possible then that > might help to obviate some of the downsides. At least for small files, and there are many in any distribution, using a dictionary very well could improve compression/decompression time, compression ratio, more than threads. Adding dictionary support would help all the single thread hardware, and even the builders when zstd -T0 option dictates there's only 1 or 2 threads available. On the generic sample set, it's functionally like getting 4 threads on speed, and even compression ratio goes up by ~3x. But I have no idea how that sample set compares to Fedora's files. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
