https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Marian Csontos changed:
What|Removed |Added
Status|POST|CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #43 from Marian Csontos ---
Thanks! Everything is done, pushed to master, f27 and f28, built. I did a smoke
test - F28 works fine, Rawhide is broken ATM.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #42 from Neal Gompa ---
Looks good except for one bit:
> Supplements: (grub2 and python3-boom)
Change this to "Supplements: (grub2 and boom-boot)".
You can fix this on import.
--
You are receiving this mail because:
You are on
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Marian Csontos changed:
What|Removed |Added
Flags||needinfo?(ngomp...@gmail.co
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #40 from Neal Gompa ---
(In reply to Jason Tibbitts from comment #38)
> Our rules are pretty clear, though. You don't name standalone applications
> with a language-specific prefix. If you have something that's both an
> applicat
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #39 from Mohan Boddu ---
(fedscm-admin): The Pagure repository was created at
https://src.fedoraproject.org/rpms/boom-boot
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #38 from Jason Tibbitts ---
Our rules are pretty clear, though. You don't name standalone applications
with a language-specific prefix. If you have something that's both an
application and a module then you are encouraged to spli
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #37 from Marian Csontos ---
Now that's actually a valid concern and something which is bugging me too.
After reviewing all those tools with modules, it is quite common to have a
package name not start with python. I will give it so
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #36 from Neal Gompa ---
(In reply to Marian Csontos from comment #35)
> We must be looking at different yum.spec files, as the one I have opened has
> everything in the package %{name}.lang, including %config, launcher, and
> pytho
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #35 from Marian Csontos ---
We must be looking at different yum.spec files, as the one I have opened has
everything in the package %{name}.lang, including %config, launcher, and python
modules.
I think dnf is the closest to what y
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Neal Gompa changed:
What|Removed |Added
Status|NEW |POST
Flags|fedora-review?
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #33 from Marian Csontos ---
The only one I found is dnf, where the split could be driven by the fact both
python 2 and 3 are supported.
Either almost everyone is doing it wrong, or the split was never meant to be
mandatory.
--
Y
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #32 from Marian Csontos ---
...and quickly looking at dozens of those without python in name, I still have
to find one which would do such a split, so it looks like what you are
suggesting is an antipattern.
--
You are receiving
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #31 from Marian Csontos ---
(Actually, I searched only packages with python in name, and with config files.
I admit there may be a package using python and having the launcher in a
separate subpackage...)
--
You are receiving thi
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #30 from Marian Csontos ---
I have made a search, and have not found single package which would made such
an artificial splitting of launcher and configuration into a separate
subpackage.
OTOH there is a bunch of packages shipping
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #29 from Marian Csontos ---
It can be used as python module. The issue is the configuration is required by
both the module and the wrapper. The split just does not make sense.
And it is rather common for python apps to include the
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Neal Gompa changed:
What|Removed |Added
Flags|needinfo?(ngomp...@gmail.co |
|m)
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Marian Csontos changed:
What|Removed |Added
Flags||needinfo?(ngomp...@gmail.co
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #26 from Marian Csontos ---
Spec URL:
https://raw.githubusercontent.com/csonto/fedpkg-boom-boot/split/boom-boot.spec
SRPM URL:
https://mcsontos.fedorapeople.org/boom-boot/boom-boot-0.9-2.fc29.src.rpm
Scratch build: https://koji.fe
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #25 from Marian Csontos ---
...except now I remember another reason why I made single package - I am not
sure how much sense it makes to stuff anything into the main boom-boot package.
It is the python library which make use of th
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #24 from Marian Csontos ---
Splitting it into more subpackages and using rich dependencies was actually one
of the earlier ideas[1], but then I decided to go with plain 1 RPM, as I
thought the simpler spec would be easier to review
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #23 from Neal Gompa ---
Yeah, I've got a couple of concerns:
* Why are we stuffing everything into a "python3-boom" subpackage? Why can't
most of the "bootloader content" be in the main "boom-boot" package?
* Since boom can be us
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #22 from Marian Csontos ---
Hi Neal, have you found some time to look at this?
NOTE: There is a new boom version 0.9 - this is the same as the previously
built version except the version and one small patch.
Spec URL:
https://raw
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #21 from Marian Csontos ---
Hi Neal, I updated the spec file, made a scratch build, and uploaded rpm and
srpm to below locations:
Spec URL:
https://raw.githubusercontent.com/csonto/fedpkg-boom-boot/master/boom-boot.spec
SRPM URL:
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #20 from Neal Gompa ---
I'm okay with the changes proposed so far, so please get up an updated spec and
SRPM so I can review it.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #19 from Neal Gompa ---
For what it's worth, I'm okay with boom.conf being shipped in /boot for now. We
already do this in GRUB 2, and everyone here knows that both GRUB 2 and Boom
will eventually need to be fixed.
--
You are rec
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #18 from Bryn M. Reeves ---
Right: the profiles can be added by the user (although we do need the user to
tell us the utsname pattern in that case, since it cannot be guessed from
os-release data).
For boom.conf itself, if it caus
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #17 from Marian Csontos ---
Let's get this to users.
I have removed profiles from /boot/boom/profiles/ - these will be created by
CLI on demand. These are data, and after all should not be packaged.
But /boot/boom/boom.conf is su
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Bryn M. Reeves changed:
What|Removed |Added
Flags|needinfo?(b...@redhat.com) |
--- Comment #16 from Bryn M. Reeve
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #15 from Neal Gompa ---
(In reply to Marian Csontos from comment #9)
> I think snpshots of /boot has its own set of problems. One of snapper's
> flaws when using BTRFS is exactly that - it keeps information about
> snapshots inside
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Marian Csontos changed:
What|Removed |Added
Flags||needinfo?(b...@redhat.com)
--- Comme
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #13 from Bryn M. Reeves ---
> If Boom cannot handle this, then it needs to do something to make that work.
I don't think that it's reasonable to expect boom to make things work that are
explicitly outside the scope of the standard
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #12 from Alasdair Kergon ---
1) document more clearly?
2) have the tool recognise this situation and provide helpful messages?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified ab
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #11 from Bryn M. Reeves ---
It's also worth noting that the boot-as-directory-of-root scenario is somewhat
incompatible with the aims of BLS: to provide a single, system-wide boot
volume. If it's a directory of one particular OS in
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #10 from Bryn M. Reeves ---
> My own setup has /boot as part of the OS disk that is snapshotted with the
> rest
> of the OS
We're aware of this limitation and are trying to find long-term solutions,
however, even before this the
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #9 from Marian Csontos ---
I think snpshots of /boot has its own set of problems. One of snapper's flaws
when using BTRFS is exactly that - it keeps information about snapshots inside
the filesystem which is "snapshotted".
I wonde
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #8 from Neal Gompa ---
Alasdair,
This is fundamentally flawed. My own setup has /boot as part of the OS disk
that is snapshotted with the rest of the OS. The reason being is precisely
because we install files into /boot.
If Boom
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #7 from Alasdair Kergon ---
From the docs https://github.com/bmr-cymru/boom :
> Boom configuration data is stored in the /boot file system to permit
> the tool to be run from any booted instance of any installed operating system.
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #6 from Alasdair Kergon ---
Have you tried out using the package to swap between different environments or
snapshots?
Whichever environment you choose to boot into - with different instances of
root volumes and data etc. - you ne
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #5 from Neal Gompa ---
Marian,
Is there a solid reason for these things being in /boot as content managed by
the package? Can they not be installed in more normal locations?
My understanding is that boom doesn't do any _real_ boo
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #4 from Marian Csontos ---
Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=26891979
SRPM: https://mcsontos.fedorapeople.org/boom-boot/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #3 from Marian Csontos ---
I have made the package slightly more non-compliant, adding these:
python3-boom.noarch: W: non-etc-or-var-file-marked-as-conffile
/boot/boom/boom.conf
python3-boom.noarch: W: non-etc-or-var-file-marked-a
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
Neal Gompa changed:
What|Removed |Added
CC||ngomp...@gmail.com
Assignee|nob.
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
--- Comment #1 from Marian Csontos ---
Benefit to Fedora:
This package handles entries in /boot for both multiple linux distributions and
for snapshots of root filesystem.
This is for those old fashioned folks who do not run containers, atom
44 matches
Mail list logo
