Re: rpmbuild is very slow with large files

On Tuesday, July 12, 2022 12:52:13 AM CEST Marius Schwarz wrote: > > Hi, > > I have just create(d/ not finished yet, started 15 minutes ago) a ~2.5 > GB rpm and found, that rpmbuild is an extrem bottleneck. > > IMHO, this is caused by a fileread function which reads files in 32k > blocks,

Re: [RFC] Build tag in RPM: from NVR to NVRB

On Wednesday, June 22, 2022 7:45:09 PM CEST Kevin Fenzi wrote: > On Wed, Jun 22, 2022 at 11:09:13AM -, Michael J Gruber wrote: > > > I also think that every package change (including rebuild) must be > > > tracked in changelog. > > > > I think that convolution is at the very heart of the

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

On Thursday, April 7, 2022 3:45:45 PM CEST Stephen Gallagher wrote: > > Sorry for keeping asking naive questions, but is there a chance to do > > some mass rebuild prior this lands, to asses the impact? Better to avoid > > (complete?) breakage of ELN and give change to fix the (most > >

Re: cmake failure to build in rawhide?

On Friday, April 1, 2022 5:45:38 PM CEST Hans de Goede wrote: > Hi All, > > While fixing a hedgewars F36 bug, the f37/rawhide build of the > fixed pkg is failing: > > In both F36 and F37 the invocation is: > > /usr/bin/cmake -S . -B redhat-linux-build > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG >

Re: dist-git force push

On Friday, April 1, 2022 4:26:36 PM CEST Robbie Harwood wrote: > Kamil Dudka writes: > > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > >> - check whether the "new object name" is descendant of > >> (contains) "old build object n

Re: dist-git force push

On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > Hi there > > I know why we do not allow to force push to dist-git in the rpms namespace, You can easily do force pushes in your own fork. Rewriting the authoritative branches in the official repositories is problematic for too

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Wednesday, March 16, 2022 1:06:34 PM CET Neal Gompa wrote: > > For completeness, here is a pull request by Miro Hrončok to change the > > packaging of curl to something that FESCO would like to have for the > > proposed Fedora change to be accepted: > > > > > > > >

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Wednesday, March 16, 2022 10:01:10 AM CET Paul Howarth wrote: > On Tue, 22 Feb 2022 12:00:06 -0500 > Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default > > > > == Summary == > > `libcurl-minimal` and `curl-minimal` will be installed by default > >

Re: Problem with cmake 3.23.0

On Monday, March 14, 2022 10:22:19 PM CET Thomas Rodgers wrote: > These are the CMake related issues I've encountered thus far - > > FlightCrew: FTBFS # CMake Error: The source directory > "/builddir/build/BUILD/FlightCrew-0.9.1/build" does not appear to contain > CMakeLists.txt. > csdiff:

Re: Problem with cmake 3.23.0

On Tuesday, March 15, 2022 12:18:02 AM CET Neal Gompa wrote: > I bent over backwards to get the macros working all the way back to EPEL 7. > > I updated the cmake3 package in EPEL 7[1] and I got RHEL to update > CMake[2] and sync the macros from Fedora[3] for RHEL 8. > > The only difference for

Re: Problem with cmake 3.23.0

On Tuesday, March 8, 2022 12:13:33 AM CET Sérgio Basto wrote: > I advise anyone to carefully read the wiki page. If you mean the Fedora 33 change page, it only describes the change from Fedora 33+ perspective. It does not take compatibility with EPEL buildroots into account at all. Kamil

Re: Problem with cmake 3.23.0

On Friday, March 4, 2022 4:17:01 PM CET Sérgio Basto wrote: > I think you missed the > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds When the change landed, I had to fix all my packages to build although they had been using out of source builds since the beginning.

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Thursday, March 3, 2022 10:49:07 PM CET Richard W.M. Jones wrote: > (1) I don't deny that curl-minimal will reduce the size of some niche > containers, my point is this is not a worthwhile goal to pursue given > the costs. I am pretty sure there are Fedora installations not based on containers

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Thursday, March 3, 2022 3:24:38 PM CET Richard W.M. Jones wrote: > On Thu, Mar 03, 2022 at 09:04:10AM +0100, Kamil Dudka wrote: > > The FTP protocol is still included in libcurl-minimal, so the protocol is > > not going to disappear with the proposed F37 change. On the other &

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Thursday, March 3, 2022 7:07:34 AM CET Ralf Corsépius wrote: > Am 24.02.22 um 19:35 schrieb Daniel P. Berrangé: > > > On Thu, Feb 24, 2022 at 07:16:26PM +0100, Ralf Corsépius wrote: > > > > > If someone is setting up a personal private mirror, I struggle > > to understand a reason why they

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Thursday, February 24, 2022 3:37:56 PM CET Neal Gompa wrote: > On Thu, Feb 24, 2022 at 8:58 AM Richard W.M. Jones wrote: > > On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote: > > > On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote: >

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Thursday, February 24, 2022 2:58:10 PM CET Richard W.M. Jones wrote: > On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote: > > On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote: > > > Did you discuss modularising curl itself upstream? >

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote: > Did you discuss modularising curl itself upstream? It was added to their wish list but I do not remember anybody working on it: https://github.com/curl/curl/commit/8204844f > That would be a better idea. Not

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Wednesday, February 23, 2022 7:01:26 PM CET Björn Persson wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > According to ICANN [1], there were 8.3 mln IDN domains worldwide. > > And that's presumably only second-level domains. Nobody knows how many > non-ASCII subdomains exist under ASCII

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote: > Dear Kamil, > > On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka wrote: > > On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote: > > > Once upon a time, Zbigniew Jędrzejewski-Szmek said: &

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > > Yes. But how many domains using idn are there? I worked on idn support > > in systemd, but when preparing the description of this change I realized > > that I have _never_

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Tuesday, February 22, 2022 9:45:30 PM CET Peter Robinson wrote: > On Tue, Feb 22, 2022 at 5:00 PM Ben Cotton wrote: > > > > > > > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default > > > > > > > > == Summary == > > `libcurl-minimal` and `curl-minimal` will be installed by default >

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

On Tuesday, February 22, 2022 10:47:40 PM CET Chris Adams wrote: > Once upon a time, Demi Marie Obenour said: > > > As mentioned above, the purpose of this change is to ensure that > > vulnerabilities in obscure protocols impact a smaller fraction of > > users. Right now, a vulnerability in an

Re: cmake on Rawhide is broken

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: > Hello all. > > Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with > libcrypto.so.1.1 and fails: > > + /usr/bin/cmake -S . -B redhat-linux-build > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG >

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote: > On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote: > > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote: > > > On 12/2/21 15:08, Sérgio Basto wrote: > > > > I didn't understood . What i

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote: > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote: > > > On 12/2/21 15:08, Sérgio Basto wrote: > > > > > I didn't understood . What is the difference for /lib64/ld-2.33.so > > > or > > > /lib/ld-2.33.so ? > > > > > > >

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

On Thursday, December 2, 2021 7:38:29 PM CET Florian Weimer wrote: > I'd like to provide an ld.so command as part of glibc. Today, ld.so can > be used to activate preloading, for example. Compared to LD_PRELOAD, > the difference is that it's specific to one process, and won't be > inherited by

Re: Automated formal verification of RPM packages

On Monday, November 8, 2021 7:10:45 PM CET Jerry James wrote: > Nice! Thanks for working on this. I tried to use the csmock plugin, > but got this at the end of the build (on an x86_64 F34 host, building > for fedora-35-x86_64): > > + for file in >

Automated formal verification of RPM packages

Formal verification of RPM packages with CBMC, Divine, and Symbiotic is now easier than ever before! csmock plug-ins for these tools are now available in stable Fedora releases. The plug-ins are still experimental and they have some technical limitations: - They work only for source RPM

Re: Fedora 35 security update of curl blocked for a month

On Thursday, November 4, 2021 2:07:53 AM CET Adam Williamson wrote: > On Wed, 2021-11-03 at 09:38 -0700, Adam Williamson wrote: > > > and that its > > > > > > subject nor the body contained any information besides the (currently > > > valid) URL to some JSON data. > > > > I don't recall exactly

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 6:32:34 PM CET Adam Williamson wrote: > 4. The email notifications should be customizable via > https://apps.fedoraproject.org/notifications/ , I believe. I do agree > it would be good if we could tweak some defaults in the notification > code to not notify you when

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 8:30:15 PM CET Adam Williamson wrote: > Further to this: I did re-run the tests, they did pass, it did make > Bodhi happy, and I successfully submitted the update to stable. It > should get pushed in the next push, I hope. > > It looks like what happened is that Bodhi

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 4:19:23 PM CET Kalev Lember wrote: > My understanding is that the test that failed and is blocking the push to > stable is the openQA test. When I discussed a similar issue that a GNOME > megaupdate ran into with adamw a few weeks ago, he said that the way to >

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 3:37:03 PM CET Fabio Valentini wrote: > Maybe multiple people attempting to waive test results and re-triggering > tests while things are still pending is not a good idea? > > It looks like the re-triggered tests failed again, after the tests had been > waived,

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 3:10:47 PM CET Mattia Verga via devel wrote: > It appears that the tests are now waived, so you can push the update to > stable as usual. > > Mattia I wish I could but it is unfortunately sill not the case: $ bodhi updates request FEDORA-2021-1d24845e93 stable

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 2:17:28 PM CET Kamil Dudka wrote: > On Tuesday, November 2, 2021 1:58:02 PM CET Miro Hrončok wrote: > > On 02. 11. 21 8:47, Kamil Dudka wrote: > > > On September 22 I submitted a Fedora 35 update of curl, which obsoleted > > > a previousl

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 1:58:02 PM CET Miro Hrončok wrote: > On 02. 11. 21 8:47, Kamil Dudka wrote: > > On September 22 I submitted a Fedora 35 update of curl, which obsoleted > > a previously submitted security update of curl. The update has reached > > karma

Re: Fedora 35 security update of curl blocked for a month

On Tuesday, November 2, 2021 9:14:31 AM CET Peter Robinson wrote: > On Tue, Nov 2, 2021 at 7:48 AM Kamil Dudka wrote: > > > > > > > On September 22 I submitted a Fedora 35 update of curl, which obsoleted > > a previously submitted security update of curl. The up

Fedora 35 security update of curl blocked for a month

On September 22 I submitted a Fedora 35 update of curl, which obsoleted a previously submitted security update of curl. The update has reached karma +13 since then, yet I was unable to make Bodhi push the update to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1d24845e93 I

Re: libcurl-minimal

On Saturday, October 16, 2021 5:32:17 PM CEST Richard W.M. Jones wrote: > On Thu, Oct 14, 2021 at 09:52:59AM +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi Kamil and everyone, > > > > what is the plan with introduction of libcurl-minimal in Fedora? > > IIUC, libcurl and libcurl-minimal both

Re: libcurl-minimal

On Sunday, October 17, 2021 2:40:05 PM CEST Steven Grubb wrote: > On Sat, Oct 16, 2021 at 10:08 PM Kevin Kofler via devel < > > devel@lists.fedoraproject.org> wrote: > > Steve Grubb wrote: > > > I'd like to suggest making libcurl-minimal very minimal for security > > > reasons. The main curl

Re: libcurl-minimal

On Friday, October 15, 2021 12:47:44 PM CEST Mark Wielaard wrote: > Hi, > > On Thu, 2021-10-14 at 16:49 +0200, Kamil Dudka wrote: > > > As I understand it, Zbyszek is now proposing to make changes to other > > packages and/or distribution metadata in order to make > &

Re: libcurl-minimal

On Thursday, October 14, 2021 3:27:03 PM CEST Steve Grubb wrote: > Hello, > > On Thursday, October 14, 2021 6:51:54 AM EDT Kamil Dudka wrote: > > > what is the plan with introduction of libcurl-minimal in Fedora? > > > > I proposed to use libcurl-minimal and curl-

Re: libcurl-minimal

Hi Zbyszek, On Thursday, October 14, 2021 11:52:59 AM CEST Zbigniew Jędrzejewski-Szmek wrote: > Hi Kamil and everyone, > > what is the plan with introduction of libcurl-minimal in Fedora? I proposed to use libcurl-minimal and curl-minimal in minimal base images half a year ago but there has

Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)

