Re: Adding Passim as a Fedora 40 feature?

2023-08-28 Thread Nicolas Mailhot via devel
Le samedi 26 août 2023 à 15:14 +0100, Peter Robinson a écrit : > > In a lot of corporate datacentre networks the "users" on the network > would know what the network is comprised of, and often on these > networks they will have 10s, 100s of even 1000s of identical devices > where being able to do

Re: Deprecating SCP

2020-11-02 Thread Nicolas Mailhot via devel
Le lundi 02 novembre 2020 à 16:16 +0100, Marius Schwarz a écrit : > Am 02.11.20 um 16:13 schrieb Solomon Peachy: > > On Mon, Nov 02, 2020 at 03:44:39PM +0100, Jakub Jelen wrote: > > > I am looking for any kind of feedback from the idea through the > > > usability, > > > implementation. Is this

Re: The future of legacy BIOS support in Fedora.

2020-10-20 Thread Nicolas Mailhot via devel
Le mardi 20 octobre 2020 à 12:32 +0200, Petr Pisar a écrit : > > In my opinion what became slugish (besides web browsers) are desktop > environments that "accelerated" GUI by a move to OpenGL and > JavaScript. > A typical examples are login managers. GDM actually loads full Gnome, > thus GDM >

Re: The future of legacy BIOS support in Fedora.

2020-10-20 Thread Nicolas Mailhot via devel
Le lundi 19 octobre 2020 à 12:47 -0400, Stephen John Smoogen a écrit : > It is only after Moore's law 'broke' after 2003 stopped seeing > doubling cpu speeds every 18 months that trying to keep hardware > useful longer than 5 years has been possible. The real turning point is when Microsoft

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Nicolas Mailhot via devel
Le 2020-09-29 12:37, Lennart Poettering a écrit : This is not the reality I live in though. New-style high level programming languages tend to avoid being just a wrapper around C APIs. And thus they implement minimal DNS clients themselves, ignoring the LLMNR, mDNS and so on. Not just for

Re: [golang packaging] how to get files from source tarball

2020-09-01 Thread Nicolas Mailhot via devel
Le 2020-08-31 18:08, Zdenek Dohnal a écrit : Hi, I'm trying to package ipp-usb project (https://github.com/OpenPrinting/ipp-usb) which is written in Go. I generated spec file via go2rpm, but several files from source tarball which supposed to be packaged is not packaged e.g. systemd unit file

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

2020-07-20 Thread Nicolas Mailhot via devel
Le dimanche 19 juillet 2020 à 10:39 -0700, Kevin Fenzi a écrit : > On Mon, Jul 13, 2020 at 10:17:11AM +0200, Nicolas Mailhot via devel > wrote: > > Tough it is a litteral key = value file with no fancy formatting > > nor > > even ini-like sections, and a handful of variabl

Re: Remove all non UK/USA English spell checker variants from default Fedora installation

2020-07-18 Thread Nicolas Mailhot via devel
Le samedi 18 juillet 2020 à 15:21 +0200, Kevin Kofler a écrit : > Germano Massullo wrote: > > Since the huge list is brought by hunspell-en, can we just ship > > Fedora > > with hunspell-en-GB and hunspell-en-US ? > > I would even argue for shipping en_US only. It is the default > language of >

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

2020-07-13 Thread Nicolas Mailhot via devel
Le dimanche 12 juillet 2020 à 13:07 -0700, Kevin Fenzi a écrit : > On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel > wrote: > > > > This is now done in the latest code refresh and in the test copr > > https://src.fedoraproject.org/fork/nim/

Re: The future of legacy BIOS support in Fedora.

2020-07-11 Thread Nicolas Mailhot via devel
Le vendredi 10 juillet 2020 à 08:55 -0400, Przemek Klosowski a écrit : > > The marginal cost of a digital key has got to be smaller than the > marginal cost of the button The marginal cost of a button is completely marginal, on devices that already include other buttons, on a assembly line that

Re: Can we do away with release and changelog bumping?

