Re: Adding Passim as a Fedora 40 feature?

2023-08-28 Thread Nicolas Mailhot via devel
n to save any bandwidth), they won’t benefit at all from domain-specific download sharing. (Unless the original source plays cdn games that breaks proxying that is) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To u

Re: Deprecating SCP

2020-11-02 Thread Nicolas Mailhot via devel
uld not care less about TLS negociation, as long as the resulting recipe is steong) User attachment to different tools is a legacy of other OSes where one protocol is built in and the others not. Regards, -- Nicolas Mailhot ___ devel mailing lis

Re: The future of legacy BIOS support in Fedora.

2020-10-20 Thread Nicolas Mailhot via devel
model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz model : 142 model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz Hardly an underpowered system -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To uns

Re: The future of legacy BIOS support in Fedora.

2020-10-20 Thread Nicolas Mailhot via devel
efore the 64bit-ed Linux installed base get outperformed enough to be retired Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora

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

2020-09-29 Thread Nicolas Mailhot via devel
-like IPC not depend on libs that may or may not have the correct legal or language requirements Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora

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

2020-09-01 Thread Nicolas Mailhot via devel
ry symlinking games. More complex because upstream Go modules permit submoduling, so submodule roots will be buried deep inside the expanded archive tree. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To un

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
ing cost of more English variants is their footprint in language selectors Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

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
hardware is an additional external expense. IOT manufacturers are first and foremost hardware people, they sell devices not bags of bits, they know how to make hardware as cheap as possible, and how to market hardware features so the marginal cost does not cost them a dime. Regards, -- Nicola

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
g. And those buttons will keep working far after the IOT manufacturer will have screwed up the software update part. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedo

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
rtificate of this remote point, has zero need for secure boot. -- 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.fedoraproject.

Re: The future of legacy BIOS support in Fedora.

2020-07-10 Thread Nicolas Mailhot via devel
hardware-side. Leading to vast deployments of abandoware. A lot of things, starting with the DRM target that funded secure boot, would not exist if manufacturers were serious about updates, because those systems are increadibly brittle and incompatible with a long term support v

Re: Btrfs by default, the compression option

2020-07-10 Thread Nicolas Mailhot via devel
Facebook relies on to make btrfs corruption non events, were available workstation side. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of

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
doing their parts. Regards, -- 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.fedoraproject.org/en-US/project/code

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

2020-07-08 Thread Nicolas Mailhot via devel
bump from here' info between builds. Regards, -- 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.fedoraproject.org/en-US/

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
ing editing the boot CLI). Otherwise you end up in keypress & display timing hell (not to mention that non-qwerty users have the additional hurdle of guessing where keys are mapped, which is why using anything except escape/space and function keys will break hard in the field). Regards, --

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

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

2020-07-06 Thread Nicolas Mailhot via devel
to admit I am biaised. Had I not been convinced it was the right approach, I would not have invested the coding time in the first place. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsu

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
se for patches), but that could be changed if people wanted it changed, and is an artefact of the general mess sources and patches are in rpm, with layers over layers of confusing things named almost the same, but not exactly the same. Regards, -- Nicolas Mailhot __

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
wrong with writing a spec for things not specified yet, quite the countrary. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

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 >

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 build

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

2020-07-05 Thread Nicolas Mailhot via devel
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Cond

Re: The future of legacy BIOS support in Fedora.

2020-07-04 Thread Nicolas Mailhot via devel
r’s experimental system with current year’s experimentalk system because nothing had settled yet. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code

Re: The future of legacy BIOS support in Fedora.

2020-07-04 Thread Nicolas Mailhot via devel
art up) Regards, -- 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.fedoraproject.org/en-US/project/code-of-conduct/ List Guid

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

2020-07-04 Thread Nicolas Mailhot via devel
th people not in your own timezone. Reagrds, -- 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.fedoraproject.org/en-US/projec

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 c

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 m

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

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

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
the git (or hg, or svn, or…) command, it’s a pure URL munger, so it won’t pull in your scm of choice in the buildroot. Presumably your workflow is so git oriented your local setup always has git installed. Regards, -- Nicolas Mailhot ___ d

Re: The future of legacy BIOS support in Fedora.