On Monday, October 4, 2021 2:24:22 PM CEST Miro Hrončok wrote: > On 04. 10. 21 14:16, Kamil Dudka wrote: > > On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote: > >> Some results from a Rawhide podman container: > >> > >> # koji download-buil

Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)

On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote: > Some results from a Rawhide podman container: > > # koji download-build --arch x86_64 coreutils-9.0-1.fc36 > # dnf install coreutils-common-9.0-1.fc36.x86_64.rpm > coreutils-9.0-1.fc36.x86_64.rpm # git clone >

Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)

On Monday, October 4, 2021 11:57:14 AM CEST Miro Hrončok wrote: > Hello, > > I see this failure in dnf in Copr and Koji: > > https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ > https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401 > > Executing(%prep): /bin/sh -e

Re: Proposal to deprecated `fedpkg local`

On Thursday, January 28, 2021 7:55:05 PM CET Vít Ondruch wrote: > Dne 28. 01. 21 v 19:36 Simo Sorce napsal(a): > > On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote: > >> Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): > >>> Vít Ondruch writes: > Thx everybody for their responses and

Re: Deprecating SCP

On Monday, November 2, 2020 6:31:33 PM CET Florian Weimer wrote: > * Kamil Dudka: > > On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote: > >> * Kamil Dudka: > >> > As far as I know, (lib)curl has never silently transformed a protocol > >>