2020-07-10 Thread Nicolas Mailhot via devel
Le vendredi 10 juillet 2020 à 14:59 +0200, Nicolas Mailhot a écrit : > Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit : > > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via > > devel > > wrote: > > > Le 2020-07-08 17:19, Pavel Raiskup

Re: Can we do away with release and changelog bumping?

2020-07-10 Thread Nicolas Mailhot via devel
Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit : > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel > wrote: > > Le 2020-07-08 17:19, Pavel Raiskup a écrit : > > > > > Small experiment (few-liner) for copr with "%bid, buil

Re: The future of legacy BIOS support in Fedora.

2020-07-10 Thread Nicolas Mailhot via devel
Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit : > > > Not quite---as I said in next sentence that you didn't include in > your quote, secure boot also tries to prevent unauthorized > modifications, That does not work either, because if your system is remotely exploitable,

Re: The future of legacy BIOS support in Fedora.

2020-07-10 Thread Nicolas Mailhot via devel
Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit : > On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel > wrote: > > If you remove end users from the loop there is zero zip nada need > > for > > secure boot in the first place. The sole

Re: The future of legacy BIOS support in Fedora.

2020-07-10 Thread Nicolas Mailhot via devel
Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel a écrit : > > My point is that however the updates are being produced, they need a > secure remote update method. It's not realistic to expect end users > to be in the loop If you remove end users from the loop there is zero

Re: The future of legacy BIOS support in Fedora.

2020-07-10 Thread Nicolas Mailhot via devel
Le jeudi 09 juillet 2020 à 23:58 -0400, Przemek Klosowski via devel a écrit : > > While it's true that a completely secure software chain doesn't > really exist yet, we are slowly going in that direction, because it > is just inconceivable otherwise in the world with billions of > autonomous IOT

Re: Btrfs by default, the compression option

2020-07-10 Thread Nicolas Mailhot via devel
Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit : > > Yes, it's completely reasonable to not do it. It might seem like a > > big > > change on its own, but Btrfs has had native compression for 10+ > > years, > > and at least three years for most all of the workloads at Facebook. > > So

Re: incorrect docs for forge macro extension, when using 'unknown' scm source (e.g., git.kernel.org) ?

2020-07-10 Thread Nicolas Mailhot via devel
Le jeudi 09 juillet 2020 à 09:40 -0700, PGNet Dev a écrit : > I'm working on a spec, pulling source with forgemeta/scm > > With known/supported scm sources (e.g., github), it works as > expected, with no issues. Because every forge hosting service out there is inventing its own archive export

Re: Can we do away with release and changelog bumping?

2020-07-08 Thread Nicolas Mailhot via devel
Le 2020-07-08 17:19, Pavel Raiskup a écrit : Small experiment (few-liner) for copr with "%bid, build system tag": https://pagure.io/copr/copr/pull-request/1436 Well, that ties the system to corp, not koji, and like the other proposal, that makes releases that do not import from one system to

Re: The future of legacy BIOS support in Fedora.

2020-07-06 Thread Nicolas Mailhot via devel
Le 2020-07-06 16:33, Gerd Hoffmann a écrit : On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel wrote: Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit : >   Hi, > > See above. sd-boot allows to edit the kernel command line too. Same > hotke

Re: The future of legacy BIOS support in Fedora.

2020-07-06 Thread Nicolas Mailhot via devel
Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit : >   Hi, > > > > default entry highlighted, a few seconds timeout with countdown. > > > Both > > > support editing boot entries. > > > Anecdata, but I definitely never (maybe once 15 years ago?) had > > grub > > install issue, but

Re: Can we do away with release and changelog bumping?

2020-07-06 Thread Nicolas Mailhot via devel
Le lundi 06 juillet 2020 à 13:06 +0200, Nicolas Mailhot a écrit : > > Because the build state exists in koji only, there is no need to > commit back to git. BTW I’m fairly certain I could have managed to implement the thing without adding source files to the SRPM, removing the need for mock

Re: Can we do away with release and changelog bumping?

