Re: Vanilla builds guideline?

Hi Kevin, On Tuesday 01 November 2011 18:23:25 Kevin Kofler wrote: > IMHO, that would be unhelpful, unneccessary and unsupportable. thank you for expressing your concerns. > You already mention that there are patches which need to be applied for the > package to build/work at all. For the vast

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 wro

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 vulnerabi

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 Ma

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 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 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 m

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 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: 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 bu

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: 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: 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 it

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_

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 director

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 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 not reach > >

review swap: cscppc, cswrap

Hi, is anyone willing to review or swap reviews of the following packages? * cscppc - A compiler wrapper that runs cppcheck in background, available at * cswrap - Generic compiler wrapper, available at Basic info and mo

Re: review swap: cscppc, cswrap

Hi Mukundan, On Friday, March 07, 2014 09:29:09 nonamedotc wrote: > I have taken cswrap for review. I will take cscppc also after > finishing cswrap. thank you very much for taking the reviews! Kamil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/lis

Re: systemd 230 change - KillUserProcesses defaults to yes

On Thursday, June 02, 2016 13:04:44 Lennart Poettering wrote: > On Wed, 01.06.16 07:20, Adam Williamson (adamw...@fedoraproject.org) wrote: > > On Wed, 2016-06-01 at 15:48 +0200, Lennart Poettering wrote: > > > Any scheme that relies on unprivileged programs "being nice" doesn't > > > fix the inher

Re: Why GUI software update tool is broken for me

On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote: > Dne 15.6.2016 v 10:14 Ade napsal(a): > > Why is this? Well some time ago the behaviour of the tool changed and now > > the only way to proceed is to click in "Restart and Install" and this is > > NEVER what I want to do. I never want to

Re: OpenSSL 1.1.0 in Rawhide very soon

On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote: > Hi all, > > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will > be also 1.0.2 compat package (compat-openssl10) so the dependencies are > not broken and Rawhide should be installable. Also things that do not > depend on o

Re: Static Analysis: proposed interchange format ("firehose")

On Wednesday, January 16, 2013 15:53:56 David Malcolm wrote: > This is a followup to my proposal in > http://lists.fedoraproject.org/pipermail/devel/2012-December/175232.html > > I want a common output format for static analysis tools so that we can > easily slurp the results from different tools

Re: Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

On Friday, January 18, 2013 23:35:24 Lennart Poettering wrote: > On Fri, 18.01.13 22:49, Andreas Tunek (andreas.tu...@gmail.com) wrote: > > I think you have a good point, but adding every imaginable featw into > > glibc > > is not really a good solution. Maybe glib is a better place for these > > k

Re: Static Analysis: results of FUDcon Lawrence hackfest

On Thursday, January 24, 2013 14:11:11 Jerry James wrote: > It is not, but see http://jjames.fedorapeople.org/blast/ for an > experimental RPM. If we could get the Vampyre developers to remove > "for research purposes only" from their license, we could get both > Vampyre and BLAST into Fedora. >

Re: Static Analysis: results of FUDcon Lawrence hackfest

On Friday, January 25, 2013 09:07:22 Richard W.M. Jones wrote: > On Thu, Jan 24, 2013 at 02:11:11PM -0700, Jerry James wrote: > > Note that we also have why and why3 in Fedora, by the way. > > .. and ocaml-cil. CIL can be used as a front-end for a static analysis tool or a C preprocessor for sta

Re: Static Analysis: results of FUDcon Lawrence hackfest

On Friday 25 January 2013 16:01:15 Jerry James wrote: > On Fri, Jan 25, 2013 at 5:16 AM, Kamil Dudka wrote: > > On Thursday, January 24, 2013 14:11:11 Jerry James wrote: > >> It is not, but see http://jjames.fedorapeople.org/blast/ for an > >> experimental RPM.

Re: Static Analysis: results of FUDcon Lawrence hackfest

On Friday, January 25, 2013 18:17:09 Richard W.M. Jones wrote: > On Fri, Jan 25, 2013 at 10:35:29AM -0500, David Malcolm wrote: > > As Kamil points out elsewhere in this thread, what we need are automated > > tools that can run on code and emit warnings, without needing human > > intervention. > >