Re: Deprecating SCP

On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote: > * Kamil Dudka: > > > > As far as I know, (lib)curl has never silently transformed a protocol > > scheme explicitly specified with URL. This can be discussed upstream > > but I do not feel like sta

Re: Deprecating SCP

On Monday, November 2, 2020 4:47:47 PM CET Simo Sorce wrote: > On Mon, 2020-11-02 at 16:36 +0100, Kamil Dudka wrote: > > How is the "compatibility scpd to support old clients" going to differ > > from the current implementation? > > > > libcurl impl

Re: Deprecating SCP

On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote: > Hi Fedora users! > > Over the last years, there were several issues in the SCP protocol, > which lead us into discussions if we can get rid of it in upstream [1]. > Most of the voices there said that they use SCP mostly for simple

Re: Error creating the package RPM: make:*** No rule to make target 'install'.

On Thursday, October 1, 2020 11:50:02 AM CEST Helg Green via devel wrote: > %build > cd app > make %{?_smp_mflags} > > %install I guess that `cd app` is missing here? Kamil > mkdir -p %{buildroot} > make install INSTALL_ROOT=%{buildroot} > > %post > # Setup icons > touch -c

Re: [ELN] need a working build of systemtap for a rebuild of qemu

On Wednesday, September 23, 2020 1:09:37 PM CEST Aleksandra Fedorova wrote: > Thanks for the heads-up. There was a CI cluster downtime yesterday and > the build was impacted by it. I restarted it, and it passed > > https://osci-jenkins-1.ci.fedoraproject.org/job/eln-build-pipeline/17459/ > > The

