Re: [mythtv] Update to latest fixes/31.
On Mon, Mar 1, 2021 at 2:05 AM Sérgio Basto wrote: > [1] > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches Thank you for confirming that the current practice (patches in dist-git) is an approved one (in fact even the default one), and while one MAY choose to do things differently to deal with others poor MUA or editor choices, or the emails that certain processes create, it is not a requirement, nor should it become one(*). (*) Until/unless there is a consensus of a change in guidelines, were perhaps some MAYs could turn into MUSTs, which you have suggested you intend to propose. I look forward to the discussion on the formal proposal. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31.
On Sun, 2021-02-28 at 13:40 +0100, Kevin Kofler via rpmfusion- developers wrote: > Sérgio Basto wrote: > > Maybe we should change the guidelines. This is common sense . Why > you > > want receive a patch with 28k , you going to read it ? or just to > > fulfill the guideline . > > Then maybe the RPM Fusion git hook should do what other projects' git > hooks > do and just truncate the long changeset, and put a link to the full > changeset in the web interface at a prominent place in the mail. > > Dealing with large text files is something git is perfectly designed > and > able to do, so we should not work around bugs and limitations in > other > infrastructure by not using git as designed. My point of view is about readable emails and readable cgit web pages, when we do a commit is sent an email to devel mailing list and very large diff files shouldn't be send to email. [1] which is not the case , 32k of patch file is a layer itself . [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection (as putting them into lookaside would do). > Kevin Kofler -- Sérgio M. B. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #23 from Marcus Müller --- > Sponsorship to packager group is done Thank you very much, this is all very generous, by the way! > See the guide https://rpmfusion.org/Contributors#Your_package_gets_approved Excellent, exactly what I was reading. Package requested: user: marcusmueller request package: welle-io on branch master user: marcusmueller request package: welle-io on branch f34 user: marcusmueller request package: welle-io on branch f33 user: marcusmueller request package: welle-io on branch f32 -- You are receiving this mail because: You are on the CC list for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #22 from leigh scott --- (In reply to Marcus Müller from comment #21) > Done that. Awesome! > > So, now I'm waiting to be admitted to the packager group, after which I can Sponsorship to packager group is done > request a new packet, after which I can import the srpm with `rfpkg import`, > right? See the guide https://rpmfusion.org/Contributors#Your_package_gets_approved -- You are receiving this mail because: You are on the CC list for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #21 from Marcus Müller --- Done that. Awesome! So, now I'm waiting to be admitted to the packager group, after which I can request a new packet, after which I can import the srpm with `rfpkg import`, right? -- You are receiving this mail because: You are on the CC list for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937
--- Comment #20 from leigh scott ---
(In reply to leigh scott from comment #19)
> Specfile is ok.
> It builds ok. https://koji.rpmfusion.org/koji/taskinfo?taskID=471761
> Lint is ok.
>
> $ rpmlint welle-io-2.2-7.fc35.x86_64.rpm
> welle-io.x86_64: W: no-manual-page-for-binary welle-cli
> welle-io.x86_64: W: no-manual-page-for-binary welle-io
> 1 packages and 0 specfiles checked; 0 errors, 2 warnings.
>
>
> Please delete the bundled faad2 and mpg123 in %prep section before you
> import the package.
>
>
> %prep
> %setup -q -n welle.io-%{version}
> rm -rf src/libs/faad2
> rm -rf src/libs/mpg123
>
>
> Package approved.
Also fix directory ownership of
%{_datadir}/welle-io/html/index.*
change to
%{_datadir}/welle-io/
--
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937
leigh scott changed:
What|Removed |Added
Assignee|rpmfusion-package-review@rp |leigh123li...@gmail.com
|mfusion.org |
Flags||fedora-review+
--- Comment #19 from leigh scott ---
Specfile is ok.
It builds ok. https://koji.rpmfusion.org/koji/taskinfo?taskID=471761
Lint is ok.
$ rpmlint welle-io-2.2-7.fc35.x86_64.rpm
welle-io.x86_64: W: no-manual-page-for-binary welle-cli
welle-io.x86_64: W: no-manual-page-for-binary welle-io
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
Please delete the bundled faad2 and mpg123 in %prep section before you import
the package.
%prep
%setup -q -n welle.io-%{version}
rm -rf src/libs/faad2
rm -rf src/libs/mpg123
Package approved.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #18 from Marcus Müller --- Regarding CentOS7/EPEL7 compatibility: Indeed impossible to achieve without packaging qt5-qtcharts-devel; No CentOS7 / EPEL package ships qt5/QtCharts/*.h, so that won't work. Therefore, I'm currently not considering adding a backwards-compatibility-enabling %cmake3 clause. Regarding %setup/%autosetoip: The future-patching-compatibility argument weighs heavy, so switched to %autosetup. now at 2.2-8. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #17 from Marcus Müller --- > And unfortunately, the introduction of %autosetup has made it more, not less, > likely to forget applying a patch, because now you end up assuming that the > package uses %autosetup and forget about adding the %patch line if it doesn't. I'm willing to say that'd be an argument in favor of %autosetup, i.e. for not adding yet another package where that might happen. General remark: It's a bit hard for me to stay atop what are "required changes for approval" and what are "general discussions on packaging guidelines", and what the state of my package is. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
RPM Fusion update report 2021-02-28
RPM Fusion update report Section free: - Fedora 32 - Pushed to testing: mythtv-31.0-15.139.20210226gitb6ddf202a4.fc32 shotcut-21.02.27-1.fc32 vdr-markad-2.6.3-1.fc32 vdr-softhddevice-1.0.14-1.fc32 Pushed to stable: shotcut-21.02.15-1.fc32 v4l2loopback-0.12.5-2.fc32 v4l2loopback-kmod-0.12.5-3.fc32 xtables-addons-3.15-1.fc32 xtables-addons-kmod-3.15-1.fc32 Fedora 33 - Pushed to testing: mythtv-31.0-15.139.20210226gitb6ddf202a4.fc33 shotcut-21.02.27-1.fc33 vdr-markad-2.6.3-1.fc33 vdr-softhddevice-1.0.14-1.fc33 Pushed to stable: shotcut-21.02.15-1.fc33 telegram-desktop-2.6.1-1.fc33 tg_owt-0-7.20210203gita198773.fc33 v4l2loopback-0.12.5-2.fc33 v4l2loopback-0.12.5-3.fc32 v4l2loopback-0.12.5-3.fc33 v4l2loopback-kmod-0.12.5-3.fc33 xtables-addons-3.15-1.fc33 xtables-addons-kmod-3.15-1.fc33 Fedora 34 - Pushed to testing: bino-1.6.7-8.fc34 gstreamer1-libav-1.18.2-4.fc34 libopenshot-0.2.5-8.fc34 mythtv-31.0-15.139.20210226gitb6ddf202a4.fc34 rpmfusion-free-obsolete-packages-34-1.fc34 shotcut-21.02.27-1.fc34 vdr-markad-2.6.3-1.fc34 vdr-softhddevice-1.0.14-1.fc34 Pushed to stable: chromium-freeworld-88.0.4324.150-1.fc34 deadbeef-1.8.7-1.fc34 gr-dab-0.4-7.fc34 shotcut-21.02.15-1.fc34 telegram-desktop-2.6.1-1.fc34 tg_owt-0-7.20210203gita198773.fc34 v4l2loopback-0.12.5-2.fc34 v4l2loopback-0.12.5-3.fc34 v4l2loopback-kmod-0.12.5-3.fc34 xtables-addons-3.15-1.fc34 xtables-addons-kmod-3.15-1.fc34 EL 7 - Pushed to testing: Pushed to stable: EL 8 - Pushed to testing: mythtv-31.0-15.139.20210226gitb6ddf202a4.el8 v4l2loopback-0.12.5-3.el8 Pushed to stable: v4l2loopback-0.12.5-2.el8 v4l2loopback-kmod-0.12.5-3.el8 xtables-addons-3.15-1.el8 xtables-addons-kmod-3.15-1.el8 Section nonfree: - Fedora 32 - Pushed to testing: Pushed to stable: Fedora 33 - Pushed to testing: Pushed to stable: Fedora 34 - Pushed to testing: Pushed to stable: EL 7 - Pushed to testing: Pushed to stable: EL 8 - Pushed to testing: Pushed to stable: nvidia-kmod-460.56-1.el8 nvidia-modprobe-460.56-1.el8 nvidia-persistenced-460.56-1.el8 nvidia-settings-460.56-1.el8 nvidia-xconfig-460.56-1.el8 xorg-x11-drv-nvidia-460.56-1.el8 Theses packages will be available in main mirror in a few hours. Wait for local mirrors to sync Please report any issue to https://bugzilla.rpmfusion.org ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #15 from Vitaly Zaitsev --- > Isn't %autosetup for autoconf things? No. > What's wrong with %setup here? %autosetup will automatically apply all patches if present in SPEC file. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #14 from Marcus Müller --- I retract the remark about autoconf; https://rpm.org/user_doc/autosetup.html Is this a recommended things to do in the absence of any patches? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #13 from Marcus Müller --- Isn't %autosetup for autoconf things? What's wrong with %setup here? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937
--- Comment #12 from Vitaly Zaitsev ---
> %setup -q -n welle.io-%{version}
You can use %autosetup -n welle.io-%{version}.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #11 from Nicolas Chauvet --- (In reply to leigh scott from comment #7) ... > > cmake3 is a legacy and deprecated tool only for EPEL7. It shouldn't be used > > in the regular Fedora packaging. Do not use it. EL7 is still supported until 2024, so when possible to introduce new package there. It's also relevant to use cmake3 macros everywhere to ease reading and permit fast-forward updates. This should be at the package maintainer discretion for me. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31.
The way the specfile pulls in the latest git commit as a patch against the release tarball is new to me. I interpretated that workflow to mean those before me thought it was important to document all the commits that were made. That's why I did not add the patch as a rfpkg source and instead included it with our git history. However, if I do add the patch file as a rfpkg source per the original request, then why bother pulling down the changes as a separate patch at all? Rpmfusion github won't track the changes this way. Why not keep it simple and pull in one tarball that contains everything? Just looking to understand. Le dim. 28 févr. 2021 à 08:08, Gary Buhrmaster a écrit : > > On Sun, Feb 28, 2021 at 4:14 AM Sérgio Basto wrote: > > > Maybe we should change the guidelines. > > I suspect your formal proposal will generate some > interesting discussion. I think it will be even more relevant to compress (gz, xz, etc) the patches from upstream Then you can just apply them compressed, the %patch macro will deal with the compression while applying. The reason why I think this is revelant for lookaside is that the patches where already applied/reviewed upstream, So having "peer reviewing", on the rpmfusion mailing list, for any eventual other downstream patch will be hidden or much more difficult. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937
Marcus Müller changed:
What|Removed |Added
Hardware|x86_64 |All
--- Comment #10 from Marcus Müller ---
Thanks everyone for the rapid feedback!
I've done the (unambigously recommended) changes requested, as far as possible.
Please check the .spec file in the git repo. COPR builds are all running
through:
https://copr.fedorainfracloud.org/coprs/marcusmueller/Welle.io/build/2024622/
> 1. Remove
> Group: Audio
Done. (oops, I knew that fedora packaging guideline.)
> 2. Change
> to
> Source0:
> https://github.com/AlbrechtL/welle.io/archive/v%{version}/%{name}-%{version}.tar.gz
Done. Note that the github project is called "welle.io", but the package
"welle-io"
> 3. %cmake3
cmake change not done; if EPEL7 support is desired, I'll gladly if/else that
in; I suspect with a Qt5-quick-depending, multiple codecs-depending project,
there's more to be done to achieve that compatibility, anyways.
> 4. Change
> %setup -q -n welle.io-%{version}
> to
> %setup -q
Can't do that! The tarball contains a folder welle.io-%{version}, not
welle-io-%{version}, so we need to tell %setup about that. I'm very open to
alternatives to this, but I don't see one that's less confusing / specific than
actually using the directory name.
(without -n ..., `fedpkg local` fails in setup; I tried.)
> 5. Use macros for %files
Done. (By the way, is there an rpmlint config that would check for such basic
things?)
> 6. Validate to desktop file
Done.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #9 from Vitaly Zaitsev --- Also EPEL7 is an ancient thing. No new packages should be built and pushed to its repository. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #8 from Vitaly Zaitsev --- > Where did you get that idea from, it's wrong. It was added to Fedora for compatibility purposes only. When cmake 4 will be released, they will be removed. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #7 from leigh scott --- (In reply to Vitaly Zaitsev from comment #5) > > 3. Change > > BuildRequires: cmake > > to > > BuildRequires: cmake3 > > cmake3 is a legacy and deprecated tool only for EPEL7. It shouldn't be used > in the regular Fedora packaging. Do not use it. Where did you get that idea from, it's wrong. $ rpm -q --provides cmake-3.19.4-2.fc34.x86_64 |grep cmake3 cmake3 = 3.19.4-2.fc34 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 --- Comment #6 from Vitaly Zaitsev --- > Using compatible macros with Epel is good practice, TBH I don't understand > why the guidelines recommend the un-versioned? Since cmake3 is a special EPEL7-only package, as regular cmake points to a very outdated version 2. That's why the new package and macros were introduced. They shouldn't be used outside of the EPEL7. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
[Bug 5937] Review Request: welle-io - Receiver for DAB and DAB+ broadcast radio
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5937 Vitaly Zaitsev changed: What|Removed |Added CC||vit...@easycoding.org --- Comment #5 from Vitaly Zaitsev --- > 3. Change > BuildRequires: cmake > to > BuildRequires: cmake3 cmake3 is a legacy and deprecated tool only for EPEL7. It shouldn't be used in the regular Fedora packaging. Do not use it. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31.
Le dim. 28 févr. 2021 à 08:08, Gary Buhrmaster a écrit : > > On Sun, Feb 28, 2021 at 4:14 AM Sérgio Basto wrote: > > > Maybe we should change the guidelines. > > I suspect your formal proposal will generate some > interesting discussion. I think it will be even more relevant to compress (gz, xz, etc) the patches from upstream Then you can just apply them compressed, the %patch macro will deal with the compression while applying. The reason why I think this is revelant for lookaside is that the patches where already applied/reviewed upstream, So having "peer reviewing", on the rpmfusion mailing list, for any eventual other downstream patch will be hidden or much more difficult. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