2020-07-03 Thread Nicolas Mailhot via devel
ora downstreams (as AWS and others already did). (this is not an endorsement of any other position in this thread, I hate all our bootloaders equally, they’ve been a lost cause since someone decided to hide the bootloader menu in the default install, makin

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 to

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

2020-07-03 Thread Nicolas Mailhot via devel
e server setup with systematic backup/restore procedures. For workstations? Even in an Enterprise context? Not so much. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an ema

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
build features that were devilishly hard to implement before something like %auto_call was available, and is pretty simple to do with %auto_call implemented Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscri

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 i

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

2020-07-02 Thread Nicolas Mailhot via devel
because tuning a production process is more than the "it works" POC stage, but that’s tuning, not reconception). Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email t

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 m

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 s

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
ping rpmbuild results as usual and exposing them to users. Regards, -- 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.fedo

Re: python-sphinx_rtd_theme update: comments requested

2020-07-01 Thread Nicolas Mailhot via devel
king the browser walk a remote location is not good for performance and will have all kind of interesting effects in restricted networks Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe se

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
lone when reinstalling, while someone always seems too invent a new Fedora change that justifies the reformatting of /. Good luck dealing with user data the next time workstation (or any other group) feels the / filesystem should change, once you've put user data on the same mount point Regards

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
, anyway. It'd be similar to the > existing %packager macro, too. This is certainly doable and will simplify the code. Therefore, I will do it. I was formatted by the way name and email are separated in .gitconfig Please ask any other technical question you may have, they are helping me to mak

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 à 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 discussion,

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
t; redhat-rpm-config will be updated to add patching support to forge > > macros, a plug-able framework to register macros to execute in > > specific sections, and rpm changelogs in detached files. > > > > == Owner == > > * Name: [[User:nim| Nicolas Mailhot]] > &

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
mething. And, the last time a problem occurred, it was traced to an undocumented and unannounced rpm change that no one knew how to fix rpm-side, and that you spent more energy proving it need not be fixed than on constructive solution-finding. I freely admit that my code suck

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

2020-06-30 Thread Nicolas Mailhot via devel
dware vendor did not test fully, does not bode well for the reliability of the integrated software+hardware system. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedorapro

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

2020-06-27 Thread Nicolas Mailhot via devel
not have an IT organisation to back it up in a professional way. -- 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.fedorapro

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

2020-06-26 Thread Nicolas Mailhot via devel
rformance points over the competition. Therefore, using btrfs in Fedora, is inherently more ambitious, than using it at Facebook. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le

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

2020-06-26 Thread Nicolas Mailhot via devel
their own boot in the process. Thus, Anaconda EFI support is terrible period. -- 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:

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 gi

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 gi

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

2020-06-25 Thread Nicolas Mailhot via devel
). -- 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.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https

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

2020-06-24 Thread Nicolas Mailhot via devel
tructs like safeset (in redhat-rpm-config’s common.lua) that check if the packager already set things to other value before blindly stomping over them Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscrib

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 t

Re: RHEL 9 and modularity

2020-06-24 Thread Nicolas Mailhot via devel
pendency manipulation verbs we have evolved over the years for Provides and Requires. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fed

Re: RHEL 9 and modularity

2020-06-24 Thread Nicolas Mailhot via devel
s of complexity modularity requires at the component creation stage. Regards, -- 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://do

Re: how to correctly remove a subpackage ?

2020-06-12 Thread Nicolas Mailhot via devel
ople who request application of rpmlint messages without understanding their meaning will want you to add the provides even when the provide part is not actually provided in the new version. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.f

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
ate right now (no modules = no storage, no input, no nothing) -- 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.fedora

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 handl

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

2020-06-09 Thread Nicolas Mailhot via devel
s to > bootstrapping conditionals, because that seems to be the use case? One use case is bootstrapping. Another is just getting things to build till you have the time to investigate if a new test failure is an actual problem or upstream being careless as usual. There are probably other use cases

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 > > > > > > https://docs.fedorapr

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

2020-06-09 Thread Nicolas Mailhot via devel
time. 2. the fact you can not ask koji or mock for a bootstrapped build, you have to change the spec manually -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fe

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

2020-06-08 Thread Nicolas Mailhot via devel
r upstream’s own code sure, but for everything else (legalities, the tird party code they depend on, build systems and automation) certainly not. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To un

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