[ELN] need a working build of systemtap for a rebuild of qemu

The latest eln build of systemtap fails to install, which prevents qemu from being built: https://bugzilla.redhat.com/1881342 The maintainer of systemtap says that it is the eln rebuild what went wrong. So he created a new rawhide build in the hope that it will trigger a new eln build,

Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

On Tuesday, July 21, 2020 4:02:29 PM CEST Neal Gompa wrote: > On Tue, Jul 21, 2020 at 9:51 AM Kamil Dudka wrote: > > What exactly do you mean by "work"? If the option does not take any > > effect, that is perfectly fine because the Fedora change did

Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

On Tuesday, July 21, 2020 3:41:02 PM CEST Neal Gompa wrote: > On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka wrote: > > On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote: > > > That's odd, it shouldn't work, > > > > I believe it does. > > > > >

Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote: > That's odd, it shouldn't work, I believe it does. > since -B wasn't introduced until CMake 3.13... You only need working -B option to override a previously specified -B option. Otherwise CMake defaults to the current working

Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

On Monday, July 20, 2020 9:23:46 PM CEST Dominik 'Rathann' Mierzejewski wrote: > On Monday, 20 July 2020 at 20:46, Kamil Dudka wrote: > > > On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote: > > > > > Or you could just use "%global __cmake_in_sou

Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote: > Or you could just use "%global __cmake_in_source_build 1" which > reverts to the previous behavior. That does not make any sense. The packages I talk about have used out of source builds since forever. > Or you could *actually* make

Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