Re: Proposed F19 Feature: Yum Groups as Objects

On Monday 28 January 2013 13:58:56 Jaroslav Reznik wrote: > = Features/YumGroupsAsObjects = > https://fedoraproject.org/wiki/Features/YumGroupsAsObjects > > Feature owner(s): James Antill > > Change the default yum configuration from group_command=compat to > group_command=objects. I have been

Re: Proposed F19 Feature: Yum Groups as Objects

On Monday, January 28, 2013 10:26:01 Bruno Wolff III wrote: > On Mon, Jan 28, 2013 at 16:52:18 +0100, > > Kamil Dudka wrote: > >I have been always wondering why yum needs a special set of commands to > >manipulate groups of packages. What would be the downside of using

Re: Proposed F19 Feature: Yum Groups as Objects

On Monday, January 28, 2013 11:58:00 Kevin Fenzi wrote: > On Mon, 28 Jan 2013 19:49:50 +0100 > > Kamil Dudka wrote: > > On Monday, January 28, 2013 10:26:01 Bruno Wolff III wrote: > > > On Mon, Jan 28, 2013 at 16:52:18 +0100, > > > > > >Kam

Re: Proposed F19 Feature: Yum Groups as Objects

On Monday, January 28, 2013 17:42:16 James Antill wrote: > On Mon, 2013-01-28 at 13:53 -0500, Casey Dahlin wrote: > > On Mon, Jan 28, 2013 at 10:26:01AM -0600, Bruno Wolff III wrote: > > > On Mon, Jan 28, 2013 at 16:52:18 +0100, > > > > > > Kamil Dud

Re: Static Analysis: some UI ideas

On Monday, February 04, 2013 15:04:36 David Malcolm wrote: > I've been experimenting with some UI ideas for reporting static analysis > results: I've linked to two different UI reports below. > > My hope is that we'll have a server in the Fedora infrastructure for > browsing results, marking thing

Re: Static Analysis: some UI ideas

On Monday 04 February 2013 22:37:45 David Malcolm wrote: > Content-addressed storage: they're named by SHA-1 sum of their contents, > similar to how git does it, so if the bulk of the files don't change, > they have the same SHA-1 sum and are only stored once. See e.g.: > http://fedorapeople.org/~

Re: Static Analysis: some UI ideas

On Tuesday, February 05, 2013 11:57:51 David Malcolm wrote: > Interesting. I had thought that git purely stored compressed files and > eschewed the idea of deltas, but it does indeed store deltas sometimes: > http://git-scm.com/book/ch9-4.html The delta compression is used e.g. anytime you transf

Re: Orphaning PycURL

On Friday, February 22, 2013 12:02:47 Jeffrey Ollie wrote: > The final straw is that the package failed to build in the latest mass > rebuild: > > https://bugzilla.redhat.com/show_bug.cgi?id=914411 Thanks for heads up! This is a bug in the latest upstream release of libcurl. I will apply the ups

Re: Orphaning PycURL

On Friday, February 22, 2013 14:54:04 Jeffrey Ollie wrote: > On Fri, Feb 22, 2013 at 2:33 PM, Jon Ciesla wrote: > > Excellent! Jeffrey, will you be picking python-pycurl up again, then? > > No. While this was an easy fix that was actually in another package, > PycURL has other problems. I thin

Re: Provenpackagers dealing with -Werror=format-security issues

On Friday, March 17, 2017 14:36:25 Stephen Gallagher wrote: > There was an issue[1] with GCC7 during the mass-rebuild. Despite the > Fedora-wide setting of -Werror=format-security, GCC did not process its > command-line properly and an unknown number of packages were built without > this flag appro

Re: Provenpackagers dealing with -Werror=format-security issues

On Sunday, March 19, 2017 15:09:59 Tomasz Kłoczko wrote: > gcc can now load some extensions as DSOs and maybe it would be possible to > use this entry point to start thinking about develop extension which would > allow store formated data about types and locations of warning in some text > file per

Re: Provenpackagers dealing with -Werror=format-security issues

On Wednesday, March 29, 2017 12:09:14 Tomasz Kloczko wrote: > What I'm trying to tell is that as long > as suppressing such warnings is hard coded in spec files it > decreases probability of fixing the code. Because you are trying to use wrong tools to capture compiler warnings from Fedora packag

switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

In order to make even smaller Fedora base images, it was proposed to switch libcurl back to OpenSSL. The Fedora Crypto Consolidation project, which motivated the switch of libcurl from OpenSSL to NSS ten years ago, is now deprecated and libcurl is the only package that pulls NSS as its dependency

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Wednesday, April 05, 2017 10:33:11 Stephen Gallagher wrote: > On 04/05/2017 09:59 AM, Colin Walters wrote: > > On Wed, Apr 5, 2017, at 09:52 AM, Kamil Dudka wrote: > >> In order to make even smaller Fedora base images, it was proposed to > >> switch > >>

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Wednesday, April 05, 2017 11:38:35 Colin Walters wrote: > On Wed, Apr 5, 2017, at 11:28 AM, Kamil Dudka wrote: > > Anyway, do not overestimate the power of HTTP/2. It will not > > transparently > > bring you better transfers for free. You can speak HTTP/2 even while &

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

gt; On Wed, Apr 5, 2017, at 09:52 AM, Kamil Dudka wrote: > >>> In order to make even smaller Fedora base images, it was proposed to > >>> switch > >>> libcurl back to OpenSSL. The Fedora Crypto Consolidation project, which > >>> motivated the sw

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Wednesday, April 05, 2017 18:28:53 Dusty Mabe wrote: > On 04/05/2017 12:17 PM, Kamil Dudka wrote: > > On Wednesday, April 05, 2017 11:38:35 Colin Walters wrote: > >> libostree does that - > >> https://github.com/ostreedev/ostree/blob/c937305c0e7f5609273e25753912c

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Thursday, April 06, 2017 15:00:31 Jan Kurik wrote: > On Thu, Apr 6, 2017 at 2:49 PM, Kamil Dudka wrote: > > On Wednesday, April 05, 2017 17:09:34 Jan Kurik wrote: > >> Might not be directly related, but just for a reference - one of the > >> F26 Changes (currently de

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Thursday, April 06, 2017 16:05:16 Jan Kurik wrote: > On Thu, Apr 6, 2017 at 3:47 PM, Stephen Gallagher wrote: > > On 04/06/2017 09:12 AM, Kamil Dudka wrote: > >> On Thursday, April 06, 2017 15:00:31 Jan Kurik wrote: > >>> On Thu, Apr 6, 2017 at 2:49 PM, Kamil Dud

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Thursday, April 06, 2017 18:39:26 Kai Engert wrote: > On Thu, 2017-04-06 at 09:29 -0700, Adam Williamson wrote: > > On Thu, 2017-04-06 at 18:22 +0200, Kai Engert wrote: > > > I would like to make you aware that the certificate validation of > > > openssl > > > isn't > > > as complete as in NSS.

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Friday, April 07, 2017 11:01:35 Kai Engert wrote: > On Fri, 2017-04-07 at 10:38 +0200, Kamil Dudka wrote: > > Although we build libcurl against NSS now, it loads the same CA bundle as > > if we built it against OpenSSL: > > > > /etc/pki/tls/certs/ca-bundle.crt &

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Friday, April 07, 2017 13:34:42 Kai Engert wrote: > On Fri, 2017-04-07 at 11:54 +0200, Kamil Dudka wrote: > > On Friday, April 07, 2017 11:01:35 Kai Engert wrote: > > > On Fri, 2017-04-07 at 10:38 +0200, Kamil Dudka wrote: > > > > Although we build libcurl against

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Friday, April 07, 2017 13:45:48 Kamil Dudka wrote: > On Friday, April 07, 2017 13:34:42 Kai Engert wrote: > > On Fri, 2017-04-07 at 11:54 +0200, Kamil Dudka wrote: > > > On Friday, April 07, 2017 11:01:35 Kai Engert wrote: > > > > On Fri, 2017-04-07 at

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Friday, April 07, 2017 18:46:33 Kai Engert wrote: > You convinced me, that it would be good to have test cases to demonstrate > how nss/openssl/gnutls are behaving related to the distrust rules. > > I setup the following page, wich provides multiple test cases, and > intructions how to test: >

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Friday, April 07, 2017 18:46:33 Kai Engert wrote: > You convinced me, that it would be good to have test cases to demonstrate > how nss/openssl/gnutls are behaving related to the distrust rules. > > I setup the following page, wich provides multiple test cases, and > intructions how to test: >

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

On Thursday, April 13, 2017 10:45:13 David Woodhouse wrote: > On Mon, 2017-04-10 at 15:52 +0200, Kai Engert wrote: > > On Mon, 2017-04-10 at 15:31 +0200, Kamil Dudka wrote: > > > Anyway, I guess we should move this discussion to some curl- or > > > nss-related chann

Does anybody use JavaSript (ECMAScript) support in ELinks?

The JavaScript (ECMAScript) support in ELinks uses a legacy implementation of the interpreter (mozjs-1.8.5). Several bugs of the legacy interpreter breaking ELinks had to be debugged recently: https://bugzilla.redhat.com/1177557 https://bugzilla.redhat.com/1425004 https://bugzilla.re

Re: Does anybody use JavaSript (ECMAScript) support in ELinks?

On Friday, April 28, 2017 09:01:48 Matthew Miller wrote: > S, I'm not actively using it daily, but I occasionally do (and did > more when I was an active sysadmin). A lot of websites don't work at > all without javascript, and it's nice to have a text mode option in a > pinch. Could you please

Re: coreutils /bin file dependencies

On Friday, June 23, 2017 10:57:11 Mark Wielaard wrote: > On Fri, 2017-06-23 at 10:11 +0200, Igor Gnatenko wrote: > > > On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: > > > > > On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: > > > > > > > For the record, there appear to be only 25

Re: F27 System Wide Change: Graphical Applications as Flatpaks

On Monday, July 17, 2017 11:53:35 Daniel P. Berrange wrote: > I had this kind of fun problem upgrading F25 -> F26. I was lazy and didn't > want to reboot so I was just running dnf distro-sync in a gnome-terminal > session. I've upgrade this way since F6 and mostly it just works, but > forgot to no

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday, March 17, 2016 14:44:21 Przemek Klosowski wrote: > On 03/17/2016 02:00 PM, Kamil Dudka wrote: > > On Thursday 17 March 2016 13:21:42 Przemek Klosowski wrote: > >> Could you summarize the argument against something like > >> > >> libcurl_versio

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday, March 16, 2016 15:11:07 Yaakov Selkowitz wrote: > On 2016-03-16 14:07, Kamil Dudka wrote: > > On Wednesday, March 16, 2016 20:28:16 Ville Skyttä wrote: > >>> http://pkgs.fedoraproject.org/cgit/rpms/curl.git/log/?h=private-kdu > >>>

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday 16 March 2016 17:25:26 Bill Nottingham wrote: > Kamil Dudka (kdu...@redhat.com) said: > > On Wednesday, March 16, 2016 16:19:23 Bill Nottingham wrote: > > > Kamil Dudka (kdu...@redhat.com) said: > > > > Are you reading it from the specfile?

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday, March 17, 2016 19:27:09 Richard W.M. Jones wrote: > On Thu, Mar 17, 2016 at 07:00:09PM +0100, Kamil Dudka wrote: > > On Thursday 17 March 2016 13:21:42 Przemek Klosowski wrote: > > I was (by mistake) speaking about loading libcurl's run-time dependencies >

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday, March 16, 2016 15:48:54 Dennis Gilmore wrote: > On Wednesday, March 16, 2016 9:39:33 PM CDT Kamil Dudka wrote: > > On Wednesday, March 16, 2016 16:19:23 Bill Nottingham wrote: > > > Kamil Dudka (kdu...@redhat.com) said: > > > > Are yo

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday 17 March 2016 10:21:33 Alexander Bokovoy wrote: > On Thu, 17 Mar 2016, Kamil Dudka wrote: > >On Thursday 17 March 2016 08:57:19 Alexander Bokovoy wrote: > >> On Wed, 16 Mar 2016, Dennis Gilmore wrote: > >> >On Wednesday, March 16, 2016 9:39:33 PM CDT

introducing curl-minimal and libcurl-minimal RPM packages

The curl and libcurl packages, which are both required by dnf, have a lot of run-time dependencies. I propose to maintain curl-minimal and libcurl-minimal subpackages obtained from a conservatively configured build of curl, resulting in a significant reduction of their run-time dependencies. T

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday, March 16, 2016 16:19:23 Bill Nottingham wrote: > Kamil Dudka (kdu...@redhat.com) said: > > Are you reading it from the specfile? > > > > It is just an implementation detail of the packaging (the > > RemovePathPostfixes feature of rpm). The string you me

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Friday 18 March 2016 08:29:27 Petr Pisar wrote: > On 2016-03-18, Kamil Dudka wrote: > > On Thursday, March 17, 2016 14:44:21 Przemek Klosowski wrote: > > > > According to Fedora Packaging Guidelines, unversioned shared library files > > should be installed by -dev

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Friday 18 March 2016 05:14:28 Nico Kadel-Garcia wrote: > On Fri, Mar 18, 2016 at 4:29 AM, Petr Pisar wrote: > > I think the solution is have more packages delivering the same-named > > shared library file with the same soname. Each of the packages > > conflicting each other. Then the non-minima

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday, March 16, 2016 20:28:16 Ville Skyttä wrote: > > http://pkgs.fedoraproject.org/cgit/rpms/curl.git/log/?h=private-kdudka > > -libcurl-minimal > libcurl.so.x.y.z.minimal looks pretty weird to me, and wrong as well > because it stuffs "minimal" into the version part, but the minim

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday 17 March 2016 08:14:42 Dennis Gilmore wrote: > On Thursday, March 17, 2016 07:12:01 AM Kamil Dudka wrote: > > On Wednesday, March 16, 2016 17:07:39 Dennis Gilmore wrote: > > > On Wednesday, March 16, 2016 09:52:36 PM Kamil Dudka wrote: > > > > On Wedn

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday 17 March 2016 08:57:19 Alexander Bokovoy wrote: > On Wed, 16 Mar 2016, Dennis Gilmore wrote: > >On Wednesday, March 16, 2016 9:39:33 PM CDT Kamil Dudka wrote: > >> On Wednesday, March 16, 2016 16:19:23 Bill Nottingham wrote: > >> > Kamil Dudka (kdu...@redh

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday 17 March 2016 11:55:31 Bill Nottingham wrote: > Kamil Dudka (kdu...@redhat.com) said: > > > If you care about a consistent developer, user, and debugging experience > > > regardless of mechanism of delivery, you wouldn't do this in the first > > > pla

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday, March 16, 2016 17:07:39 Dennis Gilmore wrote: > On Wednesday, March 16, 2016 09:52:36 PM Kamil Dudka wrote: > > On Wednesday, March 16, 2016 15:48:54 Dennis Gilmore wrote: > > > On Wednesday, March 16, 2016 9:39:33 PM CDT Kamil Dudka wrote: > > > > On W

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Wednesday, March 16, 2016 17:20:38 Przemek Klosowski wrote: > On 03/16/2016 04:39 PM, Kamil Dudka wrote: > > ldconfig will always pick /usr/lib64/libcurl.so.4 because there can be > > only one file with that name installed at a time. > > OK, but how do you determine wh

Re: introducing curl-minimal and libcurl-minimal RPM packages

On Thursday 17 March 2016 13:21:42 Przemek Klosowski wrote: > On 03/17/2016 12:54 PM, Kamil Dudka wrote: > > I am also open to discuss other solution to the above problem. The other > > proposals I have captured in this thread are: > > > > - use dlopen() -- already

Re: Koji builders' specs

On Sunday, December 25, 2016 13:13:31 Pádraig Brady wrote: > On 22/12/16 13:13, Pádraig Brady wrote: > > On 21/12/16 16:04, Dan Horák wrote: > >> On Tue, 20 Dec 2016 16:03:49 +0100 > >> > >> Pavel Raiskup wrote: > >>> Hi all, > >>> > >>> where is documented what system/hw is used on (primary) Ko

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 su

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 ma

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: 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 rem

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 on

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: 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 -- devel@

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 pack

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: 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: 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 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: 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 st

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. Bei

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 and

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: 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. > -

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 log fil

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 so

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 selected

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: 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 wh

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. > >> > >>

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: nbdkit-ext2-plugin-1.7.3-1.fc30.

  1   2   >