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 sharing of the same firmware is useful. Maybe
> make that configurable so the network/system admin can make the
> decision for what's best for their usecase?

This king of corporate datacenter network will proxy system downloads
(more to detect attacks than 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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 something you would like to see in Fedora
> > > soon? Do
> > > you have something against this? Is your use case missing?
> > I like it!  scp-the-tool (including command/filename completion!)
> > is
> > just so much nicer to work with than sftp-the-tool.
> Well, thats a nice feature requirement, almost forgot about it.

Well lftp-the-tool is even better. And they all do the same thing from
a functional POW, only the underlying protocol changes. This is sad,
the user wouldn’t care less about protocol differences (as he would 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> consumes 500 MB of memory and after logging in Gnome shell for user's
> session
> takes another 500 MB. SDDM becomes insanely graphics-demanding. The
> QML
> backend first started polling old Intel VGAs, then spits flickering
> artifacts
> on old Radeons. Regarding feature-parity it completely looses to KDM
> (no XDM,
> broken PAM with non-password authentication mechisms, it even became
> a blocker
> for F33).

The worst thing is that was done as the same time that wayland moved
input management to the window manager. Any random GUI action can now
result in feel-good GUI prettification that will starve input
processing of CPU, resulting in frozen mouse pointers and missed
repeated or reordered keystrokes.

So, useless desktop except as a browser shell where typing is marginal.

> journalctl | grep gnome-shell | grep 'libinput error' | grep 'your
system is too slow' | wc -l
7060

> cat /proc/cpuinfo  | grep model
model   : 142
model name  : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
model   : 142
model name  : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
model   : 142
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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 missed its 64bit conversion.
Previously, you could always add a couple of years of useful lifetime
to a computer just by adding some memory (because memory is one of the
key parameters manufacturers skimp on). But, once most of the market
got stuck in 4GiB land due to Windows limitations, you could suddenly
add a decade or so of lifetime just by using the fact Linux was 64 bit
to grossly outscale the default Windows-oriented memory setup.

Now the gap is slowly shrinking now that Windows is 64bit and
manufacturers learn to use memory again. But it will be some time
before 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 Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 DNS. For SMTP, HTTP, etc.

The modern way of coding apps is minimal marginally-compliant and secure 
built-in network client (so things sort of work on the dev system and in 
CI/CD unit tests), with the OS interposing a full-featured protocol 
proxy in “production” deployments.


The problem is that this software dev trend conflicts with the 
traditional end-to-end IETF view. When the end-to-end view wins you end 
up with a single canonical network client like chrome or firefox because 
coding a full-featured secure network client implementation is hard and 
devs want their apps to do network-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 Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
ipp-usb.service or udev rule file 71-ipp-usb.rules.

I managed to package those files with following install command e.g.:

install -m 0644 -vp
%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb/systemd-udev/*.rules  
%{buildroot}%{_udevrulesdir}

but '%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb' is quite ugly -
is there a predefined golang macro for such path? Or a best practice?


You do not need that at all in most of the spec, the usual workdir is 
the root of the upstream zip. The complex path you posted is (painfully) 
symlinked to keep go tools happy in GOPATH mode, anything which is not a 
"go foo" execution can happily ignore it and just work from the current 
directory. But if you do need an absolute file path or already changed 
dir somewhere else '%{gobuilddir}/src/%{goipath}' is likely to be close 
to what you want.


The next gen of Fedora Go tooling will be both simpler and more complex.

Simpler because in Go module mode we can drop completely the horrific 
mandatory root dir renaming to url, adding a src prefix. So in most 
cases we will just work from the archive root like other languages, 
without playing brittle directory 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 variables. Very boring
> > KISS
> > stuff.
> 
> Sure, but a file with 16 spaces and a newline is pretty confusing.

I will add a line of comment instead. The confusion is due to the fact
rpmbuild wants source files to exist before the build starts, and wants
them to be more than 13 bytes. I thought filling with spaces would
convey the empty file idea, I was wrong, adding a comment is trivial
and the parsing code is robust WRT comment lines, so no biggie to
change and improve.

Thank you for the enhancement suggestion!

> But then you know that exact thing was built. 
> With this setup you look at the git hash in koji and... it's the next
> commit after that thats exactly this build? Thats really messy.

The system separates build commits from modification commits.

It’s not like right now when most commits are modification *and* build
commits, except when they are not (because the change was done in
several commits, because the build failed but git still pretends it
occured, because a branch was EOLed before the modification process
finished, because the commit tracked a build that did not pass bodhi
gating, etc etc.)

The proposed system is a lot more clear and strict, for a build to be
tracked in git it needs to have actually succeeded and be commited
back, anything else is packager WIP. Making git history something you
can rely upon.

> Right, I was suggesting _changing_ your macros for this workflow. 
> 
> maintainer makes changes, runs scratch builds, tests, etc.
> They decide everything is good for an official build. 
> They generate the files and the macros just use those generated
> files,
> they don't bump anything or require a post build checkin.

You do not need to change the macros for this workflow, they already
support reproducible replay. Just prepare your build out of band and
then ask to build it in reproducible mode.

That only requires buildsys support to set the variable that activates
reproducible mode, and buildsys or packager support to make sure the
buildroot content matches the test builds (macros can do a lot of
things, they can not manage buildroot state in stead of the build
system).

However what this amounts to is the following:

1. build packages in scratch mode
2. check
3. commit
4. rebuild scratch builds in reproducible mode

That is more complex than the target workflow in the macros

1. build packages
2. check
3. decide to keep the packages, and commit back

The second workflow is more reliable than the first one, because the
second preserves the packages you tested, instead of hoping nothing
changed in the buildroot between the two build steps.

Of course doing it in 3 steps requires pairing back commit with bodhi
gating, absent bodhi changes it will probably be more involved at
first.

But the fact is it *can* evolve to a 3-step process with infra help,
and the evolution is consistent with what we’ve been trying to achieve
in the past years, and the current 4-step process is also supported at
macro level, as long as fedpkg/koji learns to set one variable (*not*
rocket science). And setting one variable is no different from the
generic bcond stuff ELN people want to happen.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 
> the distribution. Why would British be any more worth shipping than
> any other language out there?

Practically some people do care about original English. And, there is
little to win deployment side, all those spellcheckers share a common
trunk, the only annoying 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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump
> > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/
> > 
> > I fleshed out the change page a little too
> > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping
> 
> So I finally carved out a few minutes to look at this, but... 

Thank you for taking a look at it

>  
> https://copr-dist-git.fedorainfracloud.org/cgit/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/sil-charis-fonts.git
> seems to not exist? Is that some copr issue?

I honestly do not know. The copr was created with a mass import of
srpms themselves created by rpmbuild -bs. I mainly use copr to check
the srpm I build locally in mock work in another system before feeding
them to koji, so I never used the git part of copr much.


> Looking in the src.rpms I see some of the files I want to look at are
> oddly empty? 
> 
> ➜  ~ od -c rpmbuild/SOURCES/buildsys.conf
> 000  \n
> 016
> 
> Is that because it's the 'before' src.rpm without the version
> information injected yet?

Yes, almost all of the srpm have not been bumped before they were fed
to copr, so they only include the minimal whitespace necessary for
rpmbuild to register them as sources (the evil "your source is less
than 13 bytes" rpmbuild assertion).

IIRC, I scratched sources for most of them to check the new spectool
had not problem with the specs, so they won’t have any bump history in
them.

You have an example of bumped srpm in adf-accanthis-fonts (with an
almost full buildsys.conf though this package do not use the postbuild
counter). 

>  Might be nice for these files to have a small
> doc block at the top?

The detached changelog – certainly not, that would complexify its
maintenance quite a lot. The conf file, why not, that’s fairly trivial
to add.

Tough it is a litteral key = value file with no fancy formatting nor
even ini-like sections, and a handful of variables. Very boring KISS
stuff.

> Or at least the wiki page could explain each file,
> whats in it and whats the format for it. 
> 
> I really dislike having a second commit to say 'yes, this build was
> the last one'. Could you generate that info in advance and just
> commit it before the build? 

Well I really dislike people who commit that a build happened when it
has not yet, and who rewrite git history multiple times to "fix" when
they guess wrong:) Or worse, who do *not* rewrite git, and have a
changelog that clearly does not correspond to their build history.

The release part of autobumping will only happen if the spec needs it.
ie if the release the packager stored in the spec already makes the evr
newer than the last recorded evr no bump will happen. Changelog, not
sure, I suppose I could tie it up to release bumping so if one does not
happen the other does not happen either (that would make the code more
complex, but not too hard to add).

However, is not possible and it won’t be possible to pre-fill
buildsys.conf because the decision to bump or not is made by comparing
the current evr to the one stored in there. So if you pre-bump the
file, the logic will decide you have already done the corresponding
build (which, if I follow you correctly will be *true*) and add another
release bump to make sure two consecutive builds in a branch have
different evrs.

Basically, what you want is to reproduce a build you already did some
other way. Then just set the variable that triggers reproducible mode
and you’ll be done (that would require koji/copr cooperation however).

If anything changed in the buildroots you build against your build may
fail the same way it fails today, and your git and changelog will be a
lie the same way they are a lie today, but I guess than is that mode
that’ll be what you want.

There is no miracle, pre-filling means build roulette and bumping
mistakes. The proposed system is reliable because nothing except
rpmbuild itself records that a build actually happened in sources.

The change is quite simple and robust code wise but it turns people
assumptions on their head. It is *real* autobumping and not the
approximations they are used to.

In a real autobumper setup you do not pre-bump manually, anymore than a
real automated ansible setup you do not mess manually with the target
systems before you run your playbook. You can pre-mess manually a

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 already builds a
ton of such things. A physical button is a on-of, a digital key
infrastructure is years of expensive maintenance and updates to keep
going. And as you noted they have to include physical bybass for other
reasons.

You’re used to computing costs as a software person, where 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,
-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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
> > 
> > The %bid macro is definitely meant to be usable with any build
> > system,
> 
> That won’t work unless you persist the %bid state so the next build
> systems knows where to pick up from. And persisting is the part you
> do
> not like in my proposal (unless I completely misunderstood what you
> wrote before).
> 
> Making things work across build systems without persisting means
> using
> an external reference like the clock, and that only works if your
> build
> history is completely linear, without scratched branches (intended
> scratch branches or branches that do not work out, despite the
> packager initial hopes)

Also, if you do not persist, your build won’t be reproducible in a
third party buildd system, because reproducing requires knowing the
%{bid} value you used in your own build.

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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, build system
> > > tag":
> > > https://pagure.io/copr/copr/pull-request/1436
> > 
> > Well, that ties the system to corp, not koji
> 
> The %bid macro is definitely meant to be usable with any build
> system,

That won’t work unless you persist the %bid state so the next build
systems knows where to pick up from. And persisting is the part you do
not like in my proposal (unless I completely misunderstood what you
wrote before).

Making things work across build systems without persisting means using
an external reference like the clock, and that only works if your build
history is completely linear, without scratched branches (intended
scratch branches or branches that do not work out, despite the packager
initial hopes)

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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, it will just be remotely exploited at every boot, and
there will be nothing stored persistently for secure boot to block
(that is actually how some windows malware started to behave once
Microsoft added boot protections).

The other usual argument is that digital keys are cheap and physical
buttons or locks expensive. Well digital keys are definitely not cheap
once you count all the work to keep digital protections up to date and
bug free, and physical buttons are definitely not expensive. I have one
on every bargain-bin iot plug in my house, to authorise initial
pairing. 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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 function of secure boot
> > and
> > DRPM is to prevent end users, present in the update loop, from
> > doing
> > things the manufacturer disagreees with.
> 
> s/manufacturer/device owner/

Nope, manufacturer. There are hundreds of other simpler ways to protect
device owner side (physical locks on racks, 2FA auth via a physical
button on the device or an sms code, etc).

The average device is not sold with locks in the supermarket. The home
or office or building or rack door is considered sufficient
protection. 

Evil maid does exist, but applying evil maid generally would require
putting locks on everything you buy, from the drawers where you may
store sensitive documents someday, to the fridge where the evil maid
may serve herself on your precious lagger.

The threat scenario has been massively ovehyped to justify giving keys
to the manufacturers.

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 zip nada need for
secure boot in the first place. The sole function of secure boot and
DRPM is to prevent end users, present in the update loop, from doing
things the manufacturer disagreees with.

A system, that auto consults a remote update point, over https,
checking the certificate 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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 devices

That’s a joke isn’t it? The problem IOT side is not the security of the
software update chain. The problem is that manufacturers skimp on
software updates in the first place, and refuse to provide the length
of support software-side, that users have come to expect 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 view.

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> > it's quite safe.
> 
> But it has been eating data as recently as 2018 [1] and the Debian
> wiki warns strongly against using compression that is dated for 2020
> [2].  The project will already see a large number of new bugs thanks
> to the wider breadth of hardware, why throw in an additional variable
> when you can flip it on in six months anyway?

Compression will increase the risk of data loss, because compression
removes data duplication that could be used to reconstruct data in case
of corruption. If you add duplication over compression to make it
recovery-safe, the wins are not so good.

However, that is consistent with btrf’s recovery story, and reliance on
restoring from backups in case of problems.

What is the workstation backup story? I would be a lot more confident
in this change, if the things 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 Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 API, it is not possible for the macro to process an
unknown source without being taught how this particular service works.

That, basically involves writing the lua equivalent of regexpes that
contruct the variables forgesetup will use from forgeurl and
tag/commit/whatever (you can check in redhat-rpmc-config history how
pagure and gitea support was added, they’re the two last supported
sources)

So, either your need is a one-off, and you can workaround things by
setting all the variables forgemeta would have computed if it knew your
source, or it’s something generally useful for the long term, and
someone needs to add the regexpes

In other circumstances, the someone might be me, but I’m getting fed up
with everyone else in the project not doing their part and blaming me
for doing things alone. So, right now, very unlikely that I will invest
more in Fedora without others 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-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 
another (which definitely matters to me, because my packager workflow 
has rpmbuild, mock, copr and koji stages).


I honestly do not see how you can bump safely, without providing the 
bumping code the "bump from that point" information.


When you bump, you graft new release growth over an existing release 
tree. Stacking something blindly without looking upon where you stack it 
will work in a lot of cases, but will fail horribly in others. I like 
KISS but this KISS is too SS for my tastes. If linear history worked for 
a project the size of Fedora we’d be all still using CVS.


The bumping code itself is not hard to write

Serializing 'bump from here' in a format that can be reliably read later 
is also not hard (as long as you do not insist on expanding Release and 
trying to decompose it back at the next build).


The hard part is moving '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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> hotkey ('e') even.  And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.

Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).


Sure.  All bootloaders I have seen in recent years (including sd-boot)
behave that way.


I was mostly reacting to

And unlike the 'l' and 'w' hotkeys that one is actually listed if you 
hit '?' or 'h'.


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 plenty of dracut reconfiguration/upgrade
> > failures
> > over the years and the ability to edit the command line has been a
> > life
> > sacver.
> 
> See above.  sd-boot allows to edit the kernel command line too.  Same
> hotkey ('e') even.  And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.

Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
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,

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
changes of for back commits. It would have involved creating a separate
subpackage for the state payload (à la debuginfo) with past state
floating in this subpackage without ever being commited back. Much like
the koji implementation makes changelog and release state float in a
koji alternate dimension that is not Fedora git or the package sources.

I decided against it because that would have made importing from one
buildsystem to another quite inconvenient, and because it would have
added a lot of (brittle) implementation complexity.

These days my coding is very data-model driven, the right data model
means a smaller and more future-proof implementation, the fact the
autobump implementation is such a small diff shows the data model is
right, IMHO

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 package-maintainer. Currently it sits deployed in staging
> koji, so you can give it a test-drive :-)
> 
> We hope we can return to it later this year, to have it deployed in
> prod koji.
> 
> [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html

I think it is good to have alternative implementations that show what
the real consequences and costs of doing something one way or another
are.

The abovementioned implementation is tied to koji and will never work
outside koji, and involves quite a lot of spec munging (that may work
or not, I suspect it won’t work so well on my spec files for example).
And it takes a lot of moving pieces to do so.

Because the build state exists in koji only, there is no need to commit
back to git. Conversely, this is what makes it a koji-only solution
that does not export well to other build systems.

My implementation is much simpler (6 files changed. 179 lines added. 5
lines removed)
https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump

However it relies on another redhat-rpm-config change which is
definitely not simple (30 files changed. 2163 lines added. 619 lines
removed). Though probably still quite less than the whole of
rpmautospec + rpmautospec macros + koji plugin
https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/213995c8371837f3689c0d053ed055c25de287c9?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump

The other redhat-rpm-config change was done for other reasons, and
contains code to address totally different needs, and I will need it
whether the bumping change is done or not (but, I’m sure the
rpmautospec guys will state a lot of their code was also written for
other reasons).

I suspect my implementation wins on genericity and on the other
features it unlocks within spec files, while the rpmautospec
implementation wins if you want to keep things within a little team of
Fedora infra people.

I’d call my implementation more elegant, because it tries to fix things
within spec files first, and uses the fixes to make it easier to
implement higher level features. While the rpmautospec solutions tries
to take spec files as they are and force a high level feature over and
from outside a packager spec file.

But I will be the first 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 to the detached file
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping


and use that to calculate the next release field?


The changelog file is not used as source of data, except as a reference 
state that will be added to. Using the changelog file as source of data 
would require quite a lot of complex and unreliable changelog format 
parsing, so the bumping data is taken from another key = value file 
(that uses the same persistence mechanisms).


Also the packager may decide to trim quite a lot of intermediary 
changelog events, so the EVR and date in the last changelog entry are 
not necessarily the EVR and date of the last build.



Given the other replies to this thread (that this is all local only,
unless koji does git commits), does that mean that it's still: dist-git
commit = rebuild.


To be part of official Fedora history the result of a build needs to be 
committed yes. The change does not force you to build every commit, nor 
to commit every build out there.



The "only" difference to the current state of affairs
being, that I don't have to specify the Release field myself?


Once you've modified a spec, and set a starting evr point in this spec, 
further rebuilds do not involve touching the spec. Spec changes are real 
spec changes, not spec changes to bump a release or bump a changelog.



The packager does not have to request the modification in his spec,
it’s done as part of the various %auto_foo calls the change introduced


Could you provide an example how this would look in practice?


If you want a demonstration of the auto framework and of changelog 
detaching, you can take any of the non macro builds in

https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/builds/

If you want to see a demonstration of autobumping, you need to rpmbuild 
-ba manually right now, because of the two small limitations mock side. 
So you need to take the redhat-rpm-config and fonts macro packages in:

https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/

and rebuild one of the other packages in there.

The only difference between the two coprs is the redhat-rpm-config 
package, there is no change in the fonts macro package or in the 
automated packages themselves. Autobumping can be implemented without 
any spec file change once the auto framework is used.


(The mock limitations are first, the fact that mock currently collects 
the SRPM at the start, not end of the build process, and second, the 
fact you need to pass packager ID that will end up in the changelog bump 
to the build process and there is no way in the copr/copr UI do do 
that.)



What I am currently missing from this proposal though is:
- How is this actually even implemented?
- How will this look in practice?


See above ↑

- Given that additional files would be put into dist-git, how do we 
roll

  this back in case things go wrong? (Having thousands of "remove
  %autorelease" commits by releng could be an option here, albeit not a
  pretty one).


Since bumping is a feature over the auto framework, and does not require 
any additional spec change, it is enabled by registering bumping 
processing in this framework, and disabled by removing this 
registration. There is no need to change spec files or history. In fact 
I use the same spec files to QA the auto framework and bumping, and 
depending if the redhat-rpm-config version I test includes the bumping 
or not, they will bump or not.


When bumping code is not present the additional key=value file bumping 
uses is not auto-added to sources, so the next srpm import will clear it 
from sources the same way patches disappear from sources once no longer 
used (and can linger forever if a packager does not import srpms and 
does not git rm those files explicitly).


Removing the auto framework is something else altogether. Because its 
aim is to massively simplify spec files (in opt-in, not mandatory mode), 
you can not go back without undoing the spec simplifications.


However, because great care was taken to define a clean and generic spec 
syntax when using the auto framework, you could replace it will multiple 
reimplementations without changing spec files. The %auto framework spec 
API is basically


%prep
%auto_prep ← automated processing

It’s hard to go more generic than that. (You might want to remove the 
%auto calls altogether and have %prep, for example, call %prep by 
default, but that would remove the packager choice to use or not the 
%auto calls, and to insert custom processing before those calls).


The only "irregularity" is that the %auto macro

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 Fedora release logic to its ultimate
> > > > conclusion,
> > > > the thing that should be in charge of committing the new
> > > > release/changelog build state to package history in git is
> > > > bodhi,
> > > > not
> > > > koji.
> > > 
> > > Why do build events need to be recorded in the Git history in the
> > > first place? 
> > 
> > The changelog is built-in the rpm format. Therefore, it needs to
> > exists
> > at rpmbuild stage. Therefore, you need to record past changelog
> > state
> > so new builds are consistent with previous builds.
> 
> The changelog should be consistent, but it needn't record every
> single
> build event. Otherwise OBS would not work at all: the build system
> bumps
> the release field automatically on each rebuild, but it does not
> touch the changelog at all.

Well just bumping the changelog by default, and letting the packager
remove unecessary lines when he has the time to look at the changelog,
is a much friendlier workflow than asking the packager to think about
it on every single build, redoing builds when he forgot about it
because redoing builds is the only way to get a new changelog included
in the binary payload.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

That’s several orders of magnitude better than the usual my code is the
best, copy whatever undocumented thing I did by accident in my last
commit, this is the reference implementation, I won’t commit to
anything and I will change it at will without notification in the
future.

Thank you Lennart for understanding what we meant when we asked you to
engage with standards like the FHS years ago, and for not embarking
upon blackbox unspecified coding.

We all hate writing documentation and formal specifications are among
the most exhausting documentation one may write.

And, nothing 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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 necessarily the one you want to keep.

(This is why git is not relying on timestamps to construct commit
timelines, for example. A reliable timeline system knows what change
occured before the next one.)

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 state to package history in git is bodhi,
> > not
> > koji.
> 
> Why do build events need to be recorded in the Git history in the
> first place? 

The changelog is built-in the rpm format. Therefore, it needs to exists
at rpmbuild stage. Therefore, you need to record past changelog state
so new builds are consistent with previous builds.

You may argue that the existence of scms like git makes built-in
changelogs irrelevant. People that have to debug problems in systems
that mix packages sources will disagree – they have no wish to comb
multiple external scms to find what was changed in a package set that
breaks (hard to do when the thing that broke is networking for
example).

And, even if you removed completely the changelog from the rpm format,
you’d still need to manage package releases.

> So why is NEVR required to change when nothing in the package source
> has changed? 

The NEVR is required to change because you need to publish a new
package ID to clients, so clients know they have an update to deploy.
That has nothing to do with koji limitations, it’s a requirement or the
rpm update system, or pretty much any change management system for that
matter.

> It seems that several problems would just disappear if a rebuild
> would generate a unique package ID without a Git commit.

That’s exacly what the change does.

> Here's an idea: We could mandate that Release must expand a macro
> called buildtag. This macro would have a new value every time,
> monotonically increasing. A timestamp seems easiest, but that should
> bean implementation detail that could be changed without breaking
> things.

Because things are slightly more complex than you think they are, the
counter is not just a timestamp, and there are two not one counter, but
yes, again, that’s exacly what the change does.

> (The build time is already stored in packages, and could
> theoretically be used to tell builds apart, but that would require
> changes to lots of tools I guess.)

The build time by itself is not sufficient because you have branches,
and scratch builds (which are basically abandonware branches) so
parallel package history exists and a single monotonic timeline can not
represent that.

Nevertheless the last build time is useful (for changelog bumping, if
nothing else) and is one of the things the change stores as past state
(you could try to deduce it from other things, but why bother, a
timestamp variable is cheap and easy to manipulate).

> Mass rebuilds would no longer make any Git commits. They would just
> take the latest version and submit it for building. 

Again, that’s basically what the change does. A build stores counters
and date as they existed as the time of the build in one of the SRPM
source files. The next build reads this file and computes a higher
release. No external bump script involved. No spec file change
required. The spec file can be left unchanged forever, the release info
in there is just the last release someone made a change to the spec
files, and everything autobumps from there.

All you need is to pass the "last build" info from one build to
another, which is done via importing the results of last build at the
start of the new build. Since the import relies on SRPM content and
nothing else you can even move the build chain from one buildsystem to
another it will still work. 

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 necessarily the one you want to keep.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 %buildsys_packager instead of two?
> You're always using them together, anyway. It'd be similar to the
> existing %packager macro, too.

This is now done in the latest code refresh and in the test copr
https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/

I fleshed out the change page a little too
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 Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-04 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 in use in
. That’s a very misleading assumption to make, computer systems
have matured a lot, and hardware lifetime has gone up with this
maturing (much to manufacturer’s despair, the maturing is starting to
affect smartphones now).

It’s no longer early days when you replaced last year’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 of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-07-04 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 software is
ancient. That does not mean it is ancient at the start of the system
lifecycle (I’ve seen crazy people building such systems from a Fedora
image, because they knew they would accumulate enough technical debt
during the system lifecycle, without taking the centos debt from the
start 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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 people keep bolting new workarounds over old
workarounds insteak of fixing it once and for all. The original lua
integration in rpm was justified by the needs of the %sources macro,
that’s not an accident).

It is unsafe to use % for anything except rpm macro calls in a spec
file, unless you escape it with % first.

As for date, you’ll be generally better using a standard like --iso-
8601 or --rfc-3339, even if that means a lua gsub pass to replace
characters rpm does not like, than inventing your own. And don’t forget
the -u flag or you’ll have surprises as soon as you start working with
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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_ already added in my referenced spec:
> 
>   BuildRequires: git

Then you probably hit one of the cases where the SRPM is prepared
before the full buildroot is assembled.

That means you may need to make sure to enable the container option in
copr (it’s default in mock now but IIRC copr lags a bit) and probably
add some conditionals to your code so it does not error out if executed
before the full buildroot is assembled.

Generally speaking, there’s no reason a spec that buildrequires
everything it needs should not execute in mock or copr, but you have to
be extra careful with preamble macros, because preamble macros are not
executed once but multiple times during a build.

Because BuildRequires can be generated rpmbuild needs to execute the
preamble to check what BuildRequires exist, therefore a preamble macro
should fail gracefully when one of its BuildRequires is not available
yet.

(A good way to discover how convoluted this part is is to add some
%{echo: markers in a working spec and look when the echoes trigger in a
full mock/copr build).

If you don’t care you can force a specific buildroot in mock/corp
configuration, of course.

> > dead stupid (so stupid
> 
> Let's chalk that up this time to 'lost in translation', shall we?

That was a compliment, actually, the only reason the humain brain does
not see stupid mistakes is that you’re asking it to operate at another
level. Computers are dumb as a brick and have no problem seeing all the
dumb little things the humain brain optimises away.

> There _is_ no "so oriented" or "always" workflow.  

You’re formatted like we all are by your past experiences. Just because
you did not read about a pattern in a book, does not mean you are not
following a pattern, because you’ve been exposed to the work of others
that followed the same pattern (knowingly or not).

Regar,ds


-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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, and the
> > change
> > makes the forge macro code modular enough the second level will be
> > auto-registered in sourcelist, but how is the buildsystem supposed
> > to
> > provide sources that did not exist during its first pass over the
> > spec
> > file?
> 
> Possible.  But I personally think that "dynamic buidlrequires" should
> stay
> working with BuildRequires, not Sources.
> 
> > and Fabio’s most excellent rewrite of the spectool code (if you
> > have
> > not used it yet, try it, it’s good). However someone needs to add
> > lookaside or buildsys integration to spectool to spectool so
> > spectool
> > has something to source new sources from in a restricted build
> > context.
> 
> Let me just state my opinion that I don't like this situation coming.
> Packaging should be simple task, and should be made simpler, obvious.

I understand. There is just this huge pressure in npm, and go and rust,
and all other modern languages, and even in git itself via submodules,
to create huge dependency graphs of interlinked components.

You can attempt, like we (me at least) to make individual component
packaging as easy and cheap as possible. That still costs you one spec
file per git repo, and forces you to treat git submodules as separate
projects.

It is possible the pressure will continue to grow to a point that a
spec needs to automate not just the top-level component but all the
other bits upstreams hide bellow this component. If that happens we
will need dynamic sourcing in spec files. There is huge pressure EL
side at least to get this second scenario to work (in part, due to EL
management putting hard constrains on introduction of new srpms,
forcing EL packagers to stuff as many things as possible into existing
spec files).

The requester is clearly attempting the second approach.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 in the changelog in a separate
> > > key = 
> > > value
> > > file (with the components of the build evr, the last packager id,
> > > etc).
> > 
> > Do you mean that the key/value file will be committed to Git from
> > inside
> > Koji? Do the Koji builders have write access to Git?
> 
> This is the part that worries me a little about this approach.
> Builders currently do not have commit access to git and I'm not sure
> if we want them to considering they have git installed (so they can
> clone) as well as access to all the packages in dist-git from a
> networking point of view (again so they can clone).
> So if we were to give the builders commit access to dist-git, an
> attacker could easily commit to any other packages, potentially from
> something as easy as a scratch-build.

From a purely architecture POW I’m convinced the proposed approach is
the correct approach. Anything else proposed so far involves:
  – tying a low-level event like "build occurred at date XXX" to high-
level Fedora infra (making our workflow non portable and 
incompatible with downstreams and third parties)
  – taking bets in git that a build will occur and succeed (before it 
actually occurs and succeeds, in real life builds fail for various
reasons), and
  – attempting to munge spec file behind the packager back (unlikely to
work fine the more automated and dynamic we made those).

However, because it’s the correct architecture solution, it also forces
to make hard architectural choices, instead of mixing unrelated things
in git and pretending that makes the result fine. Mixing unrelated
things in a pile of container or git poo and pretending the result is
fine is exactly what I hate in contenerish build workflows and why I
work on rpm packaging.

From a pure high-level view, the thing in our infra that gates builds
and decides whether they are official or scratched is bodhi.

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 state to package history in git is bodhi, not
koji. And you can put security related checks there, since deciding to
push things to users requires security related checks anyway (that
probably also involves branching while a bodhi update is in flight and
not approved yet).

However, that’s if you want to push the model to its ultimate
conclusion and have something nice solid, automated, and future-proof.

If you don’t want to touch bodhi, and it you do not want koji to commit
to git (which, is not the best of things for the reasons you stated,
and for the reasons I stated), you can just:
– make the koji client return the URL that will contain the SRPM at the
  end of the build process if it succeeds.
– have the person of script that called the koji client (and has,
  presumably, write access to the corresponding packages) consult the
  build results later
– and have this person or script decide if he or it wants to commit the
  build result to history or not

That’s the REST way of doing things. It’s a co-out because you push
hard commit decisions to the client, but it’s a prefectly valid
approach. The commit decision exists with or without my change, it’s
just people have (successfully) convinced themselves git is magic and
git makes release decisions go away.

You could also try to filter source files to limit the back commit to
specific files. But really, if you don’t trust your build process to
modify files in a secure way, you should not distribute the produced
RPMs in the first place.

> rpmautospec relies on git tags to store the build info, could it be
> considered here?

As explained above, that does not solve any of the hard problems, that
handwaves them away by pretending that because someone filled some
metadata in git, it corresponds to the actual build state.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> > > devel wrote:
> > > > If there is buy-in, it will be implemented by goodwill people.
> > > > If there
> > > > is no buy-in, it won’t, normal community development process.
> > > > Put
> > > > yourself in the category you want to be in, your choice, not
> > > > mine.
> > > 
> > > I believe that Change submission guidance is pretty clear on
> > > this:
> > > 
> > >    "If you have improvement in mind, work to get implementers
> > > committed
> > >    to the effort _before_ filing a Change proposal, rather than
> > > expecting
> > >    them to show up for work once the Change is accepted."
> > 
> > This is a F34 Change (not that it could not be done for F33 if
> > people were willing). 
> 
> This is apparently something that was missed, just by seeing the
> subject of this
> thread.

Yes, sorry, I see our dear release wrangler missed that I was crazy
enough to submit both a last-day F33 change and a prospective F34
change (both dealing with essentially the same codebase).

It’s a F34 change, anyone can check in the wiki history it never
pretended to be anything else.

Now it is doable for F33 too (at least on my side) by that may be
overly ambitious infra-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 Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> 
>   https://www.diffchecker.com/izjQYkUF
> 

The fail log is full of

sh: git: command not found
sh: git: command not found
sh: git: command not found
sh: git: command not found
sh: git: command not found
sh: git: command not found
sh: git: command not found
sh: git: command not found
sh: git: command not found

You added some processing that depends on the git command (that
forgemeta does not use) but forgot to BuildRequire the package
providing that command.

As stated before forgemeta does not depend on 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
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> > stop
> > updating, and likely move to something that is still supporting
> > BIOS,  if they
> > don't write their own installer and just continue using Fedora,
> > given that
> > this is an entirely artificial limitation.
> > 
> While I completely hear you on the fact that people will often sweat 
> assets for years longer than accounting schedules suggest they
> should, do you really think they're going to write custom
> installers??? 

They’re going to move to forks of Fedora 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,
making it something that does not exist… till you need it an realize
the state it’s in).

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 be in, your choice, not mine.


I believe that Change submission guidance is pretty clear on this:

"If you have improvement in mind, work to get implementers 
committed
to the effort _before_ filing a Change proposal, rather than 
expecting

them to show up for work once the Change is accepted."


This is a F34 Change (not that it could not be done for F33 if people 
were willing). It was filled at the same time as the F33 change because 
it’s the logical continuation of the F33 change and people were sure to 
ask about it in the other change discussion (as they did).


I believe a full cycle is largely enough to get people used to the idea 
and committed or not. It was split from the F33 change to give this 
cycle for things to mature.


The F33 change is continuation of work I began in 2017, and has served 
Fedora well since, and the same objections were raised against the 2017 
change, and the same empty promises were made by naysayers that they 
would do better someday, and 2+ years later no one has seen any part of 
their alternative implementation in real life (laughably, some of the 
naysayers complained it was not documented well enough, and blocked the 
documentation merge later when it was provided). Also the naysayers are 
not the ones that would do the implementation since no one sane would 
count on them to do anything anyway.


The work is done, anyone can get the SRPMS in the copr and check by 
himself that they do autobump and auto changelog, there are minor 
blockers because the feature changes slightly the point at which the 
SRPM should be collected in the build process, but they are *minor*, not 
anything that requires a huge re-architecture of current tooling.


Which is pretty cool because current tooling was not designed around 
this feature, and yet it works fine, with minor adjustments.


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 spec, of
course you should never depend on Internet ability. For you own needs,
both mock and copr allow enabling the internet. forge macros do not
enforce a specific policy.

The main showstopper will be that if the additional commands need to
process files in sources, you need to run %prep first, and %prep
depends on sources being set, so you’ll be in a chicken and egg
situation.

Now, we’ve been moving to more dynamic spec contruction in the last
years, so I can see it being possible in the near feature if everyone
makes a goodwill effort, but right now that is not possible.

With the dynamic buildrequires part rpm upstream added, and with
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

it will certainly be possible to compute a second level of sources
during the dynamic buildrequires first pass over prep, and the change
makes the forge macro code modular enough the second level will be
auto-registered in sourcelist, but how is the buildsystem supposed to
provide sources that did not exist during its first pass over the spec
file?

That probably involves running spectool by default over %sourcelist at
the start of %prep, which, again, should be doable easily with 
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

and Fabio’s most excellent rewrite of the spectool code (if you have
not used it yet, try it, it’s good). However someone needs to add
lookaside or buildsys integration to spectool to spectool so spectool
has something to source new sources from in a restricted build context.

If anyone is interested in doing the spectool/buildsys integration
part, we can fill a change for F34. It’s another example, like
autobumping, of high level 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 side tag, whatever). Koji is still in
>> charge, the bumping is just integrated in the build process with the
>> rest of the package creation.
>
>Koji was just an example. %changelog section should be auto-generated
>from commits messages. I don't want to maintain a separate file with
>the changelog.

The feature is completely compatible with this workflow. 

It registers build events in a detached file (the only part of the rpm 
changelog that requires knowledge of the rpm format)

You can prime this file via git hooks or any other system you like, the feature 
will take it as is, add the timestamp the build occurred at, and feed the 
result to the correct parts of the rpm build process.
-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 the category you want to be in, your choice, not mine.


Implementation is moving the call to SRPM creation at the end of the 
build process instead of relying on the SRPM as it existed at the start 
of the build process. So, while it is work, it is not complex work (I’m 
sure there is more than that 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 to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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` time with other files rpmbuild
modifies.


I don't like that. %changelog should be generated automatically on 
Koji

side.


Why? Koji schedules a build.


No, Koji also builds the SRPM, via fedpkg-simple or a similar 
mechanism.


Sure, by build I intended both the deployment packages and the SRPM.

The main difference between the current workflow (the reason it fails in 
mock right now, but that should not be too hard to fix) is that the SRPM 
that includes the build info is itself a result of the rest of the 
build.


That seems the main point people misunderstand (thank you for making me 
clarify it), the proposal does not involve preparing a special SRPM out 
of band, that is then fed to koji, the SRPM containing the bumped 
changelog and last build info is the result of the build process 
alongside the binary packages.


mock (and koji) just have to pick this SRPM at the end of the build and 
not use the SRPM as it existed before the build occurred.


And why is it that way? You do not consider a rpmbuild -bs a build event 
do you? We do it all the time to import packages from one system to 
another. The only thing which is a real build that produces a bump and 
is stored in changelog history is a full rpmbuild -ba build.


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 be generated automatically on
> Koji
> side.

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 side tag, whatever). Koji is still in
charge, the bumping is just integrated in the build process with the
rest of the package creation.


I think Change Page does not mention that Koji will be committing
anything to the dist-git.


It does not need koji to commit anything to dist-git. While that would 
be nice to have, the back-commit can be done by the human who scheduled 
the build, or by fedpkg, or whatever. That also means that till this 
back commit is done whoever scheduled the build can decide to scratch it 
all as a dead evolutionary branch. And you can do "I feel lucky" tests 
and forget about them if they turn out bad.


But yes, as was discussed on this list in the beginning of the year, in 
a model where bumping is infrastructure-independent and done at the rpm 
level, various infrastructures still needs to pick up the results of rpm 
builds and do whatever they want to do with them.


rpmbuild can create rpms, it can not record things in 
organization-specific systems.


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 intended to be
browsed
(possibly offline) from within Fedora anyway.

It’s not that hard to expose /usr/share/fonts in a webserver (and
pretty risk-free).


Let's consider this scenario.

The documentation is exposed on 1.2.3.4:8000 from machine A.

On machine B, I open http://1.2.3.4:8000/ in my webbrowser.
The HTML is loaded, it contains a CSS file reference.
The CSS is loaded, it contains an /usr/share/... font link.

Now I don't know if having the font /usr/share/... font installed on
machine B makes it work, but certainly, th font from machine A won't
be served this way.


You’d need to declare the font files you want to serve as a relative 
path, in your CSS files, and that relative path matches the path your 
webserver serves /usr/share/fonts at.


Not sure it is worth the effort but is is certainly doable

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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.
>
> What is “changelog bumping”?  Why is it needed?  What about release
> bumping?

Changelog bumping is the act of putting the actual release bump and
build time in the changelog.

With the change, the spec is able to self-compute its next release if
the spec file evr is older or equal to the last build event.


How does it know that "last build event"?


The same process that commits a new state of the changelog file in 
sources,
commits the date that was written in the changelog in a separate key = 
value

file (with the components of the build evr, the last packager id, etc).

That means, you can trim the detached changelog file (if you find the 
list of build events uninteresting), the SRPM will still remember to 
bump the next EVR to something above the last build (even if it does not 
appear in the changelog file).


(That also means I could dispense with writing a parser for the custom 
timestamp format rpm changelogs use, and save the date in easy to parse 
RFC 3339/ ISO 8601 format)


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs



--
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 be generated automatically on Koji
side.


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 side tag, whatever). Koji is still in 
charge, the bumping is just integrated in the build process with the 
rest of the package creation.


And, unlike something done specifically by koji, the bumping will import 
and export across all build systems, ie all the bumps that occurred in 
rpmbuild, or mock, or copr, or obs, or whatever are imported in fedpkg 
with the rest of the srpm, and an srpm produced by koji can import in 
rpmbuild, or mock, or copr, or obs, or whatever without loss of bump 
information.


And you no longer waste hours wondering why a package you just fixed is 
still failing on your test systems before realizing it is masked by 
another build that did not share the same bump history.


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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.


What is “changelog bumping”?  Why is it needed?  What about release
bumping?


Changelog bumping is the act of putting the actual release bump and 
build time in the changelog.


With the change, the spec is able to self-compute its next release if 
the spec file evr is older or equal to the last build event.


On build, it will both bump the release, without touching the spec file 
(that is release bumping) and commit the new build event timestamp in 
the detached changelog file at %build time (that is changelog bumping).



The detached changelog is just one more file in SRPM sources, which is
modified by rpmbuild at `%build` time with other files rpmbuild
modifies. The tricky part is to modify the source file as a source 
file

so rpmbuild adds the result to the produced SRPM (and, that does not
work in mock right now, because mock serves the SRPM that existed at
the start, not at the end of the build. Though it’s probably just a
matter of getting mock to call again its SRPM creation method at the
end of the build).

The packager does not have to request the modification in his spec,
it’s done as part of the various %auto_foo calls the change introduced


Can you list the relevant %auto macros explicitly somewhere?  Is
%autosetup included in the set of macros that trigger this behavior?


%autosetup is not part of the new framework, all the new %auto entry 
points have %auto_something name/


Auto release bumping and auto changelog bumping involve registering some 
processing in the preamble (to compute the next evr), in %sourcelist (to 
deal with the source files involved in saving state) in %build (to 
commit the new data to disk once the build is ongoing) and in %changelog 
(to get rpmbuild to record the new changelog state in package metadata)


ie it registers processing in %auto_pkg, %auto_sources, %auto_build and 
%auto_changelog


The bumping is done by the buildsys subsystem ie practically by
%new_package (called by %auto_pkg, directly or via %buildsys_pkg), by 
%buildsys_sources (called by %auto_sources), %buildsys_build (called by 
%auto_build) and %buildsys_changelog (called by %auto_changelog).


It’s done by the buildsys subsystem because the %buildsys subsystem is 
tasked with writing the SRPM header in the new %auto_call framework, so 
only it knows which of the various (sub)package epochs and versions are 
the ones that apply to the SRPM.


This may seem a bit complex and convoluted, but that’s because 
autobumping


https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

is a small addition over the big %auto_macros change.

https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

And it is small because the big change provides all the low-level infra 
to code such high level features easily.


The big change was not done for autobumping. It’s only once I coded it 
for other packaging needs that I realized it made implementing 
autobumping trivial (trivial to me after all the other changes, maybe 
not so trivial for the average macro reviewer).


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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 make those packages auto-bump and auto-changelog at
> > the rpm level, in an infrastructure-independent way.
> 
> Please forgive the silly questions (it's getting late here…), but how
> does this look in practice?

There are no silly questions, do ask if you have more.

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

The detached changelog is just one more file in SRPM sources, which is
modified by rpmbuild at `%build` time with other files rpmbuild
modifies. The tricky part is to modify the source file as a source file
so rpmbuild adds the result to the produced SRPM (and, that does not
work in mock right now, because mock serves the SRPM that existed at
the start, not at the end of the build. Though it’s probably just a
matter of getting mock to call again its SRPM creation method at the
end of the build).

The packager does not have to request the modification in his spec,
it’s done as part of the various %auto_foo calls the change introduced

> Is the old changelog discarded?

The old changelog file is replaced in srpm sources with a new file
containing new build event lines before the old lines. It is not done
before the build is effective and %build has been started (ie a
rpmbuild -bs or rpmspec -P will show the future bump, but nothing will
be stored before the build is effective)

> And is this related to Piere/Pingou's work on the same topic that was
> deployed to koji staging?

It’s a different implementation, at the rpm level, that does not tie
bumping to Fedora infra (koji included). Though, it is probably
complementary to what pingou did on the changelog alimentation front.

IMHO the design mistake so far was to conflate bumping and non-build
event changelog filling. You need to do both of course but build event
should be a build event driven by the lowest common denominator
(rpmbuild) with koji/infra scrapping 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.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 hard to expose /usr/share/fonts in a webserver (and
pretty risk-free).

However old IE browsers are a plague security-wise, it’s much better to
remove IE workarounds than help users keep an insecure browser that
does not work all that well on free software webapps.

Also, making 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 :
> > > 
> > > 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 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
> > 
> 
> Anaconda does this behavior correctly with btrfs with / and /home as
> separate subvolumes on the same btrfs volume. So the preservation of
> /home would still work, while we get flexible storage allocation at
> the volume level.

That only works as long as btrfs is the next shiny thing, or as long as
no one decides the options Fedora used to create btrfs volumes with are
crap and it’s a good idea to recreate them with new better options.

(btrfs may offer migration to new volume options like ext4 did in the
past, I still would not want anaconda to touch my existing user data
volumes, especially when doing emergency reinstalls because the kernel,
systemd, glibc or any other core component crapped itself).

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
completely insufficient, I did it at the last minute to honor
deadlines. Please check if it is ok for you now.

Anyway here are some answers I added to the wiki


> 
> What's "autobumping" here 

The change will make packages that use the %auto_ redhat-rpm-
config macros auto-bump and auto-changelog at the rpm level, in an
infrastructure-independent way. The %auto_ framework is proposed
in
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

In that context, auto-bumping means that a SRPM, produced in any
compatible build system (that is, any build system that does not
inhibit low-level rpmbuild behaviour), will rebuild by default to a
release higher, than the last build release, in the next build system
it is imported into, without any manual change to the SRPM source
files.

Auto-changelog means that the build event will also be traced in the
rpm changelog (again, without any manual change). 

> and how is it better than rpmdev-bumpsec?

Unlike rpmdev-bumpsec, the feature is automatic.

It does not require explicit human action. Releases get bumped even if
the human forgot a particular release has already been built.

It does not rely on an external tool, nor requires this external tool
to be able to parse a spec file (which can be difficult for heavily
automated spec files like the ones that take advantage of %auto
macros).

A rebuild does not touch the spec file at all. That means, the spec
files changes tracked by your favorite scm, will show only spec logic
changes, without drowning those in no-logic-change build events. 


> [...]
> > == How To Test ==
> > 
> > A redhat-rpm-config packages with the changes and some example
> > packages are available in
> >   
> > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/
> 
> A diff with changes

The current code state is visible in

https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/commits/forge-with-patches

It’s one small commit on top of the huge change queued in:
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95

That PR can still evolve based on feedback and testing. Therefore, I
can’t promise that the auto-bumping logic will always apply directly,
just that it will look more or less this way after rebasing. I do not
rebase it on every change to the other PR.

This is very young code, there are probably lots of easy things to tidy
up in there. However it works. 


> 
> Why is a separate "rpm-changelog.txt" file with manually maintained
> changelog better than current manually maintained changelog inside
> .spec?

This change does not separates the changelog. The separation is already
done in

https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
that this change builds upon

Without separation, we would lose the benefit of auto-bumping at the
SCM level, since no-logic-change rebuilds would still result in a spec
file change.

Separation makes automation a lot easier since adding to the changelog
is just pre-pending some lines, and does not require any knowledge of
rpm syntax. Auto-bumping will add a "* date name evr" line on the next
rebuild, so changelog additions can limit themselves to plain text
descriptions of new changes at the top of the existing file.

Separation is a requirement for auto-changelog bumping at the rpm
level. Once rpmbuilt is lauched, it can not modify the processed spec
file. Therefore making the changelog modifiable by the build process
requires splitting it out of the spec file first. 

> How about using git commit log for changelog instead?

This is a low level change that does not depend on any specific
infrastructure, git included. It works directly at the rpm level. 

An infrastructure that uses git, can feed git commit events to the
detached changelog file, using dumb or elaborate git commit hooks, and
any other method it wants to implement. The auto-bump logic does not
care, it will use the detached changelog file in the state it exists at
the start of the build process.

Because the logic catches all rebuilds, regular manual trimming of the
lines that add no value is recommended. 

> [...]
> > 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 %buildsys_packager instead of two?
> You're always using them together, anyway. It'd be similar to the
> existing %packager macro, too.

This is certainly doable and 

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, and discuss the design or the implementation, I’m
all ears the change process is here for that.

Just don’t feed me “your code is black magic” “someone will do better
someday” “your code will have bugs” because yes all software has bugs,
yes someone can always do better someday, and yes code you did not
bother to read even at high level is black magic.

But none of this makes Fedora any better, it’s all empty posturing, and
I have completely lost patience with this s*. (as should be obvious
from my first answer)

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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]]
> > * Email: 
> > 
> > == Detailed Description ==
> > 
> > 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 (users of forge, fonts and go
> > macros).
> > 
> > It was driven first, by the need to make the underlying macro
> > infrastructure robust enough to package Go modules, and second, by
> > an
> > unfortunate rpm 4.15 regression that proved it was foolish to
> > depend
> > on rpmbuild to parse Tags in anything except canonical order.
> 
> I think this would be already at least 30 times we mentioned that RPM
> works as expected and the bug was just in the spec files that relied
> on Name being parsed before expanding ~/.rpmmacros.

Yes, rpm broke existing specs and you insisted it was normal it broke
them and the 10+ years during which the pattern they used worked was an
anomaly. You told me nothing would be fixed, and I just had to generate
tags in the exact undocumented order you wanted them generated, and
that you did not care about my problems (to the point, you proposed
reverting whole parts of the distribution to the level they were years
ago just so you did not have to deal with them).

So here is the code that does exactly that. You got your wish, it
caused me a lot of work and pain to implement, get out of your
defensive mode, people are not doing things to make you miserable they
are doing things to solve their own problems.

All the things you pretend discovering today have been hashed and re-
hashed to death with rpm upstream (to the point, Panu once dismissed a
ticket, stating I had already asked the same thing many times and the
answer was still no).

So now I solved *my* packager problems at the macro level with no rpm
maintainer help whatsoever and I don’t care if rpm maintainers suddenly
feel they could do better. I spent litterally decades asking them to
look at those things, and they did not care (Florian excepted, thank
you Florian).

> 
> > A packager that needs custom processing can add custom code above
> > or
> > bellow the various `%auto_foo` calls, and check with `rpmspec -P`
> > that
> > the result does what he wants it to do. For obvious reliability
> > reasons injecting custom code in the middle of an `%auto_foo`
> > sequence
> > is not allowed.
> 
> What about rpmdev-bumpspec, vim plugin and such tools adoption that
> expect Version/Release/%changelog to be present in spec?

That’s why a second change deals with autobumping.

That’s why I objected vigorously when you and Panu told me two months
ago to generate tags values instead of pointing out that changes in Tag
evaluation rules made them useless for my specs.

So now everything is generated, and removing the Tag obstruction
enabled solving other problems. It was a lot of work I could have done
without, but the work is done now, and I *will* use it to its full
capabilities, because I did not do this work to make a point, I did it
to solve my Fedora packager problems, and it solves them nicely.


-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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, in an infrastructure-independent way.
> 
> So how exactly is this supposed to work? From where will it get old
> changelog, how packagers will migrate to this, how does it affect
> reproducibility?

The changelog is just one file in SRPM sources, and bumping is done
from last build state which is just one key = value file in sources
(storing the evr components, the last built time, and last build
packager id).

In reproducible mode last evr and packager id and build time are
applied without bumping. You need to set
%reproducible_build = true (or anything except false) in your
~/.rpmmacros (or config_opts['macros'], or as rpmbuild --define flags).

The auto framework  (and %new_package) split Release in separate
%{source_release} %{dist} and %{post_release} components, which makes
the implementation way easier than multiplexing things in a single
Release tag and trying to untangle the mess later.

A production implementation would probably split %{dist} in %{distcore}
and %{distprefix} (the .gitdatehash things we stuff in Releases and in
rpm changelogs as opposed to the fcX part we want to appear in Release
but not in changelogs). I know where the offending code is in fedora-
release and the split up is trivial to implement, but there’s no point
in worrying about this level of detail before the core of the feature
is approved (or not).

The implementation is really simple and easy, it took me two days to
write and test it because it reuses all the building blocks I had
already done for my other change (without those jungling all the bits
involved at various points of the spec file would have been challenging
to say the least).

> 
> So are you asking mock and koji people to implement something? Did
> you
> talk to them before submitting this proposal?
> 
> > * Mock issue:   
> > https://github.com/rpm-software-management/mock/issues/599

I filled the mock issue to inform them. Again, this is a feature that
took me two days to code (it did not exist, even in thought, last
saturday). I was actually surprised at how easy it was to implement,
given the months if was discussed on this list.

At the mock level, there are two issues.

The main one (and only critical one) is that bumping MUST occur when
%build is executed, because a spectool or rpmbuild -bs is not a build
event, only a full build is. That means the SRPM produced by
rpmbuild -bs
is not the bumped SRPM, only the SRPM produced by
rpmbuild -ba

is bumped. My (imperfect) understanding of the mock issue is that mock
serves the first, not the second one at the end of the build process.

The second issue is that bumping changelog requires filling a builder
name and mail in the changelog line, and mock provides not easy way to
pass those to the build process.

If those two problems are lifted I see no special problem copr side
(except using the new mock plumbing to pass builder iname & mail to
mock).

For koji/fedpkg things are a bit more challenging because you will want
to back-commit the bumping to git once a build succeeds. Which is the
main point clime and me disagreed earlier on this year. Though, it is
not a show-stopper initially, a packager can back-commit manually if he
wants the bump recorded till tooling catches up.

While that adds constrains on the koji/git interface, that gives you a
bumping mecanism totally generic and independant of the build infra,
that does not rely on external python/ruby/whatever scripts to bum, and
does not require messing with someone else’s spec just to trace and
bump a rebuild.

Just importing an srpm from one system to another will preserve the
bumping state without any data loss.

> > 
> > == Contingency Plan ==
> > 
> > There is no contingency plan because the change will happen or not
> > at all.
> 
> This is not true. If it will happen but then something will be
> entirely broken we need to revert it.

Thank you for your vote of confidence. I hope you realise that by that
yardstick, nothing would be accepted, including your own changes,
because something may always happen someday causing someone to revisit
something. 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 sucks and is way worse than the perfect
code no one has written yet nor intends to write any day soon.

-- 
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/e

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 dm-log-writes work, have all been
> traced back to hardware doing the wrong thing.

However, software does not work without hadware bellow it, and having
storage software that is intolerant of real-world hardware
defficiencies, of pushes this hardware in modes the hardware 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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-26 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 for 5 years.
> > > It's worked out very well. Thanks,
> > 
> > Josef, I'd love to hear your comments on any differences between
> > that
> > situation and the typical laptop-user case for Fedora desktop
> > systems.
> > Anything we should consider?
> > 
> 
> We buy worse hardware than a typical laptop user uses, at least for
> our hard drives. 

The difference between an operation like Facebook and the Fedora user
base, it that Facebook will have a huge fleet of crap hardware, with
the support teams to baby-sit the crap hardware, and attention to
reducing the variety of crap hardware to limit the support matrix
breadth, while Fedora has to deal with a huge support matrix breadth,
without the support teams and the support team tooling to baby-sit
hardware. (Besides Facebook designs the levels of crapiness they allow
in their hardware, meaning they know exactly where they are pushing
limits to lower hardware costs).

And, it’s not always the crap hardware that hits bugs. Sometimes
expensive gamer hardware will fail first because its manufacturer has
pushed the limits to eke some performance 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...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-26 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 like
> > 
> > /boot/efi > EFI (FAT32)
> > / > btrfs
> > 
> 
> BTW that layout.
> Anaconda still does not allow installing something like that because
> it does not allow /boot on btrfs (technically there is no any
> reasons to demand that and /boot can be just subvolume on the root
> btrfs pool).

Anaconda will detect you’re reusing an efi partition, and complain it
does not fit its requirements of the day, and force you to recreate it
from scratch, blowing up the EFI parts installed by other systems for
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 intentional, since a lot ot things tooling-
> > side
> > do not talk the git protocol and will never talk the git protocol,
> > starting with rpm itself, spectool, etc).
> 
> noted.  not clear initially from reading the docs; this helps. thx!

The documentation part of the initial redhat-rpm-config forge
implementation was never merged, and I gave up on refreshing it, so
you’re in traditional unwritten rpm lore land.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 intentional, since a lot ot things tooling-
> > side
> > do not talk the git protocol and will never talk the git protocol,
> > starting with rpm itself, spectool, etc).
> 
> noted.  not clear initially from reading the docs; this helps. thx!
> 
> > git is not the only scm system out there.
> (snip)
> 
> sure.  i'm trying to get forge playing nice with not-included-yet hg
> sources atm :-)

I know some people have used it successfully with birbucket hg
projects, for example. The code is pretty SCM agnostic, it "only"
constructs API URLs for the major forge services out there.

> 
> yup.  and for the moment -- while I'm getting my 'end product' sorted
> out -- that's intentional, and I'm not concerned with audit trail.

That’s fine as long as you know the limitations, and that is why I made
the technical side of the macros support this workflow too.

> > So you should have a long list of
> > %forgeurlX
> 
> 
> that's already changed in my latest ...
> 
> > %tagX or %commitX
> 
> fair enuf, now that the above is nice-n-clear ...
> 
> that'll get announced ... here?

That will be announced on devel and packaging once there is a redhat-
rpm-config PR and a set of example copr builds to look at. The aim is
to get it done soonish, so i18n can decide if they want to push a
change that depends on it before the F33 change deadline (30th june).

First set of unit tests and test builds is green, so it should not take
long now.

> do you have a _rough_ timeframe for when that'll be consistently
> supported/usable in rpmbuild, mock & COPR?

This is very low-level work that only depends on rpm (and often not a
particular rpm version). So typically when it is done it just works in
all upper level tools (spectool, rpmlint, mock, copr, koji, etc).

Now get it done includes a redhat-rpm-config PR merge, and I do not
control how long those take (likewise, it will imply an update of the
forge and fonts packaging guidelines since they both use the same macro
engine, and FPC can ponder things ponderously sometimes).

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-25 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 itself, spectool, etc).

git is not the only scm system out there. Nor its protocol is set in
stone. It would be very tricky to push it down to layers like spec
files that operate on timescales measured in years/decades and are used
by a huge amount of third-party tools that expect http(s) source URLs.

From a pure auditing side, it is also correct to have all the sources
of things you package listed explicitly, and not have recursive sources
that install themselves other sources behind auditor’s backs.

Note that your spec as it stands is inherently unsafe since you are
pulling sources from a a moving reference (master) instead of commiting
to a specific commit or tag state¹ (another proof git is not safe to
use as direct packaging layer, since it pretends to give you a fixed
state while submoduling things that are not fixed).

The correct auditable way to use git in rpm is to declare all the git
sources you actually use, with a specific tag or commit hash for each
of them.

So you should have a long list of

%forgeurlX
%tagX or %commitX

and a single %forgemeta -a at the end

That will change soonish BTW, I’m currently doing final testing on code
that will use a slightly different syntax:

%forge_urlX
%forge_tagX or %forge_commitX
%forge_patchlist %{expand:
foo1.patch
foo2.patch
}

…
%auto_init

…
%sourcelist
%auto_sources

%patchlist
%auto_patches

%prep
%auto_prep

Because not making -a the default and emphasising -z in the
documentation was comfusing users. -z should be a last resort debuging
help, not the first thing you look at when packaging multiple sources.

That will leave you with each individual source unpacked and patched in
%{_builddir}, and needing a some symlinks between %{_builddir}
subdirectories to construct a unified source trees, but that’s how
multisource works deep down in rpm, nothing I invented myself.

Regards,

¹ I made it work in the macros because I knew people would attempt to
do it, and I’d rather have it work in my code than have people butcher
it to achiever their aims, but from a Fedora packaging guidelines POW
it is a mistake).


-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 ; \
>    CXX=%{__cxx}; export CXX ; \
> 
> This breaks the relatively common construct for building MPI versions
> of 
> packages:
> 
> export CC=mpicc
> export CXX=mpicxx
> %configure

This is why macros should never set variables blindly but use
constructs 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 idea was that DNF could discriminate the same-name package using
> > the
> > ModularityLabel tag instead of relying on modulemd documents
> > delivered in the
> > repository metadata.
> 
> One problem of having it a tag (which we do not even have in Fedora)
> is
> that it requires rewriting dependency resolution logic at dnf level,
> and a Tag does not come with all the dependency manipulation verbs we
> have evolved over the years for Provides and Requires.

That is what killed the group tag and comps groups as generic ways to
declare package grouping BTW.

RPM maintainers were long opposed to metapackages, but in the end
metapackages offer more packager flexibility, and appear as normal
objects in the dependency graph, meaning you can do things with them
you could never achieve with an out-of-graph Comps/Tag group.

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> ModularityLabel tag instead of relying on modulemd documents
> delivered in the
> repository metadata.

One problem of having it a tag (which we do not even have in Fedora) is
that it requires rewriting dependency resolution logic at dnf level,
and a Tag does not come with all the dependency 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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
> namespace into rpm name itself?" I mean...I wouldn't mind having it
> as
> a separate attribute but the usefulness of it would need to be
> discussed.

The namespacing information will eventually need to be pushed to the
package level because  it’s not possible to do cool stuff with things
that do not exist at the atomic component level.

However rpm (the tool that creates the deployment format) sucks loads
for managing variables/attributes at scale. RPM tags are completely
inadequate for the level of variabilisation the distribution needs
today (and getting more inadequate BTW — there are new tag constrains
in rpm 4.15+ that did not exist before).

That’s why we have to shove level after level of unrelated complexity
in a single Release tag, that’s the whole changelog/autobumping
discussion (I have other examples but they would not speak to the
general audience on this list).

You can bypass a lot of rpm format limitations by giving up on Tag uses
altogether, using rpm macros/variables instead of tags in the spec
file, and exposing the new metadata in foo() provides, but you will
still hit the brick wall of handling all those new variables at the
spec level.

IMHO Modularity functional objectives were good, implementation was
bad, first by confusing a build framework with a deployment stream
format, and second, by not investing in the actual tool that creates
our deployment format, to make it scale to the levels 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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-
> 1.
> 
> now we have:
> X-2 (which obsoletes X-a-1)
> X-b-2

With that structure you do not need fedora-obsolete-packages since
X ≥ 2 will eat X-a < 2. However, you may need a provides X-a in X ≥ 2
if something in the dependency graph depends on X-a < 2 (dnf repoquery
may help you identify those). However, if X ≥ 2 does not actually
provide the things dependants expect in X-a the provides will do more
harm than good.

Those rules are independant of the fedora release and will work the
same in devel and in previous releases.

Beware of people 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.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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 shouldn't somebody spend time changing the test conditionals 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 out there

Another fun case: someone broke the dep of a component used in unit
tests. Fixing the component requires rebuilding the dep. Except, the
dep uses the component itself in its own unit tests…

There are boundless possibilities for fun and profit there (well
profit, not so sure actually)

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 out there

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
> > > 
> > Those suffer from
> > 1. the horrible bcond logic inversion that trips pretty much
> > everyone
> > all the time.
> 
> 
> That won't be different for what was the original question here, i.e.
> conditionally disable tests. bconds are what we have for better or
> worse.

bconds had adoption problems from day one and will continue to have
them as long as they are not fixed to use a human-friendly syntax

> And really, this seems about bootstrapping not disabling tests, which
> are not completely different, but nobody can objects bootstrapping,
> while disabling tests might be good just to improve build speed and
> nothing else. That should never happen in production environment IMO.

That depends entirely on upstream’s test quality. FYI some upstream
tests will attempt reconfiguring the system as root, or download random
unchecked stuff drom the internet, or communicate with an internal
server of the company that wrote the tets for example. There are many
many shades or gray out there

> You can set them in modules and I think Koji can set them:
> https://pagure.io/koji/issue/416

It would be nice if it has been fixed now

> Not mentioning that there is almost always way to provide some macro
> file

That’s the kind of manual workaround that looks nice on paper for
people who do not have to do it, and does not scale at all for people
who actually have to do it for thousands of packages while rushing to
meet release dealines

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-08 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.

Look, 9∕10th of the times the "informed" upstream decision is just one
poor dev who slapped some build automation using the first compiler he
though of in quick and dirty mode so he could get back to coding as
fast as possible (sometimes, for another system than Linux, that was
grandfathered for Linux builds later, because who cares about those
things in real life).

Sifting through build systems, possible compilers and compiler options
takes an enormous amount of care and knowledge which is lacking in the
average upstream project. Only giants like Chrome or Mozilla can afford
to do this level of analysis. I’m not even putting LibreOffice in this
class – they switched compiler for a subset of their codebase, probably
just to workaround a perf regression quickly in the hope that someone
would analyse the regression causes later. Not even sure they bothered
to check if the regression happened with all possible build flags
combinations, one report of "it’s faster using compiler XXX" (one
version of one compiler on one system with one set of build flags), is
usually sufficient for this kind of switch.

Arguably, in Fedora the average packager can not afford it either – he
relies 100% on the default compiler flags defined by the gcc team. And
the gcc team can afford to look at those closely only because of the
mass effect of a whole distribution codebase that is fully built using
the same compiler and flags everywhere.

“Upstream knows better” – for 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 we bootstrap Fedora from scratch?  Wholly new
> architectures are rare.  Are there other events that require
> bootstrapping from scratch?

Some language ecosystems have very low quality unit tests, any mass
rebuild (every release) basically works in two passes, make 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-bootstraps

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Location of executable code

2020-05-22 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? 

There is no easy way right now because this stuff gets classified by
humans, the distinction you want did no exist in the past in the FHS,
so the human classifiers did not think about it.

You could go to the FHS and request separating executable and non
executable data in separate roots, and 5 years after you did it, you’d
began to see the result of the standard change in production systems. I
think that would also involve driving a Fedora Change to focus Fedora
packagers on changing things, and to help fix all the software that
assumes both roots are the same today.

And that would require first for you to have an ironclad definition of
what executable means.

For example, Go source code is mostly not executable (people do not
expect it to run it in a Go interpreter). Except, that when this code
is present, it will be picked up by the next Go static build that needs
it. Making it behave like a shared library (except a library that will
be re-built by each of its users). So, from a security POW, I suspect
it needs to be treated executable, except most people would not think
of it this way. Google will certainly scan it in its own containers the
same way it does for elf files. 

I suspect you could spend a year going through such cases to determine
if they need treating as executable or not.

And, in the end at least 20% of the target population will decide you
are making their life miserable for no good reason, and continue to
blatantly ignore your standard, and 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
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Location of executable code

2020-05-22 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 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 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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. Because the somwehere else most people think of is
/usr/lib. And then you end up with a situation where all the multilibs
are not symetric and equal, because people had to sacrifice one of them
and stuffed architecture independant parts there.

The architecture independant/architecture specific split is one of the
stong points of the current FHS. The legacy Unix people had to get it
right because they were all deploying on mutually incompatible machine
architectures.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 you look at it.

Practically, people have been putting “read-only architecture
independent“ executable data in  /usr/share forever. Not just
javascript. Java bytecode, xslt programs, scheme programs, go code, etc
(in the Java & Go cases I’ve also seen architecture dependant data leak
in here, though I intend to fix the leaking oneway or another in the
next generation of Go packaging).

If you want to split hairs we also install fonts there, and OpenType
fonts contain instructions that will be executed by the text renderer,
and malicious fonts have triggered security problems in 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 email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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@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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 gradle APIS)

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 modules?
> > 
> > No, that’s similar to venv everywhere. The language has bytecode-
> > sharing objects. Java upstreams just got used not to share those
> > executable objects between projects, not to version them properly,
> > not
> > to manage their ABI breaks, and to change things in the local copy
> > instead of contributing changes to the original project.
> 
> Well... Java upstreams share their JARs by uploading them to a public
> Maven repository (Maven Central most of the time). And in the vast
> majority of cases there are also "source-JARs" (containing source
> code) uploaded alongside the bytecode JARs. I am simplifying things
> here a bit, but basically when Java open source projects want to ship
> their apps, they fetch pre-built dependencies from Maven Central,
> compile their apps, and bundle everything (app bytecode + pre-built
> deps) in a tarball. And that's what they ship.

If Java finally left the stone age, there should be no problem building
the same artefacts in rpm, installing them in a central place like
%{_datadir}/java or %{_libdir}/java, and making it a package other java
software can buildrequire. We managed it in Go, and we did not even
have a language versionning infra to build upon.

> > That’s non-free software open source to its extreme. The code is
> > available for a dev to copy and resell at his next work, but
> > everything is organised (at the human not technical level) so it’s
> > not possible to reuse the bytecode directly without paying someone
> > to copy and fork the original code that this bytecode was generated
> > from in the next project.
> 
> I'd like to know more about this if you don't mind. This is
> definitely not how open source Java apps are developed.

Free software is end user not dev oriented. Stallman wanted his printer
driver to work. The GPL gives rights to the recipient. As long as the
toolchain is broken enouth even huge downstreams like distros are
unable to rebuild the source easily, you have something that may be
open source, but does not function as effective free software.

And when downstreaming is broken upstreaming is broken too (who will
bother contributing to an upstream when things do not flow the other
way?).

As spot wrote a long time ago, the only useful form of open source for
Fedora (and a lot of other entities) is free software.

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 some projects we are not hopping between branches of the same
> upstream git, we are hopping between branches in different forked
> repos of the same upstream

To expand a little: when you are creating a Fedora package, you are
packaging a fixed code state (and the state must stay fixed for trivial
reproducibility, auditing, and security reasons). In git speak that
means you are packaging a specific commit reference, that may (if
upstream is careful and serious) be tagged with a clean fixed version
string.

That means packaging a branch is a no-go. It’s not a fixed git
reference, it’s a moving reference. 

*How* upstream arrived to this fixed state from the last packaged fixed
state is deeply uninteresting from the srpm POW.

It may not even exist
as clean git history upstream (assuming upstream uses git). For
exemple, you package foo project, it gets in governance trouble and the
original repository is no longuer updated, so you bet on fork foo1,
that seems to have picked up the dev. Six months later you lost your
bet, devs have consolidated on foo2 fork. There is no clean upstream
git history from foo1 to foo2, foo1 is a dead evolutionary path.

Also there may even be a complete state tracking hole somewhere in the
middle, because the creator of foo2 did not bother importing foo
history in its own repo, and did some private dev starting from a
partial copy of some (reformatted/reprocessed) foo files. Having needed
to reconstitute fragmentary dev history in a new consolidated upstream
git, I can tell you splicing past repo history fragments is non-
trivial. I can totally understand why some upstreams do not bother with
it after a governance accident.

Therefore, all the systems that try to base a Fedora package history on
the mirorring of a unified unchanging monotonic upstream repo are
broken by construction. The only thing you can reliably import in
Fedora land are specific hashes or tags. And the upstream repo where
you can find those hashes or tags may change over time.

I suppose you *could* ask a downstream Fedora scm “mirror” to compute a
git path from the last packaged state to the new one, faking a merge of
the new state over the last state, and faking continuous regular
upstream history.

But why bother? You’d be creating artificial git history
complexity that will exist Fedora-side only, and that upstream will not
understand and disagree with, just to avoid cloning the upstream repo
of the day separately to make your changes and PRs there.

Also, rpm is able to package multiple source archives in a single spec,
and we have packagers that make use of this capability. If you wanted a
fully working scm mirroring system, not only would you need to fake
continuity between upstream scm repositories that do not provide this
continuity, but to merge multiple upstream scm repositories in a single
downstream git (good luck producing patches that upstream will accept
from this unified repository).

In the meanwhile, you could just dump in your spec file

%global forgeurl0 https://repo0
%global commit0   hash0
# repo0 time handling is broken
%global time0 2020-05-16T12:25:43+00:00

%global forgeurl1   https://repo1
%global tag1x.y.z
%global forgepatchlist1 %{expand:
foo1X.patch
foo2X.patch
}

%forgemeta

%sourcelist
%forgesources

%patchlist
%forgepatches

…
%setup
%forgesetup

and be done. All existing Fedora tools like spectool will work just
fine on that (actually the forge macros are not quite there yet in the
version included in redhat-rpm-config, I still need to upstream
multipatch handling once I finish QAing it)

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 modules?

No, that’s similar to venv everywhere. The language has bytecode-
sharing objects. Java upstreams just got used not to share those
executable objects between projects, not to version them properly, not
to manage their ABI breaks, and to change things in the local copy
instead of contributing changes to the original project.

That’s non-free software open source to its extreme. The code is
available for a dev to copy and resell at his next work, but everything
is organised (at the human not technical level) so it’s not possible to
reuse the bytecode directly without 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
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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, 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 Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 ASF
wrote and people contributed to by a single ISV, Cloudera. Because it’s
the sole remaining ISV able to build the result and provide it as
secure and supported binaries.

Do you think the corps that paid a lot of the ASF devs to create the
projects that Cloudera sells 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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 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 email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 actually the consensus though.  Fedora and RHEL are
> symbiotic in so many ways that it is naive to believe Fedora is
> somehow self-contained and RHEL gets no value from it or has no
> impact on it.

The most downloaded part of Fedora is EPEL, and even Fedora packagers
that do not contribute to EPEL will often use it or got involved in the
project in the first place because of EL and EPEL. So, no question that
EL & server is important for Fedora (people should remember that when
they try to conflate Fedora with its desktop edition in Fedora
communications).

However, EL as a critical Fedora dimension, is something very different
from RHEL the product. Products have short term local deadlines and
market positionning tactics that conflict with wider (time or scope) 
strategies.

Thus, while I personnaly welcome greater EL implication within Fedora,
it needs some 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.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 need changes in upstream code I fork the upstream git repo, make
the changes there and point %{forgeurl} to my fork till the changes got
merged upstream (sometimes I am the upstream).

If upstreaming stalls I export the corresponding git patches and apply
them manually. This is painless enough I’ve not bothered yet to code a
per-forgeurl %{patchlist} in forge macros. Someday I will spend the
time here and I’ll have a safe %autoforgesetup that does not assume all
the patches belong to archive 0.

Step 3 is a bit annoying in practice *but* absolutely necessary. WIP
fixing can rely a lot on ephemeral multi-rebased topic branches. I
*need* to cut the link to upstream git in my spec files by exporting
the state the spec packages, without polluting other git repos with
transient topic branches.

I don’t waste time modifying my Sources, %forgemeta produces a
%{forgesourceX} that I declare as SourceX once and for all. I will,
eventually, code a %forgesources that can be dropped in %sourcelist so
it just works in multi-source specs, but those are few and frowned upon
in Fedora.

Sometimes upstream is itself a galaxy of forked repos, again, being
able to point the spec file to one of those (and change the pointer ar
need) without assuming upstream is a monolithic monotonic ethernal repo
is a godsend.

So, I *definitely* do not think making the Fedora git repo
a clone or extension of some upstream git repo is a good idea, not that
it is needed.

Better autobumping and auto changeloging would be appreciated, but not
if it introduces adherences to specific Fedora git objects.

Like others wrote, the correct data model is to make the buildsys
record real official Fedora build events in Fedora git, not invent
esotheric rules to workaround the fact the git can not guess accurately
what 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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 of the bundling/vendoring aproach,
relocate everything in a single private place to avoid the hassle of
interacting with the upstreams the project depends on, with the usual
result that the apex of the vendored pyramid is well maintained,
everything bellow suffers, and the project becomes 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
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 last 16 years I have in ~/.rpmmacros
>  
> %_topdir/home/jamatos/rpm/
> %_rpmtopdir %{_topdir}/build/%{?name:%name}
> %_sourcedir %{_rpmtopdir}
> %_specdir   %{_rpmtopdir}
> %_rpmdir%{_rpmtopdir}
> %_srcrpmdir %{_rpmtopdir}

That is broken nowadays because rpm 4.15 evaluates %{_sourcedir}
before reading the spec file that sets %{name}, rpm 4.16 will warn
loudly of the use of an unitialised variable in %{_sourcedir} (things
still work, for now) and a future rpm release 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
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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, that ties building to
Fedora infra?

There are lots of practical applications of being able to record build
time info in srpms (for example, I’ve been asked to record the
buildroot state one way or another, and, IIRC, samba called rpm in its
scripts for the same reason).

Modules went the overlay 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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.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:
> > > > %_use_ncurses %{lua:
> > > > if rpm.expand("%{name}") == "yourpackage1"
> > > >   or rpm.expand("%{name}") == "yourpackage2" then
> > > >   print(rpm.expand("%{bcond_with foo}%{with foo}"))
> > > > else
> > > >   print(rpm.expand("%{bcond_without foo}%{with foo}"))
> > > > end
> > > > }
> > 
> > %{name} use in macro logic is unsafe because %{name} does not exist
> > in
> > the preamble before the Name: line, and the Name: line does not
> > exist
> > before you start declaring package headers.
> > 
> > Once you’re in package
> > header declaration mode rpm parser behaviour will prevent you from
> > doing logic between headers blocks, so it all needs interleaving,
> > which
> > ends un not possible sanely in any semi-complex spec file.
> 
> You're correct but I can't think of any solution besides not using
> the macros before you define Name, just like in your example below. 

One positive result of all the ugliness in
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83

(which is what happens, when people like you and me try to do
processing on %{name}, and rpm maintainers feel otherwise)

is a generic %new_package wrapper in redhat-rpm-config.

The PR, should it be merged, will get you several things:

1. a real %{source_name} variable in spec files (not just
%{source_name} emulation in dnf) that you can set and do things with
before entering package header land

2. a single entry point within each header, *after* %{source_name} and
%{name} are set, where you can do generic pre-header processing such as
the one you propose. And where you can choose between processing the
subpackage name or the SRPM name, because they are exposed in different
variables.

And it only requires, besides merging the PR, to replace Name: and
%package lines in a spec file with the corresponding %new_package line.

If the packager did not set %{source_name}, the first %new_package will
set it and own the SRPM (usual case).

rpm will sadly probably insist that the srpm header comes first, so you
can not use %{source_name} to shuffle package headers in interesting
ways. %new_package solves the following ordering problems only:
1. need to do things with the srpm name before entering dangerous
header land (your case)
2. need to know, for macros that create package headers, if they are
supposed to takeover the SRPM or not. The PR removes the need for
complex inter-macro syncronization, a macro can just use %new_package,
and that will check if source_name if free to use, matches the package
header name, or matches something else

I coded it for my own automation macro needs (in fonts and go packages)
but it also marches your use case nicely

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 them endlessly confusing by today’s
> standards.

Of course past civilizations had other constrains. It is expensive to
carve a separator on your stone tablet. Physical space on the obelisk
you carried up from another region entirely is at a premium. But, fun
fact, the Egyptians did make an exception for the ruler names (can’t
get subjects to confuse where the ruler name starts and ends), and this
exception is the sole reason we can read ancient Egyptian today
(Champollion’s breakthrough started with the nicely separated Pharao
names).

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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
renaming, is due to someone thinking he could dispense with the dots in
python versions in the past, because the result was “obvious” to
everyone. And, years later, it is not so obvious and people think it
confusing.

Dispensing with the hyphen to separate from the rest of the package
name because it is “obvious”, is the exact same false clever economy.

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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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 mid
package name (that can easily happen when the SRPM is versionned but
subpackages not), and the hyphens nicely separe a version qualifier
from the rest of the name.

That means, a parser (human or not) can match -numeric- and not be
confused by 0ad, go2rpm, 0install, cookies4all, etc where there are
some numeric elements in the middle of the upstream name, but they are
not versions as such.

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
civilization find them endlessly confusing by today’s standards.

And yes, I am quite sensitive to the regularity of version syntax by
now, after years of trying to align the git non-idea of a version¹, the
various forges "straightening up" of git non-ideas, the go
interpretation of all of the above, and the rpm idea of a version, in
Fedora macros. And don’t get me started on pseudoversions (all the
above kinds) here.

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.

Regards,

¹ Linus did not bother with a clean version reference in git. People
build sand castles on one man page example where Linus workarounds his
own tooling defficiency by using vx.y as tag in an example.

That means in git, the vxx.y tag is probably a version, vampire 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” in the limited use
cases he imagined.

-- 
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


  1   2   3   4   >