On Monday, July 20, 2020 7:37:25 PM CEST Neal Gompa wrote: > This is because ceph is not adapted yet for > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds Yes, this change broke a lot of builds as it had been discussed on this list. > Your spec file is a complete mess, so

Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via devel wrote: > If there is buy-in, it will be implemented by goodwill people. If there > is no buy-in, it won’t, normal community development process. Put > yourself in the category you want to be in, your choice, not mine. I believe

Re: out of Koji disk space

On Wednesday, July 1, 2020 2:00:09 PM CEST Jan Kratochvil wrote: > On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote: > > > In the end we have limited resources and you are running into those > > limits. We can either have fewer builders with more disk space and a > > long queue of

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wednesday, July 1, 2020 10:54:46 AM CEST Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 01, 2020 at 09:44:12AM +0200, Kamil Dudka wrote: > > > On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote: > > > > > May I suggest another option? > >

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote: > May I suggest another option? > I provide a package for Micro, an editor written in Go with a discoverable > interface. https://micro-editor.github.io/ > > It is compiled as a static binary of 4.6 MB with no dependency. How

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Friday, June 26, 2020 3:55:01 PM CEST Peter Robinson wrote: > > -1 for the change. If the so called 'end-user' (whatever does it mean) > > can learn git, she or he can also learn 'vi' or at least how to enable > > the preferred editor. Personally, I can see nothing special on the > > nano, for

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Friday, June 26, 2020 12:07:46 PM CEST Ian McInerney wrote: > On Fri, Jun 26, 2020 at 10:49 AM Kamil Dudka wrote: > > On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote: > > > On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka wrote: > > > > ...snip... >

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote: > On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka wrote: > > ...snip... > > > > Gentoo Linux uses the /etc/env.d tree to globally set environment > > > > variables: > > https://devmanual

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Thursday, June 25, 2020 10:27:06 PM CEST Michael Catanzaro wrote: > On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney > wrote: > > > Are you sure this will work? I just ran a test, and putting a new > > config file inside /usr/lib/environment.d only works for Gnome, and > > doesn't work for

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

On Saturday, June 20, 2020 12:17:26 AM CEST Tomasz Kłoczko wrote: > All parallel build issues should be treated *as critical bugs* > which should be *ASAP fixed*. > > kloczek Seriously, are you saying that bugs causing slower build are as important as bugs causing data lost or security

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

On Tuesday, June 16, 2020 12:18:29 PM CEST Kevin Kofler wrote: > Igor Raits wrote: > > > Not sure if I follow, what means "can already be done with the existing > > one"? Does it mean that you can already specify a build dir via CLI and > > some packages already do (e.g. libsolv)? > > > As I

Re: Is dist-git a good place for work?

On Wednesday, May 6, 2020 4:35:11 PM CEST Vít Ondruch wrote: > I am not concerned about remote branches disappearing. I am concerned > about the complete opposite, when the remote branches appearing in my > local copy and not disappearing once the remote copies go. Isn't this exactly what `git

Re: Non-responsive maintainer: mruprich (Michal Ruprich)

