Re: systemd-243-rc1

2019-08-01 Thread Nicolas Mailhot via devel
Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit : > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote: > > > Since these things are both the case, a simple 1:1 mapping from "-" > > to > > "~" (and even back) is exactly correct. > > So I think the systemd.spec is

Re: [Test-Announce] Fedora 31 Beta Freeze

2019-09-02 Thread Nicolas Mailhot via devel
Le 2019-08-31 10:44, Zbigniew Jędrzejewski-Szmek a écrit : (I asked a few people what 24:00 means to them, and after getting a few strange looks and answers, To be fair: 1. ISO 8501 allows writing 24:00 Wikipedia> Midnight is a special case and may be referred to as either "00:00" or "24:00

Re: [Test-Announce] Fedora 31 Beta Freeze

2019-09-03 Thread Nicolas Mailhot via devel
Le 2019-09-02 19:27, Kevin Kofler a écrit : Nicolas Mailhot via devel wrote: 2. However the IETF explicitely forbid it when defining the ISO 8501 subset allowed on the Internet RFC 3339> Although ISO 8601 permits the hour to be "24", this profile of ISO RFC 3339> 8601 on

Re: Fedora Workstation and disabled by default firewall

2019-09-04 Thread Nicolas Mailhot via devel
Le 2019-09-03 18:52, Kyle Marek a écrit : Additionally, binding to a specific address does not handle dynamic networks very well. Simplify that to binding to a specific address does not handle network very well, since everything is dynamic nowadays, on desktops, phones or servers (servers vi

Re: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)

2019-09-13 Thread Nicolas Mailhot via devel
Le 2019-09-13 00:05, Kevin Kofler a écrit : Marius Schwarz wrote: (in short: no update to 2.00.5-3 was possible via dnf, as packages refer to 2.00.3-1 directly) They don't actually refer to liberation-fonts-2.00.3-1, but to liberation- narrow-fonts, which liberation-fonts-2.00.3-1 claims to

Re: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)

2019-09-13 Thread Nicolas Mailhot via devel
Le 2019-09-13 10:39, Kevin Kofler a écrit : Nicolas Mailhot via devel wrote: The correct thing would have been never to create a narrow liberation subpackage in the first place since narrow is just a face of a font (like bold). In theory, in an ideal world, that makes sense. But in practice

Re: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)

2019-09-13 Thread Nicolas Mailhot via devel
Le vendredi 13 septembre 2019 à 12:18 +0200, Kevin Kofler a écrit : > Nicolas Mailhot via devel wrote: > > That's an historical artefact, that made sense when everyone used > > the > > same dozen font on windows, and when each and everyone of them > > could

Re: Let's talk about Fedora in the '20s!

2020-01-06 Thread Nicolas Mailhot via devel
Le 2020-01-06 18:19, Matthew Miller a écrit : Hi, Second, we need to figure out how to work with language-native packaging formats and more directly with code that's distributed in git repos rather than as tarball releases. We're not adding meaningful end-user value by manually repackaging t

Re: Let's talk about Fedora in the '20s!

2020-01-06 Thread Nicolas Mailhot via devel
Le 2020-01-06 19:05, Nicolas Mailhot a écrit : Handling those checks is where the packaging toil is (that is, as long as Fedora is a deployment project). It is not something the packaging format makes harder. However, because our packaging format streamlines those checks, and forces to apply

Re: Let's talk about Fedora in the '20s!