2020-07-06 Thread Nicolas Mailhot via devel
Le lundi 06 juillet 2020 à 10:19 +0200, Adam Saleh a écrit : > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve > this problem few months ago. > It is a koji plugin as well as CLI tool that makes bumping the > release field and generating changelog problem of Koji, > instead of

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

2020-07-06 Thread Nicolas Mailhot via devel
Le 2020-07-05 23:55, Dan Čermák a écrit : Hi Dan So essentially you store the changelog in a separate file The changelog is already detached in the F33 change https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs This F34 change adds bumping

Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)

2020-07-06 Thread Nicolas Mailhot via devel
Le dimanche 05 juillet 2020 à 23:36 +0200, Dan Čermák a écrit : > Nicolas Mailhot via devel writes: > > > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > > > Nicolas Mailhot via devel wrote: > > > > So if you want to push Fed

Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread Nicolas Mailhot via devel
Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit : > > specification != standard I, for one, am very happy that the systemd project makes the effort of documenting its formats so others can write competing implementations or write software that interacts with the systemd

Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)

2020-07-05 Thread Nicolas Mailhot via devel
Le dimanche 05 juillet 2020 à 18:41 +0200, Nicolas Mailhot a écrit : > > While timestamping would remove the need to pass the last build info > to the next one it would also break all the workflows where several > rebuilds are done in parallel for separate needs, and the latest > rebuild is not

Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)

2020-07-05 Thread Nicolas Mailhot via devel
Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > Nicolas Mailhot via devel wrote: > > So if you want to push Fedora release logic to its ultimate > > conclusion, > > the thing that should be in charge of committing the new > > release/changelog bui

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

2020-07-05 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann' Mierzejewski a écrit : > > > To get beautiful changelogs, you also need to add > > > > > > %buildsys_name Your name > > %buildsys_email Your email > > > > > > in ~/.rpmmacros > > What about having one macro called

Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread Nicolas Mailhot via devel
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit : > (Note this explicitly excludes Chromebooks) So you want to discuss Linux desktop deployments, excluding the only sucessful mass Linux desktop deployment to date? Why? Also your data conflates systems sold in with systems

Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread Nicolas Mailhot via devel
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit : > folks that make very long-lifecycle industrial systems > meant to run generally ancient software Those things are not meant to run ancient software. They are meant to run a very long time. And yes at the end of this time the

Re: use of 'date' in rpm .spec %define concats add'l str chars?