On Thursday, April 23, 2020 4:08:24 PM CEST Robbie Harwood wrote: > That's not how this works. Yes and I am trying to suggest you how to make it work. > Even if your assertion were true (which it isn't), we have a closure > status for that. Michal (the maintainer, who isn't you) even used it -

Re: Non-responsive maintainer: mruprich (Michal Ruprich)

On Wednesday, April 22, 2020 7:28:36 PM CEST Robbie Harwood wrote: > To make this as clear as I can, let's look at > https://bugzilla.redhat.com/show_bug.cgi?id=1815163 The above mentioned ticket is not a bug report in the first place. You just expressed your personal opinion about a package

Re: fedpkg broken (pycurl issue?)

On Monday, April 20, 2020 3:59:59 PM CEST Neal Becker wrote: > Maybe the problem is that my local pycurl is not compatible with fedpkg? The more important problem is that your local pycurl is not compatible with libcurl, which is exactly what the error message is telling you, isn't it? I would

Re: Should logrotate timer be enabled by default on all installations?

On Wednesday, March 18, 2020 3:50:34 PM CET Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 18, 2020 at 01:04:58PM +0100, Kamil Dudka wrote: > > > logrotate is a utility designed to simplify the administration of log > > files on a system which generates a lot of l

Re: Should logrotate timer be enabled by default on all installations?

On Wednesday, March 18, 2020 3:20:17 PM CET Dusty Mabe wrote: > I guess it would be worth analyzing the problem space a bit: > > - in the past how many people do we think had logrotate installed and not > cron? I am worried more about automated provisioning rather than manual installations. >

Should logrotate timer be enabled by default on all installations?

logrotate is a utility designed to simplify the administration of log files on a system which generates a lot of log files. It used to be triggered by cron. The cron hook was unconditionally installed with logrotate but it took effect only if a cron daemon was installed. Starting with Fedora

Re: Mock build Fedora package on CentOS 7

On Thursday, January 16, 2020 6:12:42 AM CET Nico Kadel-Garcia wrote: > On Wed, Jan 15, 2020 at 12:08 PM Ian Pilcher wrote: > There are notes in the "mock" buglists > at:https://github.com/rpm-software-management/mock/issues/390 . The > short answer is "not very well". The dnf tools in RHEL 7

Re: dnf autoremove by default on upgrades

On Monday, January 13, 2020 4:07:56 PM CET Chris Murphy wrote: > I understand the path of least resistance with upgrades. They're > better off being upgraded, even if they silently have sale bits no > longer upgraded. From a security perspective, I think being silent > about that is not great.

Re: dnf autoremove by default on upgrades

On Monday, January 13, 2020 5:59:49 AM CET Chris Murphy wrote: > On Sun, Jan 12, 2020 at 9:39 PM Kevin Fenzi wrote: > > > > > > > On Sun, Jan 12, 2020 at 07:15:39PM -0700, Chris Murphy wrote: > > > > > Hi, > > > > > > > > > > > > This might be a bad idea. But I'm looking for better ideas than

Re: Bugzilla needinfo reminders

On Friday, October 25, 2019 11:02:00 AM CEST Tomasz Torcz wrote: > On Fri, Oct 25, 2019 at 09:30:39AM +0200, Kamil Dudka wrote: > > > On Friday, October 25, 2019 9:11:39 AM CEST Tomasz Torcz wrote: > > > > > Hi, > > > > > > > > > Few days

Re: Bugzilla needinfo reminders

On Friday, October 25, 2019 9:11:39 AM CEST Tomasz Torcz wrote: > Hi, > > Few days ago (22nd Oct) I've started receiving daily reminders > about needinfo for over a year old bugs. Which is strange, as those bugs > are closed. Bugzilla sends you notifications because the needinfo flag is set

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

On Friday, August 30, 2019 8:44:39 AM CEST Miroslav Suchý wrote: > I think that no one contemplate supporting RHEL 7 regarding zstd. Panu said that the backport would be almost trivial: https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/message/Z4EFFNJNVAP35KH74N3W5GC4E2AQXC7V/

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

On Thursday, August 29, 2019 11:17:18 PM CEST Nico Kadel-Garcia wrote: > Sent from my iPhone > > > > On Aug 29, 2019, at 12:58 PM, Kamil Dudka wrote: > > > > > >> On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote: > >> > >>&g

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote: > 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): > >>> >

Re: RANT: compton-ng…