2020-06-06 Thread Nicolas Mailhot via devel
ith magic ephemeral rawhide-only packages) See? Easy to find faults in other people’s work -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduc

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

2020-06-05 Thread Nicolas Mailhot via devel
packages build with test disabled, then redo-it with tests and sift through test results to see what is actual breakage and what is broken testing code The people who release poor unit tests also change their dep graph at high speed, poor unit tests go hand in hand with regular re-bootstr

Re: Location of executable code

2020-05-22 Thread Nicolas Mailhot via devel
d mix things. Like systemd and rpm did for multiarch. So if you care about security you’ll still need to audit the non-executable root. Except the audit will be less painful, because a lot of stuff would have been sorted by others. Regards, -- Nicolas Mailhot ___

Re: Location of executable code

2020-05-22 Thread Nicolas Mailhot via devel
years ago. :-) It got truer since. The IA stuff people want to replace traditional computing with is 100% data-driven execution. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscrib

Re: Location of executable code

2020-05-22 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. Be

Re: Location of executable code

2020-05-22 Thread Nicolas Mailhot via devel
the past. So, no use looking for non-executable /usr/share. A lot of /usr/share is executable and will stay that way. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an emai

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

2020-05-21 Thread Nicolas Mailhot via devel
kages. BTW, that’s not a Fedora project limitation. The whole GNOME stack has been trying for years to reduce the combination complexity, by forcing the use of a limited number of stacks/runtimes. -- Nicolas Mailhot ___ devel mailing list -- devel@l

Re: Re-Launching the Java SIG

2020-05-18 Thread Nicolas Mailhot via devel
The difference, is that you can build a new kernel, while running an old kernel. the kernel is not constantly breaking external kernel APIs like gradle breaks the external gradle APIs a new gradle needs to be built (when building gradle with gradle, the new build is a consumer of external gra

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

Re: Re-Launching the Java SIG

2020-05-16 Thread Nicolas Mailhot via devel
ithout paying someone to copy and fork the original code that this bytecode was generated from in the next project. The practical effect is technical stagnation and market capture by deep pocket companies. -- Nicolas Mailhot ___ dev

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

2020-05-16 Thread Nicolas Mailhot via devel
me upstream git, we are hopping between branches in different forked repos of the same upstream Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora

Re: Re-Launching the Java SIG

2020-05-14 Thread Nicolas Mailhot via devel
lls today did not notice? The next generation of corp-funded enterprise code will use another language. Sincerely, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproje

Re: Re-Launching the Java SIG

2020-05-14 Thread Nicolas Mailhot via devel
al from a technical POW, its tooling is poor sure but tooling reflects the values of the community creating and using the tools, not the reverse. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: New set of questions for FESCo candidates?

2020-05-14 Thread Nicolas Mailhot via devel
organisational thought, to be able to handle gracefully objective divergences. Because those divergences *will* eventually happen, and inventing a process at crunch time when things are on fire and everyone is too busy dealing with the fire to listen to others, is no fun.

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

2020-05-10 Thread Nicolas Mailhot via devel
was actually build in what order. That can never work reliably. Just bite the bullet, builds are controlled by the build system, no one *but* the build system can record them accurately in Fedora git. Regards -- Nicolas Mailhot ___ devel mailing list

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

2020-05-06 Thread Nicolas Mailhot via devel
impossible to contribute to independently without cloning its complex closed garden environment. Every Fedora package has a dual upstream, the source project for the project code, and Fedora rpm/macro enhancements for the spec code. Regards, -- Nicolas Mailhot

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

2020-05-04 Thread Nicolas Mailhot via devel
lease will probably error not warn on those. warning: undefined macro(s) in %{_sourcedir}: …/rpmbuild/SOURCES/%{name} You may fool things for a while with the %_rpmtopdir + %{?name:%name} but I doubt that will survive the purge long. Regards, -- Nicolas Mailhot __

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

2020-04-30 Thread Nicolas Mailhot via devel
route, it was not their best decision. Regards -- 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.fedoraproject.org

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 >

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 py

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

2020-04-30 Thread Nicolas Mailhot via devel
ampire is probably not, vnumericsomething may be a version with some made up pre/post release garbage at the end, or something else entirely. All because Linus did not bother defining a clean version separator but reused the v letter, because “it was obvious”

  1   2   3   4   5   6   7   8   9   10   >