Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

2020-04-29 Thread Nicolas Mailhot via devel
Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit : > And I don't understand what kind of automation are we > talking about that needs to parse the "3.9" part and figure out it is > a "qualifier". It mostly hits you in the package creation code. The Go macro code will just dump -qualif

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

2020-04-29 Thread Nicolas Mailhot via devel
Le mercredi 29 avril 2020 à 19:43 +0200, Miro Hrončok a écrit : > On 29. 04. 20 19:37, Nicolas Mailhot wrote: > > Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit : > > > > > All [compat packages] MUST include the base name suffixed by > > > either: > > Well we are not creating a comp

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

2020-04-29 Thread Nicolas Mailhot via devel
Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit : > Such automation is broken anyway, because it cannot tell if python- > requests is a > Python library or a Python "qualifier". It is no more broken than automation that "knows" test means is a version. Of course before you apply

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

2020-04-29 Thread Nicolas Mailhot via devel
Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit : > All [compat packages] MUST include the base name suffixed by either: Well we are not creating a compat package here and not adding an hyphen creates an artificial numeric/non numeric special case. But, I see someone formalised the

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

2020-04-29 Thread Nicolas Mailhot via devel
Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit : Hi, > I’m working on a change to rename pythonXY packages to pythonX.Y, > e.g. python39 to python3.9. > > Motivation: > When you install an additional Python interpreter, the command that > runs it contains a dot (e.g. /usr/bin/pytho

Re: RFC: Feature macros (aka USE flags)

2020-04-28 Thread Nicolas Mailhot via devel
Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit : > On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote: > > > > %_use_ncurses %{lua: > > if rpm.expand("%{name}") == "yourpackage1" > > or rpm.expand("%{name}") == "yourpackage2" then > > print(rpm.expand("%{bcond_with foo}%{wit

Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Nicolas Mailhot via devel
Le lundi 27 avril 2020 à 19:12 +0200, Petr Šabata a écrit : > > Yes, this is exactly what I'm trying to achieve -- to have > distribution-wide generic keywords that control default build options > in packages It can be done at the rpm layer and in fact there are already quite a lot of such tunabl

Re: ProtonMail Bridge rpm build request

2020-04-23 Thread Nicolas Mailhot via devel
Le jeudi 23 avril 2020 à 06:42 +, Mattia Verga via devel a écrit : > > This is something I would really like to have in Fedora repos, but > it > requires some Golang packaging skills which I miss. Golang packaging > guidelines follows specific rules, the specfile you provide is not > valid,

Re: Modularity Survey

2020-04-20 Thread Nicolas Mailhot via devel
Le lundi 13 avril 2020 à 13:34 -0400, Matthew Miller a écrit : > On Sat, Apr 11, 2020 at 01:30:57PM +0200, Kevin Kofler wrote: > > That is another major concern, that decisions made by Fedora for > > Fedora > > users depend more and more on input from people (and companies) who > > are NOT > > Fe

Re: Call for testers for rpmautospec in staging

2020-04-20 Thread Nicolas Mailhot via devel
Hi, Another solution would be to just save the state from which autobump is computed in the srpm, and bump from this state at the rpmbuild level. As long as the previous counter value is available computing a new one is just a few lines of lua macro code That would remove any adherence to koji, m

Re: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)

2020-04-09 Thread Nicolas Mailhot via devel
Le mercredi 14 août 2019 à 23:50 -0400, James Antill a écrit : > Following is the list of topics that will be discussed in the FPC > meeting Sadly, I find myself forced to request adding https://pagure.io/packaging-committee/issue/968 to FPC‘s agenda Regards, -- Nicolas Mailhot _

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

2020-04-08 Thread Nicolas Mailhot via devel
Le mardi 07 avril 2020 à 14:27 -0400, Stephen Gallagher a écrit : > > The other piece of it is that there's a UX/psychological piece to it. > If we call it .eln9.1.0, people are quite likely to skim over the 'n' > and confuse themselves into thinking it's a RHEL 9.1.0 package. Then use .el.9.dev

Re: Rawhide update from side tag pending for 2 days

2020-04-07 Thread Nicolas Mailhot via devel
There is a problem right now with the part of koji that tags builds and adds them to the various repos koji uses for new builds. So you can build new packages, but can not rely on further builds seeing your just-built packages. -- Nicolas Mailhot ___ de

Re: bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel

2020-04-07 Thread Nicolas Mailhot via devel
Le mardi 07 avril 2020 à 06:31 -0400, Paul Dufresne via devel a écrit : > Le 20-04-06 à 21 h 01, Paul Dufresne a écrit : > > BTW, thanks I was searching for an example of package using a git > version rather than a released archive! > Just for the record, *I think* the current package is a bad exam

Re: CPE Weekly: 2020-04-04

2020-04-06 Thread Nicolas Mailhot via devel
Le lundi 06 avril 2020 à 11:42 -0400, Alex Scheel a écrit : > > I'm not sure why what happens outside Fedora infra has anything to do > with the dist-git discussion. Are you suggesting that all > contributors > to all Fedora upstream should weigh in on this discussion as well? I > mean, that'd be

Re: CPE Weekly: 2020-04-04

2020-04-06 Thread Nicolas Mailhot via devel
Le lundi 06 avril 2020 à 10:09 -0400, Alex Scheel a écrit : > > In the last FESCo election, 273 ballots were cast [0]. According to > the > graph maintained by Matthew Miller [1], we have between 225 and 375 > active maintainers in Fedora, depending on how you count. That’s *weekly* activity. As

Re: CPE Weekly: 2020-04-04

2020-04-06 Thread Nicolas Mailhot via devel
Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit : > > It'd be interesting to see if the FESCo election system could be > repurposed to get a sense of all packagers' opinions, rather than > make assumptions on how the community as a whole feels based on a few > vocal members and their par

Re: %bcond_with/%bcond_without

2020-04-06 Thread Nicolas Mailhot via devel
Le lundi 06 avril 2020 à 09:03 +0200, Petr Pisar a écrit : > > # Build an HTML manual with ascidoc > %bcond_without docs > # Perform the tests > %bcond_without tests I feel the above syntax is hopeless. You need boilerplate (in all eln specs!) to explain that foo_without tests means enabling test

Re: Mock build of GO program fails

2020-04-03 Thread Nicolas Mailhot via devel
Le vendredi 03 avril 2020 à 10:58 +, Ralf Senderek a écrit : > I need a bit of assistance from a GO package expert. > > I'm trying to package ssh-chat. ( > https://bugzilla.redhat.com/show_bug.cgi?id=1819180) > ssh-chat is written in GO and it implements a custom SSH server > (on a different

[HEADS UP] Working fontconfig validation in rawhide

2020-04-02 Thread Nicolas Mailhot via devel
Hi all, Now that Fedora fonts packaging guidelines have been switched to standard macro calls like %fontcheck, is is possible to fix problems in a central place, without relying on boilerplate missing in 3/4th of our specs. One of those longstanding problems, is the lack of validation of the font

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-04-02 Thread Nicolas Mailhot via devel
Le jeudi 02 avril 2020 à 16:04 -0400, David Cantrell a écrit : > > > * We could force all ELN builds to have epoch+100 when they rebuild > > (this has problems with future updates). > > No need to modify the Epoch. And not advisable. Wild idea (perhaps completely unworkable): upstream packagers

Re: @core install picking up desktop packages

2020-04-02 Thread Nicolas Mailhot via devel
Le jeudi 02 avril 2020 à 13:24 -0400, Steve Grubb a écrit : > Hello, > > I've been doing some testing of F32 and was curious about something. > I have a > kickstart file that just installs @core to be a minimal system. While > looking > over the resulting system, there are fonts, wayland, gtk3 a

Re: [Fedora-packaging] Re: Schedule for Thursday's FPC Meeting (2020-04-02 16:00 UTC)

2020-04-02 Thread Nicolas Mailhot via devel
Le jeudi 02 avril 2020 à 10:04 +0200, Miro Hrončok a écrit : > > If there anything you need to add to the agenda, just ask and I'll > add the tag. https://pagure.io/packaging-committee/pull-request/951 please? Will just wither away without FPC attention Regards, -- Nicolas Mailhot ___

Re: CPE Git Forge Decision

2020-04-01 Thread Nicolas Mailhot via devel
Le mercredi 01 avril 2020 à 12:15 -0400, Matthew Miller a écrit : > > I understand the sentiment but would like to tweak it a bit. Rather > than a > tooling project, Fedora is an _integration_ project. We bring > together all > of this software in the world and create polished solutions for > user

Re: CPE Git Forge Decision

2020-04-01 Thread Nicolas Mailhot via devel
Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit : > > To distill it down: > > - Gitlab has more features that are needed right now for our > stakeholder group > - Gitlab has an entire company dedicated to roadmap features, we do > not. Unfortunately, Gitlab’s roadmap is also confl

Re: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL

2020-03-31 Thread Nicolas Mailhot via devel
Le mardi 31 mars 2020 à 10:00 +0200, Petr Pisar a écrit : > > And not for a fresh new installation or an upgrade from an non-up-to- > date system Because, it’s better to make usupported configurations work, at the expense of stuff Fedora commited to support? Modular priorities are strange. Rega

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

2020-03-30 Thread Nicolas Mailhot via devel
Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit : > > > As a General User > > I want to access repos fully over https > > For environments where SSH is blocked > > I would be really curious if the Red Hat Infrastructure Security guys > have changed their opinion on this after four year

Re: Upgrade tooling

2020-03-30 Thread Nicolas Mailhot via devel
> On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > Yes, that is an important hurdle that Fedora generally doesn't > > encounter > > at all. Fedora usually waits until the new rpm functionality is > > released > > in older versions of Fedora before allowing it to be used in > > rawhi

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Nicolas Mailhot via devel
Le mercredi 25 mars 2020 à 14:19 -0400, Neal Gompa a écrit : > On Wed, Mar 25, 2020 at 2:16 PM Miro Hrončok > wrote: > > On 25. 03. 20 19:10, Stephen Gallagher wrote: > > > In general, very few packages should even need conditionalizing > > > at > > > all; that's why I've been saying that this dis

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Nicolas Mailhot via devel
Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit : > My point was to highlight that ELN is not a "stable edition" like > Fedora Server. ELN is Rawhide, its quality is no better than Rawhide > quality, its stability is Rawhide stability, its target audience is > Rawhide audience.

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Nicolas Mailhot via devel
Le mercredi 25 mars 2020 à 07:19 -0700, Troy Dawson a écrit : > On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel > wrote: > > > > rpm state in EL prevents most downstreaming. Please focus efforts > > there. > > > > I don’t see how you will

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Nicolas Mailhot via devel
Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit : > On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok > wrote: > As I mentioned in the previous mail, branching goes against the > purpose of the effort. > > What we like to achieve is to create a continuous flow from Fedora > Rawhid

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

2020-03-25 Thread Nicolas Mailhot via devel
Le mercredi 25 mars 2020 à 11:28 +0100, Iñaki Ucar a écrit : > On Wed, 25 Mar 2020 at 01:14, Gavin Simpson > wrote: Hi, > Adding de...@lists.fp.o to CC. A workaround is to avoid using PS > fonts for symbols. PS fonts are dead mid-term everywhere, and already forbidden in new Fedora font package

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

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

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: 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: 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-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-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-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 à 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 à 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 à 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 à 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
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-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-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 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 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-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-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: 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: 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: 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: 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-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: 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: 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: 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: 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: 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: 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: 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-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: 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: 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: 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: 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: 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: 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 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-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-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 à 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: 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: 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: 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: 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 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: 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: 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 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 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 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-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-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-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: 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: 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: 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: 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 à 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-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-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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-10 Thread Nicolas Mailhot via devel
Le mardi 10 décembre 2019 à 07:36 -0700, John M. Harris Jr a écrit : > Most users, > just like most American and UK users, set their keyboard layout to > their primary layout, and then don't change it, Actually, most non western users spend their time switching between several input methods, one

<    1   2   3   4   >