On Tuesday, August 13, 2019 12:22:17 PM CEST Panu Matilainen wrote: > On 8/13/19 1:19 PM, Kamil Dudka wrote: > > > On Tuesday, August 13, 2019 11:26:12 AM CEST Panu Matilainen wrote: > > > >> On 8/13/19 11:17 AM, Igor Gnatenko wrote: > >> > >> > &

Re: RANT: compton-ng…

On Tuesday, August 13, 2019 11:26:12 AM CEST Panu Matilainen wrote: > On 8/13/19 11:17 AM, Igor Gnatenko wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1738293 > > > > How did it pass review? > > > > > >> Obsoletes: compton > > > > > > Silently doing Obsoletes of an active

Re: Mock - signal reaction

On Tuesday, July 30, 2019 4:59:13 PM CEST Jan Buchmaier wrote: > Do we want to catch/process SIGABRT as well? I see no obvious use case for catching SIGABRT by mock. Why are you asking about SIGABRT specifically? Kamil ___ devel mailing list --

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

Re: Mock - signal reaction

On Monday, June 3, 2019 12:18:02 PM CEST Jan Buchmaier wrote: > 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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Friday, March 22, 2019 12:25:28 PM CET Vitaly Zaitsev wrote: > Hello, Kamil Dudka. > > Fri, 22 Mar 2019 12:03:26 +0100 you wrote: > > > > Enforcing -Werror=format-security in Fedora build system was a mistake. > > > No. Enforcing -Werror=format-securi

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Friday, March 22, 2019 10:41:23 AM CET Jakub Jelinek wrote: > If we in Fedora made -Werror=format-security warning default, then > one couldn't out of box build gcc nor many other projects. Not to mention > that it is extremely nasty, because if e.g. some project uses -Wno-format > for

Re: Fedora Lifecycles: imagine longer-term possibilities

On Thursday, December 6, 2018 3:48:32 PM CET Petr Pisar wrote: > On 2018-12-06, Florian Weimer wrote: > > > In a sense, it's the old discussion between explicit rename recording > > and rename detection. I think it's clear by now that rename detection > > has won. > > > > > > Can you give us

Re: koji download-build fails with [ERROR] koji: PermissionError: [Errno 13] Permission denied

On Wednesday, September 19, 2018 11:27:04 AM CEST Richard W.M. Jones wrote: > I don't know if this is a problem with this specific version of koji, > or our Koji builders, but: > > $ koji download-build nbdkit-1.7.3-1.fc30 --arch=x86_64 --arch=noarch > Downloading:

Re: F29 System Wide Change: OpenLDAP without Non-threaded Libraries

On Tuesday, July 17, 2018 2:24:04 PM CEST Matus Honek wrote: > Florian is right, the idea is to make changes to the source code > (probably a downstream patch will be needed) such that the threaded > library will be built twice, once with libldap soname and once with > libldap_r soname, and the

Re: [HEADS UP] Removal of GCC from the buildroot

On Tuesday, July 10, 2018 5:44:50 PM CEST Kevin Kofler wrote: > Igor Gnatenko wrote: > > > As per Changes/Remove GCC from BuildRoot > > , I'm > > going to automatically add BuildRequires: gcc and/or BuildRequires: > > gcc-c++ to

backward incompatible ABI change in libnice after rebuild against updated gstreamer1

gstreamer1 was updated to version 1.14.0 in f28 on March 21st: https://koji.fedoraproject.org/koji/buildinfo?buildID=1060701 .. but not all its dependencies were rebuilt. While trying to update the libnice package now, libabigail tells me that my update is backward- incompatible because the

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Thursday, May 3, 2018 12:10:25 AM CEST Iain Rae wrote: > no, I'm afraid you're misunderstanding. if someone steals a laptop the > live user session can be more valuable than the root password. with > the live session you have access to everything the owner of the sesion > is logged into. with

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Wednesday, May 2, 2018 4:34:51 PM CEST Stephen John Smoogen wrote: > The issue is where they do not know they have installed software to > their home directory. Sure but still better than if they did not know they had installed software outside of their home directory, at least from

  1   2   >