2020-07-04 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 11:09 -0700, PGNet Dev a écrit : > > %define _build_timestamp %( date +%Y%m%d_%H%M%S ) > You’re hitting rpm macro expansion and the fact someone added %S as alias to%SOURCE in recent rpm versions (source management is an unholly mess in original rpm and

Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?

2020-07-04 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 08:24 -0700, PGNet Dev a écrit : > > > On 7/3/20 12:01 AM, Nicolas Mailhot wrote: > > You added some processing that depends on the git command (that > > forgemeta does not use) but forgot to BuildRequire the package > > providing that command. > > It's _clearly_

Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?

2020-07-03 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit : > > I'd appreciate the link to spectool rewrite, though. Here it is: https://pagure.io/rpmdevtools/blob/master/f/rpmdev-spectool Regards, -- Nicolas Mailhot ___ devel mailing list --

Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?

2020-07-03 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit : > On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel > wrote: > > it will certainly be possible to compute a second level of sources > > during the dynamic buildrequires first pass over prep,

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

2020-07-03 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 09:48 +0200, Pierre-Yves Chibon a écrit : > On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote: > > Nicolas Mailhot wrote: > > > The same process that commits a new state of the changelog file > > > in > > > sources, > > > commits the date that was written

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

2020-07-03 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 10:06 +0200, Pierre-Yves Chibon a écrit : > On Thu, Jul 02, 2020 at 03:44:51PM +0200, Nicolas Mailhot via devel > wrote: > > Le 2020-07-02 15:11, Kamil Dudka a écrit : > > > On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot

Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?

2020-07-03 Thread Nicolas Mailhot via devel
Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit : Hi, As usual for those things the reason is dead stupid (so stupid the human brain refuses to see it) > submitting the _same_ spec to COPR for online build FAILS @, > supposedly, similar Mock build > > Here's a diff > >

Re: The future of legacy BIOS support in Fedora.

2020-07-03 Thread Nicolas Mailhot via devel
Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit : > > 5-10 years? A better estimate would be 15-20 years. People aren't > > going to > > throw away perfectly fine systems and jump to new "cloud" platforms > > just > > because the OS they were using dropped BIOS support. They'll just

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

2020-07-03 Thread Nicolas Mailhot via devel
Le 2020-07-02 15:11, Kamil Dudka a écrit : 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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-03 Thread Nicolas Mailhot via devel
Le jeudi 02 juillet 2020 à 17:44 -0400, Josef Bacik a écrit : > However just because we know something > went wrong doesn't mean we can do anything about it, it just means > that the user knows now that they need to restore from backups That’s a perfect answer for an Enterprise server setup

Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?

2020-07-03 Thread Nicolas Mailhot via devel
Le vendredi 03 juillet 2020 à 07:26 +0200, Pavel Raiskup a écrit : Hi, > I'm not familiar with the %forge* macros, but I don't think it is > expected that you will add commands that need the Internet into the > macro definition. It’s neither expected nor unexpected. For a Fedora-oriented

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

2020-07-03 Thread Nicolas Mailhot via devel
Le July 2, 2020 2:47:49 PM UTC, Vitaly Zaitsev via devel a écrit : >On 02.07.2020 11:27, Nicolas Mailhot wrote: >> Why? Koji schedules a build. The build registers its own build date >in >> the produced packages. Koji decides to keep and commit the result, or >> drop it (scratch build, failed

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 12:42, Igor Raits a écrit : So who is going to implement necessary changes in mock and koji for this proposal to be complete? 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

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 11:59, Florian Weimer a écrit : * Nicolas Mailhot via devel: Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: The detached changelog is just one more file in SRPM sources, which is modified by rpmbuild at `%build

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 11:38, Igor Raits a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 11:27 +0200, Nicolas Mailhot via devel wrote: Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : > On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: > > The

Re: python-sphinx_rtd_theme update: comments requested

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 10:51, Miro Hrončok a écrit : On 01. 07. 20 19:34, Nicolas Mailhot via devel wrote: Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit : Given the /usr/share font links in CSS won't work when the documentation is exposed via a webserver, I assume the docs are mostly

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 11:21, Igor Raits a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote: Le 2020-07-02 09:52, Florian Weimer a écrit : > * Nicolas Mailhot via devel: > > > > How do I let rpm generate the changelo

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 11:17, Nicolas Mailhot via devel a écrit : This may seem a bit complex and convoluted, but that’s because autobumping https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping is a small addition over the big %auto_macros change. https

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: The detached changelog is just one more file in SRPM sources, which is modified by rpmbuild at `%build` time with other files rpmbuild modifies. I don't like that. %changelog should

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

2020-07-02 Thread Nicolas Mailhot via devel
Le 2020-07-02 09:52, Florian Weimer a écrit : * Nicolas Mailhot via devel: How do I let rpm generate the changelog automatically? This feature is not changelog generation, just changelog bumping on build events. You still need some other method to put non-build events in the changelog

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

2020-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 23:48 +0200, Dan Čermák a écrit : > Hi Nicolas, Hi Dan > This is a system-wide change because all packages build with > > redhat-rpm-config, but it only concerns packages that opted to use > > this part of redhat-rpm-config (auto framework). > > > > The change will

Re: python-sphinx_rtd_theme update: comments requested

2020-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit : > > Given the /usr/share font links in CSS won't work when the > documentation is > exposed via a webserver, I assume the docs are mostly intended to be > browsed > (possibly offline) from within Fedora anyway. It’s not that

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 10:27 -0400, Neal Gompa a écrit : > On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel > wrote: > > > > Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski- > > Szmek > > a écrit : > > > > >

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek a écrit : > > Actually that part has been answered pretty comprehensively. The > split between / and /home is hurting users Actually this split is a godsend because you can convince anaconda to leave your home alone when

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

2020-07-01 Thread Nicolas Mailhot via devel
Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann' Mierzejewski a écrit : Hi, > That's not detailed at all. You should provide at least one example > here (or a direct link to one somewhere else on the wiki). Thank you for your attention and kind review. yes the wiki page was

Re: [Fedora-packaging] Re: Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Nicolas Mailhot via devel
Le mardi 30 juin 2020 à 23:04 +0200, Nicolas Mailhot via devel a écrit : > Le mardi 30 juin 2020 à 21:45 +0200, Igor Raits a écrit : > > > > I think this would be already at least 30 times That unpleasantness aside if anyone wants to engage in constructive technical discussi

Re: [Fedora-packaging] Re: Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal

2020-06-30 Thread Nicolas Mailhot via devel
Le mardi 30 juin 2020 à 21:45 +0200, Igor Raits a écrit : > On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > > > == Summary == > > > > redhat-rpm-config will be updated to

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

2020-06-30 Thread Nicolas Mailhot via devel
Le mardi 30 juin 2020 à 21:33 +0200, Igor Raits a écrit : > On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > > > The change will make those packages auto-bump and auto-changelog at > > the rpm level,

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-30 Thread Nicolas Mailhot via devel
Le lundi 29 juin 2020 à 10:26 -0600, Chris Murphy a écrit : > > Come on. It's cleanly unmounted and doesn't mount? > > I guess you missed the other emails about dm-log-writes and xfstests, > but they directly relate here. Josef relayed that all of his deep > dives into Btrfs failures since the

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Nicolas Mailhot via devel
Le samedi 27 juin 2020 à 10:47 +0200, Igor Raits a écrit : > > Do you run postgres, financial transactions and random blackouts on > your laptop / workstation? If so, isn't it just for testing purposes? Wokstations are full of high-value personnal data, because home users do not have an IT

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Nicolas Mailhot via devel
Le vendredi 26 juin 2020 à 12:30 -0400, Josef Bacik a écrit : > On 6/26/20 11:15 AM, Matthew Miller wrote: > > On Fri, Jun 26, 2020 at 11:13:39AM -0400, Josef Bacik wrote: > > > Not Fedora land, but Facebook installs it on all of our root > > > devices, so millions of machines. We've done this

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Nicolas Mailhot via devel
Le vendredi 26 juin 2020 à 23:28 +0100, Tomasz Kłoczko a écrit : > On Fri, 26 Jun 2020 at 23:21, Alex Thomas > wrote: > > Once question, are we looking at using a layout like openSUSE is > > doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, > > or > > are we looking at something

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

2020-06-27 Thread Nicolas Mailhot via devel
Le vendredi 26 juin 2020 à 07:41 -0700, PGNet Dev a écrit : > hi, > > On 6/25/20 11:58 PM, Nicolas Mailhot wrote: > > forgemeta works in release mode, with release archives published > > over > > http(s). It does not talk at all to source projects using the git > > protocol (and that is

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

2020-06-26 Thread Nicolas Mailhot via devel
Le vendredi 26 juin 2020 à 07:41 -0700, PGNet Dev a écrit : > hi, > > On 6/25/20 11:58 PM, Nicolas Mailhot wrote: > > forgemeta works in release mode, with release archives published > > over > > http(s). It does not talk at all to source projects using the git > > protocol (and that is

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

2020-06-26 Thread Nicolas Mailhot via devel
Hi, forgemeta works in release mode, with release archives published over http(s). It does not talk at all to source projects using the git protocol (and that is intentional, since a lot ot things tooling-side do not talk the git protocol and will never talk the git protocol, starting with rpm

Re: Heads up - %configure and %cmake changes affecting MPI packages

2020-06-24 Thread Nicolas Mailhot via devel
Le mercredi 24 juin 2020 à 21:49 -0600, Orion Poplawski a écrit : > This change in redhat-rpm-config: > > * Wed Jun 03 2020 Igor Raits - > 158-1 > - Add option to choose C/C++ toolchain > > changed %_set_build_flags to also set the CC/CXX compiler variables: > >    CC=%{__cc}; export CC ; \ >  

Re: RHEL 9 and modularity

2020-06-24 Thread Nicolas Mailhot via devel
Le mercredi 24 juin 2020 à 12:03 +0200, Nicolas Mailhot a écrit : > Le mercredi 24 juin 2020 à 11:56 +0200, Petr Pisar a écrit : > > I see. I focused on having the stream information on RPM level. > > Then > > the > > answer is no, the package name does not contain the information. > > > > My

Re: RHEL 9 and modularity

2020-06-24 Thread Nicolas Mailhot via devel
Le mercredi 24 juin 2020 à 11:56 +0200, Petr Pisar a écrit : > I see. I focused on having the stream information on RPM level. Then > the > answer is no, the package name does not contain the information. > > My idea was that DNF could discriminate the same-name package using > the >

Re: RHEL 9 and modularity

2020-06-24 Thread Nicolas Mailhot via devel
Le mardi 23 juin 2020 à 20:31 +0200, clime a écrit : > Or we can bring the notion of > the namespaces into rpm itself (that's where my suggestion of > "Stream" > rpm attribute comes from but it could also be called just > "Namespace"). But then there is the argument: "Why not just put the >

Re: how to correctly remove a subpackage ?

2020-06-12 Thread Nicolas Mailhot via devel
Le vendredi 12 juin 2020 à 19:31 +0200, josef radinger a écrit : Hi, > we have > X-1 > X-a-1 (dependent on X and Y) > X-b-1 (dependent on X) > > now the dependency Y is removed from rawhide and i create a new > version > 2 of package X without the dependency on Y and thus no subpackage X- > a-

Re: Something weird with modules in kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64

2020-06-09 Thread Nicolas Mailhot via devel
Le mardi 09 juin 2020 à 15:05 +0100, Richard W.M. Jones a écrit : > I've installed kernel-5.8.0- > 0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64 but > not rebooted (still running 5.6.0-0.rc5.git0.1.fc33.x86_64 on the > host). I can confirm that rawhide does not boot in a useful state right now (no

Re: [Fedora-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Nicolas Mailhot via devel
Le mardi 09 juin 2020 à 14:56 +0200, Nicolas Mailhot a écrit : > Le mardi 09 juin 2020 à 14:35 +0200, Vít Ondruch a écrit : > > > > The proposal was to optionally disable test. When somebody asked > > why, > > the answer was bootstrapping. But we know how to handle > > bootstrapping. > > So

Re: [Fedora-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Nicolas Mailhot via devel
Le mardi 09 juin 2020 à 14:35 +0200, Vít Ondruch a écrit : > > The proposal was to optionally disable test. When somebody asked why, > the answer was bootstrapping. But we know how to handle > bootstrapping. > So shouldn't somebody spend time changing the test conditionals to > bootstrapping

Re: [Fedora-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Nicolas Mailhot via devel
Le mardi 09 juin 2020 à 12:21 +0200, Vít Ondruch a écrit : > Dne 09. 06. 20 v 12:12 Nicolas Mailhot napsal(a): > > Le mardi 09 juin 2020 à 12:08 +0200, Vít Ondruch a écrit : > > > Just FTR, we have bootstrapping guidelines > > > > > >

Re: [Fedora-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Nicolas Mailhot via devel
Le mardi 09 juin 2020 à 12:08 +0200, Vít Ondruch a écrit : > > Just FTR, we have bootstrapping guidelines > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping > Those suffer from 1. the horrible bcond logic inversion that trips pretty much everyone all the time. 2. the

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-09 Thread Nicolas Mailhot via devel
Le lundi 08 juin 2020 à 09:48 -0600, Jeff Law a écrit : > > I put faith in both the upstreams and packagers to do the right thing > for their project. Right now Fedora policy does exactly the opposite > by forcing everyone to use GCC rather than making an informed, per > project, decision.

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-06 Thread Nicolas Mailhot via devel
Le samedi 06 juin 2020 à 12:37 +0200, Igor Raits a écrit : > > Why is it painful? You have all dependencies packaged that follow > semver (not like Go) and it is quite easy to build those packages. And Go has all build dependencies in the release where they are used (not like rust, with magic

Re: Let's standardize the way to disable tests during RPM build?

2020-06-05 Thread Nicolas Mailhot via devel
Le vendredi 05 juin 2020 à 15:46 +0100, Richard W.M. Jones a écrit : > > For the RISC-V bootstrap we used rpmbuild directly (before Koji and > its dependencies had been ported), and added --nocheck. However once > Koji was working we built packages properly with checks enabled. > > How often do

Re: Location of executable code

2020-05-23 Thread Nicolas Mailhot via devel
Le vendredi 22 mai 2020 à 21:31 -0400, Steve Grubb a écrit : > > Over a couple emails I kind of realized that originally this was > framing the > question wrong. My question now is how can we determine what is meant > to be > executable by system applications vs examples and other cruft?

Re: Location of executable code

2020-05-23 Thread Nicolas Mailhot via devel
Le vendredi 22 mai 2020 à 16:48 -0400, Steve Grubb a écrit : > On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel > wrote: > > > > In general, data is code is data. > > I know this argument well (Weird Machines). I was making the same > argument 10 years ago. :-) It got

Re: Location of executable code

2020-05-23 Thread Nicolas Mailhot via devel
Le vendredi 22 mai 2020 à 20:41 +0200, Nicolas Mailhot via devel a écrit : > > So, no use looking for non-executable /usr/share. A lot of /usr/share > is executable and will stay that way. Also moving executable things somewhere else would make multiarch (more of) a major hassle

Re: Location of executable code

2020-05-22 Thread Nicolas Mailhot via devel
Le vendredi 22 mai 2020 à 10:30 -0400, Steve Grubb a écrit : > The /usr/share hierarchy is for all read-only architecture > independent data > files. The important part of the FHS definition is “read-only architecture independent“. Because everything on computing storage is data depending on how

Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-21 Thread Nicolas Mailhot via devel
Le mercredi 20 mai 2020 à 22:18 +0200, Miro Hrončok a écrit : > > We could have parallel installable multiple Python version stacks > w/out Modularity just fine. The "only little problem" is we hardly > have the enough maintainers to maintain the 3k+ existing Python > packages. BTW, that’s not a

Re: Re-Launching the Java SIG

2020-05-18 Thread Nicolas Mailhot via devel
Le lundi 18 mai 2020 à 08:34 -0500, Ty Young a écrit : > > The "toolchain" isn't broken, other than Gradle developers not > caring about backwards compatibility but... It works for them, just > as constantly breaking internal kernel APIs works for the Linux > kernel The difference, is that you

Re: Re-Launching the Java SIG

2020-05-18 Thread Nicolas Mailhot via devel
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit : > Hello, > > On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel < > devel@lists.fedoraproject.org> wrote: > > Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit : > > > On Fri, 15 May 202

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

2020-05-16 Thread Nicolas Mailhot via devel
Le samedi 16 mai 2020 à 11:09 +0200, Nicolas Mailhot a écrit : > Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit : > > So, another way that could work, with minimal tooling is that we > > keep > > the master branch strictly mirroring whatever upstream branch we > > follow, > > For

Re: Re-Launching the Java SIG

2020-05-16 Thread Nicolas Mailhot via devel
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit : > On Fri, 15 May 2020 08:02:34 +0200 > Michal Srb wrote: > > An aside, just to clarify for myself. That means that all Java apps > are > the equivalent of statically linked, right? And are related to > things > like flatpaks and

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

2020-05-16 Thread Nicolas Mailhot via devel
Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit : > > So, another way that could work, with minimal tooling is that we > keep > the master branch strictly mirroring whatever upstream branch we > follow, For some projects we are not hopping between branches of the same upstream git,

Re: Re-Launching the Java SIG

2020-05-14 Thread Nicolas Mailhot via devel
Le jeudi 14 mai 2020 à 06:33 -0500, Ty Young a écrit : > > I could literally go on and on. The "my-shit-don't-stink" attitude is > so terrible it's borderline sad. And years of terminally broken build practices Java-side have finally resulted in complete capture of all the Java big data code the

Re: Re-Launching the Java SIG

2020-05-14 Thread Nicolas Mailhot via devel
Le jeudi 14 mai 2020 à 11:53 +0200, Michal Srb a écrit : > > Since there is no standard place for shared Java libraries on your > laptop, Of course there is one /usr/share/java, which has been defined and used by Linux distributions since jpackage times (circa ~2000). Java is not special from a

Re: New set of questions for FESCo candidates?

2020-05-14 Thread Nicolas Mailhot via devel
Le mercredi 13 mai 2020 à 15:17 -0400, Josh Boyer a écrit : Hi, > If the consensus from the Fedora community is that RHEL should shift > development elsewhere, the Fedora Council can always reach out to me > and I can start that internal conversation. I do not believe for a > second that's

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

2020-05-10 Thread Nicolas Mailhot via devel
Hi, Well, *my* packaging workflow is pretty simple: 1. point to the upstream git repo in my spec file with %{forgeurl} and the rest of the forge macros 2. point to the target upstream tag or commit with the associated variable 3. spectool (or co from lookaside if already there) 4. build If I

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

2020-05-06 Thread Nicolas Mailhot via devel
Hi, Also Fedora is driving a lot of spec syntax enhancements, both at the rpm and the macro layer. Pushing spec files upstream is a sure way to freeze spec syntax in stone and have everything behave in rpm 3.x mode (with rpm 3.x limitations) 20 years from now. The whole thing is just a variation

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

2020-05-04 Thread Nicolas Mailhot via devel
Le lundi 04 mai 2020 à 17:31 +0100, José Abílio Matos a écrit : > On Monday, 4 May 2020 16.41.26 WEST Richard Shaw wrote: > > > For the longest time I at least overrode it so it wouldn't mix > everything > > together by putting the package name in the mix: rpmbuild//... > > So did I, for the

Re: Proposal to enable spec file preprocessing step before srpm build

2020-04-30 Thread Nicolas Mailhot via devel
Le lundi 09 mars 2020 à 00:26 +0100, clime a écrit : Hi, > the code would fail because at that point, the > git metadata is already missing (they are not included in srpms). Can’t storage of built-time information in srpms be fixed instead of adding a whole new overlay over existing tools,

Re: RFC: Feature macros (aka USE flags)

2020-04-30 Thread Nicolas Mailhot via devel
Le jeudi 30 avril 2020 à 10:49 +0200, Petr Šabata a écrit : > On Tue, Apr 28, 2020 at 9:55 AM Nicolas Mailhot via devel > wrote: > > 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: > &

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

2020-04-30 Thread Nicolas Mailhot via devel
Le jeudi 30 avril 2020 à 10:03 +0200, Nicolas Mailhot a écrit : > > Old human languages did not use word separators like space in > writing, because "everyone knew" where one word started and the next > finished. Even scholars that spent their life studying one of those > past civilizations find

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

2020-04-30 Thread Nicolas Mailhot via devel
Le jeudi 30 avril 2020 à 10:03 +0200, Nicolas Mailhot a écrit : > > Clever “it’s obvious in the few cases we imagine today, we do not > need a clean version separator” syntaxes fail hard once exposed to > the real world. Also, to get back to the original subject, the whole python package

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

2020-04-30 Thread Nicolas Mailhot via devel
Le jeudi 30 avril 2020 à 00:38 +0200, Miro Hrončok a écrit : > > My sentence was about "python3.9" not being more annoying than > "python-3.9". > > I wonder, why do you consider periods in names confusing? … > jboss-jsf-2.1-api Another example where the hyphen helps reading. The version is

  1   2   3   4   >