2020-01-07 Thread Nicolas Mailhot via devel
Le mardi 07 janvier 2020 à 14:06 +0100, Fabio Valentini a écrit : > > Conclusion: Some things could and should be improved Yes, there are lots of shades of gray. All recent package managers allow downloading stuff for use (or they'd have no users). Some manage to build things. Some manage deps.

Re: Let's talk about Fedora in the '20s!

2020-01-07 Thread Nicolas Mailhot via devel
Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit : > > I'm far from having a satisfactory response to that, but I see two > fronts here. First, marketing. How does Ubuntu managed to be so > popular among less-experienced Linux users? I'm not sure, but I > suspect that good marketing has

Re: Let's talk about Fedora in the '20s!

2020-01-07 Thread Nicolas Mailhot via devel
Le mardi 07 janvier 2020 à 18:37 +0100, Clement Verna a écrit : > > > On Tue, Jan 7, 2020, 18:21 Nicolas Mailhot via devel < > devel@lists.fedoraproject.org> wrote: > > Le mardi 07 janvier 2020 à 17:14 +0100, Iñaki Ucar a écrit : > > > > > > I'm

Re: Lagging system with latest kernels

2020-01-09 Thread Nicolas Mailhot via devel
Le 2020-01-09 15:02, Stephen John Smoogen a écrit : I have seen something like this happen in the past. I think it was around Fedora 18? kernel time frame.. on certain Lenovo T440? if you did a dd to a usb key, keyboard and mouse would be like you pointed out. I get this all the time, with or

Re: Fedora 32 Self-Contained Change proposal: Provide OpenType Bitmap Fonts

2020-01-09 Thread Nicolas Mailhot via devel
Le jeudi 09 janvier 2020 à 12:16 -0500, Ben Cotton a écrit : > > == Detailed Description == > In Fedora 31, pango has been upgraded to 1.44, and switched to use > the HarfBuzz library instead of FreeType. > > But HarfBuzz doesn't support bitmap fonts or Adobe Type 1 fonts. > In gnome-terminal, t

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-10 Thread Nicolas Mailhot via devel
Le vendredi 10 janvier 2020 à 17:36 +0100, Pierre-Yves Chibon a écrit : > Good Morning Everyone, > > This is not a new idea, it has been presented at flock last year and > spoken > about on this very list this fall, so I'd like to push it a little > further. > > Do we want to drop release and cha

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-10 Thread Nicolas Mailhot via devel
Le vendredi 10 janvier 2020 à 20:53 +0100, Fabio Valentini a écrit : > > You can never expect our tooling to do "magic" (TM) and work "just > right", no matter which Versions and Releases and Epochs of packages > are available from third-party repos and coprs. Yes, sure, but the current way we m

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-12 Thread Nicolas Mailhot via devel
Le samedi 11 janvier 2020 à 13:09 -0500, Neal Gompa a écrit : > > The only reason I mentioned it is because since we distro-sync > between > releases, it doesn't actually matter as much as it used to. rawhide does not distro-sync (and some may say that rawhide does not matter, but early problem d

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-13 Thread Nicolas Mailhot via devel
Le 2020-01-13 11:01, Panu Matilainen a écrit : You keep saying that, but maybe you were not involved with redhat-rpm-config back when it was that way. It was the most hideous piece of package I had ever worked with, because the model of external tarballs is just absurd and does not work at all w

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-13 Thread Nicolas Mailhot via devel
Le 2020-01-13 11:28, Miroslav Suchý a écrit : Dne 13. 01. 20 v 10:46 Petr Pisar napsal(a): No, it won't as we have competing %{version}-%{release} strings among multiple packages. E.g. perl source bundles an Encode module. And we know the module is updated frequenly on CPAN. Thus we build perl-

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-13 Thread Nicolas Mailhot via devel
Le 2020-01-13 12:07, Pierre-Yves Chibon a écrit : Hi, I don't quite see how it conflicts with it either. You may end up having foo-1.0-42 in copr and foo-1.0-32 in koji which would lead to a foo-1.0-32 (or -39) at the next build, but I'm not seeing how it's a problem per say. Correct handl

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-13 Thread Nicolas Mailhot via devel
Le 2020-01-13 12:52, Florian Weimer a écrit : I have trouble matching this claim to my experience working on redhat-rpm-config. Why is it painful to use Git as it was designed? Because redhat-rpm-config is not "using Git as it was designed". It’s using git as a centralized flat and linear SC

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-13 Thread Nicolas Mailhot via devel
Le 2020-01-13 16:20, Randy Barlow a écrit : Now, we could change the policy too to get around this, but I think "git tag" is a natural way for me to indicate "I want to build and release this commit to this Fedora release". Please do not try to infer packaged commit from src.fedoraproject.org

Re: RFC: Python minimization in Fedora

2020-01-16 Thread Nicolas Mailhot via devel
Le 2020-01-16 11:18, Felix Schwarz a écrit : Am 15.01.20 um 23:11 schrieb Victor Stinner: This solution is well supported by unmodified Python: it's part of the default sys.path search path: $ python3 Python 3.7.6 (default, Dec 19 2019, 22:52:49) import sys; sys.path ['', '/usr/lib64/python37

Re: RFC: Python minimization in Fedora

2020-01-16 Thread Nicolas Mailhot via devel
Le 2020-01-16 15:10, Felix Schwarz a écrit : Am 16.01.20 um 13:37 schrieb Nicolas Mailhot via devel: If we start messing with the Python tree it would be nice to put each shared python component in a separate zip/xz/whatever, and allow versioning those archives (ie use the highest semver zip

Re: RFC: Python minimization in Fedora

2020-01-16 Thread Nicolas Mailhot via devel
Le jeudi 16 janvier 2020 à 22:00 +0100, Felix Schwarz a écrit : > > If I understood Nicolas correctly this was about installing multiple > versions > of the same *library* in the global Python site-packages directory? Whatever you wish to call it :) The non stdlib parts projects do not seem to ag

Re: Alternative buildroot as a development tool

2020-01-17 Thread Nicolas Mailhot via devel
Le jeudi 16 janvier 2020 à 22:24 -0500, Neal Gompa a écrit : Hi Neal, > I've also said that I don't think we can handle it as our > infrastructure currently stands. Our build system tooling has > suffered from a decade of neglect, and attempts to reinvent or > improve that have been rebuffed or f

Re: Effort to remove libdb

2020-01-17 Thread Nicolas Mailhot via devel
Le jeudi 16 janvier 2020 à 20:52 -0700, Jerry James a écrit : > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia > wrote: > > The lack of a good backup tool for Berkeley DB earned me nearly a > > year > > of contracting salary from the BBC to keep alive an obsolete > > Berkeley > > DB and Apache

Re: Java Dev Group and Fedora Quality

2020-01-26 Thread Nicolas Mailhot via devel
Le dimanche 26 janvier 2020 à 00:10 +, Bill Chatfield via devel a écrit : > That's a very sad story. I had no idea. So it sounds like you mainly > need maintainers for Java packages. I have worked on building RPMs > but I have never been a package maintainer. However I have 20 years > of experi

Re: Java Dev Group and Fedora Quality

2020-01-26 Thread Nicolas Mailhot via devel
Le dimanche 26 janvier 2020 à 05:25 +, Bill Chatfield via devel a écrit : > And if the Gnome guys actually had information like this, they'd be > forced to deal with it. Forcing people does not work that well in real life, and even less in free software circles where participation is voluntar

Re: Java Dev Group and Fedora Quality

2020-01-26 Thread Nicolas Mailhot via devel
Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit : > On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote: > > > Java has been in a terminal course in Fedora for a year at > > least. You can see how much Red Hat Java leadership cares about the > > situation b

Re: Java Dev Group and Fedora Quality

2020-01-27 Thread Nicolas Mailhot via devel
Le 2020-01-27 10:52, Andrew Haley a écrit : You would not expect a GCC devroom to be concerned about the problems of all packages written in C and C++, so why would Java be any different? I would expect a GCC devroom to be concerned about the problems of all packages written in C and C++ once

Re: Java Dev Group and Fedora Quality

2020-01-27 Thread Nicolas Mailhot via devel
Le 2020-01-27 15:13, Mario Torre a écrit : On Sun, Jan 26, 2020 at 12:53 PM Nicolas Mailhot via devel wrote: Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit : > On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote: > > > Java has been in a terminal course in Fedor

Re: Java Dev Group and Fedora Quality

2020-01-27 Thread Nicolas Mailhot via devel
Le 2020-01-27 15:46, Mario Torre a écrit : You keep ignoring that a large part of the packaged ecosystem comes from different places and is maintained by different people, That’s why coordination conferences like the FOSDEM exist. and not everything is in a state of chaos as you imply Othe

Re: Git Forge Requirements: Please see the Community Blog

2020-01-29 Thread Nicolas Mailhot via devel
Le mardi 21 janvier 2020 à 16:34 +, Leigh Griffin a écrit : Hi, > On behalf of the CPE team I want to draw the communities attention to > a recent blog post which you may be impacted by: > https://communityblog.fedoraproject.org/git-forge-requirements/ Requirements: 1. the url to the archi

Re: Change proposal discussion - Optimize SquashFS Size

2020-02-03 Thread Nicolas Mailhot via devel
Le 2020-02-03 17:11, David Cantrell a écrit : Hi, We want input from the community on what the main goal should be and prioritize the rest. For example, is ISO reduction size more important than improving installation time, for instance? If so, why? This is a nonsensical question without

Re: Change proposal discussion - Optimize SquashFS Size

2020-02-03 Thread Nicolas Mailhot via devel
(and before someone says "it’s about the iso not the packages", iso files get downloaded too) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of

Re: Package uses Gradle (retired) to build: what to do?

2020-02-09 Thread Nicolas Mailhot via devel
Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > What does it tell? To me, it says that FOSS platforms don't care > about > Java as much as they used to. We're clearly able to do stuff with Go > and Rust, which are just as "anti-distribution" as Java is (based on > what other peop

Re: deduplicating noarch subpackages

2020-02-12 Thread Nicolas Mailhot via devel
Le 2020-02-12 01:21, Josh Stone a écrit : The problem is that those cross-target libraries built by two different host arches will have different metadata hashes in the filenames, because the hash includes the full "rustc -Vv" version output, including the host triple. koji is doing the righ

Re: deduplicating noarch subpackages

2020-02-13 Thread Nicolas Mailhot via devel
Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit : > > It's not so black and white. In theory, the only thing that should > matter is the target triple, but the metadata also hashes the > metadata > of all its build dependencies. That in turn may include procedural > macros (essentially

Re: deduplicating noarch subpackages

2020-02-13 Thread Nicolas Mailhot via devel
Le jeudi 13 février 2020 à 12:00 -0800, Josh Stone a écrit : > On 2/13/20 11:26 AM, Nicolas Mailhot wrote: > > Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit : > > > > > It is so black and white. If you can not produce bit-perfect > > identical > > builds, don’t try to make the result

Re: Fonts packaging policy rewrite proposal

2020-02-14 Thread Nicolas Mailhot via devel
Le mardi 12 novembre 2019 à 09:00 +0100, Nicolas Mailhot a écrit : > A fonts packaging policy rewrite proposal has been pushed to FPC > today: > https://pagure.io/packaging-committee/pull-request/934 > > It should be clearer, more opinionated, and take into account: > – updates of The OpenType s

Re: Include non-RPM content in buildroot

2020-02-21 Thread Nicolas Mailhot via devel
Le vendredi 21 février 2020 à 15:57 +0100, Martin Sehnoutka a écrit : > Hi, Hi, > Go went even further in this case and it is > common > to bundle all the dependencies as a source code directly in the > upstream > repository. See this repo as an example: > https://github.com/containers/libpod/

Re: Qt, GNOME, and fonts

2020-02-22 Thread Nicolas Mailhot via devel
Le lundi 17 février 2020 à 16:08 -0700, Jerry James a écrit : Hi, > I am trying to track down a font problem with MuseScore: > > https://bugzilla.redhat.com/show_bug.cgi?id=1790829 > > The problem is that everything is displayed in Cantarell, no matter > which font the user actually selects. I

Re: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC

2020-02-23 Thread Nicolas Mailhot via devel
Le dimanche 23 février 2020 à 14:26 +0100, Jakub Kadlcik a écrit : Thanks to all the people that worked on this! > I would like to happily announce, that the migration was successful > and the outage is finally over. Everything should work as expected. unfortunately, things are not stable yet

Re: Schedule for Mondays's FESCo Meeting (2020-02-24)

2020-02-24 Thread Nicolas Mailhot via devel
Le 2020-02-24 13:37, Petr Šabata a écrit : Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. Hi, Can you please add https://pagure.io/fesco/issue/2344 to the list since FESCO arbitration was requested withi

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-24 Thread Nicolas Mailhot via devel
Le lundi 24 février 2020 à 18:13 +0100, Miro Hrončok a écrit : > On 24. 02. 20 17:48, Pierre-Yves Chibon wrote: > > However, for the release field, we are struggling a little bit > > more, two options > > are more appealing to us: > > Can we please have a "git is the only source of truth" version

Re: Cross-arch dependencies for plugins (NSS and others)

2020-02-24 Thread Nicolas Mailhot via devel
Le lundi 24 février 2020 à 22:51 +0100, Florian Weimer a écrit : > > Recommends: isn't a hard dependency? It’s a weak but not weak weak dependency :) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an ema

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-25 Thread Nicolas Mailhot via devel
Le 2020-02-25 10:24, Pierre-Yves Chibon a écrit : If you make the build system provide the ${dirty_appendix} and drop the ${pivot} (because we want to generate the release, so there is no input specified), you get very close to what we described. BTW, regardless of how things up, we have exi

Re: New font package

2020-02-26 Thread Nicolas Mailhot via devel
Le 2020-02-26 08:51, Iñaki Ucar a écrit : Hi, Welcome ! I've submitted a new font package for review [1], but I have 0 experience with fonts (I need it to unbundle it from [2]), and I found the documentation about font packages a little bit outdated. It's a pretty simple font (OFL, single fam

Re: Include non-RPM content in buildroot

2020-02-26 Thread Nicolas Mailhot via devel
Le 2020-02-26 09:50, Martin Sehnoutka a écrit : Hi, Hi, Go package management: I know that Go has a package management now, but the question is if upstream communities are going to adopt it. Upstream communities won’t have any choice if they want their software to be trusted by third partie

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-26 Thread Nicolas Mailhot via devel
Le 2020-02-26 11:14, Nils Philippsen a écrit : Well, if we officially were to break with the upgrade path constraints, we'd have to document this. While we're at it, we should then document that Rawhide users should use "dnf distro-sync". That won’t work because (for example) rawhide is pullin

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-26 Thread Nicolas Mailhot via devel
Le mercredi 26 février 2020 à 23:07 -0500, Neal Gompa a écrit : > > You don't use Release for upstream versioning, even for snapshots. > For > your examples: > > * 0-0.1.beta.2 -> 0~beta.2-1 > * 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a- Sorry but no You are attempting to redefine the m

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-27 Thread Nicolas Mailhot via devel
Le 2020-02-27 08:35, Nicolas Mailhot via devel a écrit : Le mercredi 26 février 2020 à 23:07 -0500, Neal Gompa a écrit : You don't use Release for upstream versioning, even for snapshots. For your examples: * 0-0.1.beta.2 -> 0~beta.2-1 * 0-0.1.20120225gitd6c789a -> 0~git20120

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-27 Thread Nicolas Mailhot via devel
Le 2020-02-27 09:52, Miro Hrončok a écrit : On 27. 02. 20 9:20, Pierre-Yves Chibon wrote: How would that work with "complex" releases? For example release containing prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package have no version, so depend heavily on the Release tag

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-27 Thread Nicolas Mailhot via devel
Le 2020-02-27 12:59, clime a écrit : Hi, can you, please, show an example of such package? I was searching through some golang packages because I was curious how it works but couldn't find an example A Go example: https://src.fedoraproject.org/rpms/golang-x-build A non-Go example: https://

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-27 Thread Nicolas Mailhot via devel
Le jeudi 27 février 2020 à 17:38 +0100, clime a écrit : > On Thu, 27 Feb 2020 at 16:26, Nicolas Mailhot via devel > wrote: > > Le 2020-02-27 12:59, clime a écrit : > > Hi, > > > > > can you, please, show an example of such package? I was searching > > >

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Hi, Anyway, here is what I would personnaly consider a robust, inclusive, and future-proof design: — a %{use_dynstate} rpm variable enables dynamic changelog/release behaviour — probably initialy set to false distro-wide, to let volunteers test the thing by setting it to true iin their specs,

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Le samedi 29 février 2020 à 14:28 +0100, clime a écrit : > > Does ENVR without %{dist} means something with respect to the content > from > which the package was built or with respect to features that it > offers for the given distribution version? You need to evaluate evr with a neutral dist val

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Le samedi 29 février 2020 à 13:49 +0100, clime a écrit : > On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel > wrote: > > Hi, > > > > Anyway, here is what I would personnaly consider a robust, > > inclusive, > > and future-proof design: > > I

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Le samedi 29 février 2020 à 15:12 +0100, clime a écrit : > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel > wrote: > > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit : > > > Does ENVR without %{dist} means something with respect to the > > > cont

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Le samedi 29 février 2020 à 16:11 +0100, Nicolas Mailhot a écrit : > > Build-time state changes need to be commited back, of course > (otherwise the produced srpm needs to be re-imported manually) Probably, only on *successful* production build however. We don’t need to record failed or scratch b

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Le samedi 29 février 2020 à 20:30 +0100, clime a écrit : > > What about fedpkg local and fedpkg verrel then? Putting %{dynrel} reconciliation in the rpmbuild -bs stage using detached file state means that fedpkg local (or checking out git state and building in mock or copr or OBS or via plain rp

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-02-29 Thread Nicolas Mailhot via devel
Le samedi 29 février 2020 à 20:57 +0100, clime a écrit : > On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel > wrote: > > Le samedi 29 février 2020 à 15:12 +0100, clime a écrit : > > > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel > > > wrote: >

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-03-02 Thread Nicolas Mailhot via devel
Le 2020-03-01 02:31, clime a écrit : On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel wrote: Le samedi 29 février 2020 à 20:30 +0100, clime a écrit : Putting %{dynrel} reconciliation in the rpmbuild -bs stage using detached file state means that fedpkg local (or checking out git

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-03-03 Thread Nicolas Mailhot via devel
Le 2020-03-02 14:45, clime a écrit : On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel wrote: Le 2020-03-01 02:31, clime a écrit : > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel > wrote: >> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit : &

Re: Ideas and proposal for removing changelog and release fields from spec file

2020-03-03 Thread Nicolas Mailhot via devel
Le 2020-03-03 07:03, clime a écrit : Actually, that wouldn't work because prefix needs to be static, not dependent on rpm macros For myself, I would oppose any rpm release process that would not take core rpm mecanisms like macros into account. Recording builds in changelogs without checkin

Re: [Fedora-packaging] Re: Ideas and proposal for removing changelog and release fields from spec file

2020-03-03 Thread Nicolas Mailhot via devel
Le 2020-03-03 15:14, clime a écrit : On Tue, 3 Mar 2020 at 09:22, Nicolas Mailhot wrote: Le 2020-03-02 14:45, clime a écrit : > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel > wrote: >> >> Le 2020-03-01 02:31, clime a écrit : >> > On Sat, 29 Feb 2020 at

Re: Donate 1 minute of your time to test upgrades from F31 to F32

2020-03-06 Thread Nicolas Mailhot via devel
BTW my local servlet, which is on F33, lost automounting of lvm on mdraid home Makes systemd unit crazy, it forgets about user units, and refuses to acknowledge them even after /home is remounted manually. (this may or may not be the same thing, F32 & 33 have not diverged too far yet) -- Nicola

[HEADS UP] Fonts packaging guidelines change status

2020-03-07 Thread Nicolas Mailhot via devel
Hi all, WHAT IS IT ALL ABOUT On 2020-02-13, FPC approved a rewrite of our fonts packaging guidelines. The previous guidelines were more than a decade old, technically outdated, relying on packages dropped from Fedora, and badly damaged during wiki to asciidoc migration. The new guidelines took

Re: Reducing broken dependencies in fedora (32) repositories

2020-03-09 Thread Nicolas Mailhot via devel
Le lundi 09 mars 2020 à 12:11 -0500, Bruno Wolff III a écrit : > On Mon, Mar 09, 2020 at 18:11:32 +0100, > Fabio Valentini wrote: > > On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III > > wrote: > > > > I'm also not sure how you would detect that from the package > > metadata > > ... query all pa

Re: Change in perl-devel dependencies

2020-03-10 Thread Nicolas Mailhot via devel
FYI it also broke DejaVu fonts, I had to patch the spec in F33 -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedorapr

Re: Change in perl-devel dependencies

2020-03-10 Thread Nicolas Mailhot via devel
Le 2020-03-10 08:15, Nicolas Mailhot a écrit : FYI it also broke DejaVu fonts, I had to patch the spec in F33 https://bugzilla.redhat.com/show_bug.cgi?id=1811741 -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: [HEADS UP] Fonts packaging guidelines change status

2020-03-14 Thread Nicolas Mailhot via devel
Hi all, WHAT IS IT ALL ABOUT On 2020-02-13, FPC approved a rewrite of our fonts packaging guidelines. STATUS ✅ Published https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/ (grammar fixes welcome as a PR) ✅ Fedora 33 and next ✅ Fedora 32 (before freeze deadline) ✅ Fedora

Re: dropping autogenerated dependency on pkg-config

2019-05-02 Thread Nicolas Mailhot via devel
Le mercredi 01 mai 2019 à 13:12 +0100, Tomasz Kłoczko a écrit : > On Wed, 1 May 2019 at 09:04, Nicolas Mailhot < > nicolas.mail...@laposte.net> wrote: > [..] > > > One of those specs is elfutils.spec in which is: > > > > > > %check > > > # Record some build root versions in build.log > > > uname -

Re: dropping autogenerated dependency on pkg-config

2019-05-03 Thread Nicolas Mailhot via devel
Le vendredi 03 mai 2019 à 09:46 +0100, Tomasz Kłoczko a écrit : > ial today, because the storage part has not been streamlined. > > As I wrote problem only is that without possibility really rollback > to > the full state described in set of exact N-E:V-Rs packages recorded > data such auditing da

Re: dropping autogenerated dependency on pkg-config

2019-05-03 Thread Nicolas Mailhot via devel
Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > wrote: > [..] > > You're assuming the only use is roolback. It's not > > Point taken. Can you shortly describe other use cases? You use apps

Re: dropping autogenerated dependency on pkg-config

2019-05-03 Thread Nicolas Mailhot via devel
Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit : > On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel > wrote: > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > > > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot v

Re: Upgrade to F30 gone wrong

2019-05-05 Thread Nicolas Mailhot via devel
It would be nice to have a robust upgradeable bootloader setup. I'm pretty sure that ranks before having a pretty flicker-free boot to Fedora users. Pretty boot has been a workstation priority for how many releases now? Baring that, just having a reinstall bootloader option in rescue mode would

Re: Upgrade to F30 gone wrong

2019-05-06 Thread Nicolas Mailhot via devel
Le dimanche 05 mai 2019 à 12:33 -0400, Steve Grubb a écrit : > On Sunday, May 5, 2019 11:39:50 AM EDT Nicolas Mailhot via devel > wrote: > > It would be nice to have a robust upgradeable bootloader setup. I'm > > pretty > > sure that ranks before having a prett

Re: Upgrade to F30 gone wrong

2019-05-06 Thread Nicolas Mailhot via devel
Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > Right and that's the same with beta testing, which is how bugs like > this can sometimes not even get found until after release. A lot of > tests are done on pristine systems that are throw away. It's entirely > understandable few p

Re: Upgrade to F30 gone wrong

2019-05-06 Thread Nicolas Mailhot via devel
Le May 6, 2019 4:29:22 PM UTC, Chris Murphy a écrit : >On Mon, May 6, 2019 at 1:52 AM Nicolas Mailhot > wrote: >> >> Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : >> > >> > Right and that's the same with beta testing, which is how bugs like >> > this can sometimes not even get fo

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

2019-05-31 Thread Nicolas Mailhot via devel
Le vendredi 31 mai 2019 à 02:15 +0200, Pavel Raiskup a écrit : > 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

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

2019-05-31 Thread Nicolas Mailhot via devel
Le jeudi 30 mai 2019 à 14:29 -0700, Samuel Sieb a écrit : > On 5/30/19 1:56 PM, Chris Murphy wrote: > > On Thu, May 30, 2019 at 8:40 AM Daniel Mach > > wrote: > > > Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a): > > > > I'm pretty sure this would break DeltaRPMs, since none of the > > > > drpm > > >

Re: RFC: Multiple parallel side tags

2019-06-08 Thread Nicolas Mailhot via devel
Le samedi 08 juin 2019 à 11:23 +0200, Igor Gnatenko a écrit : > Hi, > > Imagine situation that somebody is working on KDE rebase and me on > libgit2 rebase. Both involve rebuilding/updating some package, let's > say kf5-ktexteditor. > > We both work in different side tags, in KDE rebase kf5-ktext

New Go Packaging Guidelines landed in rawhide (koji) today

2019-06-08 Thread Nicolas Mailhot via devel
Hi, Fedora’s new Go packaging macros landed in rawhide (koji) today. The corresponding Fedora Go packaging conventions are therefore EFFECTIVE for new rawhide builds. For the first time in Fedora’s history, we will be able to perform Go package builds conforming to an approved Fedora Packaging Gu

Re: New Go Packaging Guidelines landed in rawhide (koji) today

2019-06-12 Thread Nicolas Mailhot via devel
Le 2019-06-12 10:39, Jakub Cajka a écrit : Fedora’s new Go packaging macros landed in rawhide (koji) today. I thought that we have agreed on Go SIG meeting with eclipseo to do this in side tag along with golang rebase(to avoid 2 rebuilds), https://fedoraproject.org/wiki/Changes/Adopt_new_Go

Re: Modularity vs. libgit

2019-06-14 Thread Nicolas Mailhot via devel
> We could go a step further and extend rpm and dnf to support multiple > versions of same named packages for installation. This is doable but > not necessarily trivial. Having rescued this week a system in abysmal stale, with traces of rpm forcing right and left, I'd say this would also requir

Re: Langpacks and the packages needed to display/input a language

2019-06-16 Thread Nicolas Mailhot via devel
Le samedi 15 juin 2019 à 20:13 +0200, Julen Landa Alustiza a écrit : > I don't have a clear opinion on this, yet. > > In my use case I totally agree with you, I don't really need all this > support, just a few thing are enough for me. > > But I understand that for the general non english speaker,

Re: HEADS UP: DynamicBuildRequires are available

2019-06-18 Thread Nicolas Mailhot via devel
Le 2019-06-18 03:27, Igor Gnatenko a écrit : Hi folks, Hi as of today, builders have been updated (thanks to Kevin) and DynamicBuildRequires finally work in Rawhide. Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires Example of real build: https://koji.fedoraproject.o

Re: HEADS UP: DynamicBuildRequires are available

2019-06-18 Thread Nicolas Mailhot via devel
Le 2019-06-18 10:42, Miro Hrončok a écrit : On 18. 06. 19 3:27, Igor Gnatenko wrote: Hi folks, as of today, builders have been updated (thanks to Kevin) and DynamicBuildRequires finally work in Rawhide. All of the following works? Koji, mock and copr? Mock already worked IIRC. Regards. --

Re: HEADS UP: DynamicBuildRequires are available

2019-06-18 Thread Nicolas Mailhot via devel
Le 2019-06-18 10:19, Miroslav Suchý a écrit : Dne 18. 06. 19 v 3:27 Igor Gnatenko napsal(a): as of today, builders have been updated (thanks to Kevin) and DynamicBuildRequires finally work in Rawhide. Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires Example of real b

Re: Modularity vs. libgit

2019-06-18 Thread Nicolas Mailhot via devel
Le 2019-06-17 22:04, Terry Bowling a écrit : Hi If I may, since I also represented the customer side not so long ago in a fortunexxx company. * Customers think we had too many repos. It is hard to find what they need. From a customer point of view you sidestepped the demand. Inste

Re: Langpacks and the packages needed to display/input a language

2019-06-19 Thread Nicolas Mailhot via devel
Le 2019-06-19 12:48, Jens-Ulrik Petersen a écrit : Hi And yes as Nicolas also said maybe we need: langpacks-ko-fonts and langpacks-ko-input-methods, etc. I's much more than input methods, it's anything you need to read/write a language (input, spell/grammar, fonts, etc) Though the whole con

Re: Langpacks and the packages needed to display/input a language

2019-06-19 Thread Nicolas Mailhot via devel
Le 2019-06-19 14:32, Nicolas Mailhot a écrit : Le 2019-06-19 12:48, Jens-Ulrik Petersen a écrit : Hi And yes as Nicolas also said maybe we need: langpacks-ko-fonts and langpacks-ko-input-methods, etc. I's much more than input methods, it's anything you need to read/write a language (input, sp

Re: HEADS UP: DynamicBuildRequires are available

2019-06-22 Thread Nicolas Mailhot via devel
Le vendredi 21 juin 2019 à 19:16 -0500, Jason L Tibbitts III a écrit : > (Certainly it's > better if it misses things because you can always just add them as > regular BuildRequires:, but it's tougher to deal with things added > erroneously.) That's trivial to handle too, just add a | grep -v 'ba

Re: HEADS UP: DynamicBuildRequires are available

2019-06-22 Thread Nicolas Mailhot via devel
Le vendredi 21 juin 2019 à 18:32 -0500, Jason L Tibbitts III a écrit : > > > > > > "MC" == Michael Cronenworth writes: > > I'm disappointed that the macro doesn't emit the > %generate_buildrequires > line as well; I'm not real sure, this would work, for projects that contain stuff involving mul

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Nicolas Mailhot via devel
Le lundi 24 juin 2019 à 18:50 +0200, Igor Gnatenko a écrit : > But packages will be still built for i686 architecture and then > shipped in repos (not completely sure if having i686-only repo is > useful, but they will be in x86_64 repos definitely). It would be nice if they were finally split in

Re: HEADS UP: DynamicBuildRequires are available

2019-06-26 Thread Nicolas Mailhot via devel
Le 2019-06-26 15:39, Richard W.M. Jones a écrit : On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote: as of today, builders have been updated (thanks to Kevin) and DynamicBuildRequires finally work in Rawhide. Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequire

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-26 Thread Nicolas Mailhot via devel
Le 2019-06-26 16:07, Josh Boyer a écrit : On Wed, Jun 26, 2019 at 9:24 AM Roberto Ragusa wrote: On 6/26/19 2:34 AM, Michal Schorm wrote: > I - and a people around me - have plenty of 32-bit hardware. Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines, updated to rec

Re: always update the bootloader during major upgrades

2019-06-28 Thread Nicolas Mailhot via devel
Le jeudi 27 juin 2019 à 12:26 -0600, Chris Murphy a écrit : > On Thu, Jun 27, 2019 at 9:06 AM Bruno Wolff III > wrote: > > On Wed, Jun 26, 2019 at 14:19:26 -0600, > > Chris Murphy wrote: > > > Short version: Fedora should take responsibility for the > > > bootloader > > > being up to date, by u

<    1   2   3   4   >