7:20 a.m.
(i don't see any of these posts thus far in 2020, so perhaps
they've fallen out of vogue? i'm merely blindly complying with
the instructions at [0]).
hello there in RPM land! i'm a longtime linux user/developer.
my first Linux install was RedHat 5.1 in the summer of 1998,
and i've been Free ever since. i primarily run Debian and Arch
these days, but do some RHEL work professionally, and am very
interested in ensuring my software runs on rawhide and friends.
my immediate motivation for joining the Fedora community is
packaging up a recent library of mine, "notcurses", best
summarized as a baby of ncurses and ffmpeg [1]. there's a demo
here [2] that you might find entertaining. i've written a book
which is available for purchase [3] or free download [4]. i've
spoken with Mssr. David Cantrell, a fellow Yellow Jacket, and
believe in him to have secured a sponsor.
i'd then like to look into getting my disk-management tool
"growlight" and perhaps my network security recon tool
"omphalos" into rawhide. more than that, i hope to become more
expert with this family of Linuxes.
hack on! --nick
[0] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[1] https://nick-black.com/dankwiki/index.php/Notcurses
[2] https://www.youtube.com/watch?v=-H1WkopWJNM&feature=youtu.be
[3] https://www.amazon.com/dp/B086PNVNC9
[4] https://nick-black.com/htp-notcurses.pdf
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
7:34 a.m.
Hello!
On Mon, Apr 6, 2020 at 7:21 AM Nick Black <dank(a)qemfd.net> wrote:
(i don't see any of these posts thus far in 2020, so perhaps
they've fallen out of vogue? i'm merely blindly complying with
the instructions at [0]).
hello there in RPM land! i'm a longtime linux user/developer.
my first Linux install was RedHat 5.1 in the summer of 1998,
and i've been Free ever since. i primarily run Debian and Arch
these days, but do some RHEL work professionally, and am very
interested in ensuring my software runs on rawhide and friends.
my immediate motivation for joining the Fedora community is
packaging up a recent library of mine, "notcurses", best
summarized as a baby of ncurses and ffmpeg [1]. there's a demo
here [2] that you might find entertaining. i've written a book
which is available for purchase [3] or free download [4]. i've
spoken with Mssr. David Cantrell, a fellow Yellow Jacket, and
believe in him to have secured a sponsor.
Ok, well let me know if you need a sponsor. I generally prefer CMake based
projects anyway :)
So the only problem I see is that notcurses depends on ffmpeg, which is not
allowed in Fedora. I see it's technically "optional", but I wonder about
the usefulness of the resultant package without it.
It's technically possible to be sponsored at RPM Fusion first (I was) but
it's not preferred. Perhaps one of your other projects could be submitted
here first?
Thanks,
Richard
7:45 a.m.
Richard Shaw left as an exercise for the reader:
So the only problem I see is that notcurses depends on ffmpeg, which
is not
allowed in Fedora. I see it's technically "optional", but I wonder about
the usefulness of the resultant package without it.
ooh, I was unaware of this. FFmpeg is only used for
decoding/scaling images and video. An NCURSES-like level of
functionality is possible without it, one which will still
benefit from e.g. RGB color and multithreading safety.
I've been considering throwing another image-decoding backend
into the project, as FFmpeg draws in a huge dependency chain on
Debian as well. What's the preferred "kitchen sink" image
decoder these days? libimagemagick? What's recommended for
Fedora/Rawhide, if I ideally want to:
1) throw a file/memory buffer at the lib without having to know
anything about image format,
2) get 24-bit RGB or 32-bit RGBA back, and
3) have it handle scaling?
It's technically possible to be sponsored at RPM Fusion first (I
was) but
it's not preferred. Perhaps one of your other projects could be submitted
here first?
I'm not sure I understand your meaning. Do you have a page I can
reference? Thanks!
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
7:53 a.m.
On Mon, Apr 6, 2020 at 7:46 AM Nick Black <dankamongmen(a)gmail.com> wrote:
Richard Shaw left as an exercise for the reader:
> So the only problem I see is that notcurses depends on ffmpeg, which is
not
> allowed in Fedora. I see it's technically "optional", but I wonder
about
> the usefulness of the resultant package without it.
ooh, I was unaware of this. FFmpeg is only used for
decoding/scaling images and video. An NCURSES-like level of
functionality is possible without it, one which will still
benefit from e.g. RGB color and multithreading safety.
Up to you which way to go... I don't see packaging it in RPM Fusion as a
problem. I would think most people who would be interested in this package
would likely not have a problem enabling RPM Fusion.
I've been considering throwing another image-decoding backend
into the project, as FFmpeg draws in a huge dependency chain on
Debian as well. What's the preferred "kitchen sink" image
decoder these days? libimagemagick? What's recommended for
Fedora/Rawhide, if I ideally want to:
1) throw a file/memory buffer at the lib without having to know
anything about image format,
2) get 24-bit RGB or 32-bit RGBA back, and
3) have it handle scaling?
The best candidate I can think of that would at least handle 2 and 3 would
be OpenImageIO (which I maintain for Fedora). I'm not an expert at using it
though, but it is a dependency for Blender for Cycles rendering.
It's well maintained and the author is very helpful and responds to
questions quickly via the mailing list. It in combination with OpenColorIO
(which I also maintain) have been used in production of several animated
movies so you know it's very robust.
It's technically possible to be sponsored at RPM Fusion first (I
was) but
> it's not preferred. Perhaps one of your other projects could be submitted
> here first?
I'm not sure I understand your meaning. Do you have a page I can
reference? Thanks!
Unlike Debian, Fedora is hosted in the US so RPM Fusion exists to package
programs with patent/licensing issues (rpmfusion-free) including binary
blobs like the NVidia drivers (rpmfusion-nonfree).
Only fully FOSS without patent or licences issues can be packaged in Fedora.
Thanks,
Richard
8:03 a.m.
Richard Shaw left as an exercise for the reader:
Up to you which way to go... I don't see packaging it in RPM
Fusion as a
problem. I would think most people who would be interested in this package
would likely not have a problem enabling RPM Fusion.
So, if you've seen the demo, that's not really at all the
intended usage. The main goal is to facilitate really attractive
versions of things like GTop, htop, s-tui, etc. I'd written some
very substantial NCURSES programs, and found the process
unpleasant and the results wanting. The primary goal was making
things like
https://nick-black.com/dankwiki/index.php/Growlight and
https://nick-black.com/dankwiki/index.php/Omphalos
look better and be easier to hack on. Neither, you'll note, uses
fancy images or video :). So since this is primarily intended as
a library fit for arbitrary systems applications, I'd probably
want to aim for the "core" repo (assuming that core repo
packages can only dep on projects in the core repo).
Now, a "notcurses-noffmpeg" version in Core and a
"notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
thing ever done?
It's well maintained and the author is very helpful and responds
to
questions quickly via the mailing list. It in combination with OpenColorIO
(which I also maintain) have been used in production of several animated
movies so you know it's very robust.
I remember being impressed by OpenImageIO when I last looked at
it (2013 or so). I'll take a look into it, thanks!
Unlike Debian, Fedora is hosted in the US so RPM Fusion exists to
package
programs with patent/licensing issues (rpmfusion-free) including binary
blobs like the NVidia drivers (rpmfusion-nonfree).
Only fully FOSS without patent or licences issues can be packaged in Fedora.
Got it, so very similar to the "main" vs "non-free" split in
Debian, except it looks like FFmpeg ended up on the wrong side
of the divide in Fedora :).
It looks like GStreamer is in Core, and that would give me video
decoding, which would be nice to retain.
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
1:34 p.m.
On Mon, Apr 06, 2020 at 09:03:54AM -0400, Nick Black wrote:
Richard Shaw left as an exercise for the reader:
> Up to you which way to go... I don't see packaging it in RPM Fusion as a
> problem. I would think most people who would be interested in this package
> would likely not have a problem enabling RPM Fusion.
So, if you've seen the demo, that's not really at all the
intended usage. The main goal is to facilitate really attractive
versions of things like GTop, htop, s-tui, etc. I'd written some
very substantial NCURSES programs, and found the process
unpleasant and the results wanting. The primary goal was making
things like
https://nick-black.com/dankwiki/index.php/Growlight and
https://nick-black.com/dankwiki/index.php/Omphalos
look better and be easier to hack on. Neither, you'll note, uses
fancy images or video :). So since this is primarily intended as
a library fit for arbitrary systems applications, I'd probably
want to aim for the "core" repo (assuming that core repo
packages can only dep on projects in the core repo).
Now, a "notcurses-noffmpeg" version in Core and a
"notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
thing ever done?
That's kind of clunky, IMHO. Splitting out the ffmpeg support as a
loadable runtime module like you see with gstreamer and gdk-pixbuf would
be easier to package and split between repos. That might necessitate
splitting out the ffmpeg functionality as a separate source repo. Or at least
release notcurses and notcurses-ffmpeg separately.
> It's well maintained and the author is very helpful and
responds to
> questions quickly via the mailing list. It in combination with OpenColorIO
> (which I also maintain) have been used in production of several animated
> movies so you know it's very robust.
I remember being impressed by OpenImageIO when I last looked at
it (2013 or so). I'll take a look into it, thanks!
> Unlike Debian, Fedora is hosted in the US so RPM Fusion exists to package
> programs with patent/licensing issues (rpmfusion-free) including binary
> blobs like the NVidia drivers (rpmfusion-nonfree).
> Only fully FOSS without patent or licences issues can be packaged in Fedora.
Got it, so very similar to the "main" vs "non-free" split in
Debian, except it looks like FFmpeg ended up on the wrong side
of the divide in Fedora :).
It looks like GStreamer is in Core, and that would give me video
decoding, which would be nice to retain.
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
2:15 p.m.
On Mon, 6 Apr 2020 09:03:54 -0400
Nick Black <dankamongmen(a)gmail.com> wrote:
Now, a "notcurses-noffmpeg" version in Core and a
"notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
thing ever done?
I think this is still true for audacity, mplayer, and chromium so they
get patented video codec support. Before mpeg was completely off patent,
there were other audio applications where this happened, with the
rpmfusion version adding support for mp3.
2:32 p.m.
On Mon, Apr 6, 2020 at 8:03 AM Nick Black <dankamongmen(a)gmail.com> wrote:
Richard Shaw left as an exercise for the reader:
> Up to you which way to go... I don't see packaging it in RPM Fusion as a
> problem. I would think most people who would be interested in this
package
> would likely not have a problem enabling RPM Fusion.
So, if you've seen the demo, that's not really at all the
intended usage. The main goal is to facilitate really attractive
versions of things like GTop, htop, s-tui, etc. I'd written some
very substantial NCURSES programs, and found the process
unpleasant and the results wanting. The primary goal was making
things like
https://nick-black.com/dankwiki/index.php/Growlight and
https://nick-black.com/dankwiki/index.php/Omphalos
look better and be easier to hack on. Neither, you'll note, uses
fancy images or video :). So since this is primarily intended as
a library fit for arbitrary systems applications, I'd probably
want to aim for the "core" repo (assuming that core repo
packages can only dep on projects in the core repo).
Now, a "notcurses-noffmpeg" version in Core and a
"notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
thing ever done?
Yes, there's a number of examples but audacity and sox are two. What we do
at RPM Fusion is create a new package there that depends on the package in
Fedora and either append -freeworld (just patent issues, like ffmpeg which
are in the free repo), or append -nonfree for packages that depend on "free
as in beer" instead of "free as in speech" libraries.
There are a few requirements though to make this work (and I'm not an
expert here so correct me if I'm wrong!)
1. The library needs to be dlopen()'ed from the main package so it'll still
function without the "extra" packages from RPM Fusion.
2. All the bits common to the main package need to be excluded from the RPM
Fusion package since we can't (and don't want to) have redunded files in
the package. This may look like "libnotcurses-ffmpeg.so.<soname}" which
would be the only payload in the RPM Fusion -freeworld package.
It looks like GStreamer is in Core, and that would give me video
decoding, which would be nice to retain.
Yup! Only the bits that NEED to go into the RPM Fusion -freeworld package
would be included.
Thanks,
Richard
2:46 p.m.
Richard Shaw left as an exercise for the reader:
Yes, there's a number of examples but audacity and sox are two.
What we do
at RPM Fusion is create a new package there that depends on the package in
Fedora and either append -freeworld (just patent issues, like ffmpeg which
are in the free repo), or append -nonfree for packages that depend on "free
as in beer" instead of "free as in speech" libraries.
There are a few requirements though to make this work (and I'm not an
expert here so correct me if I'm wrong!)
1. The library needs to be dlopen()'ed from the main package so it'll still
function without the "extra" packages from RPM Fusion.
2. All the bits common to the main package need to be excluded from the RPM
Fusion package since we can't (and don't want to) have redunded files in
the package. This may look like "libnotcurses-ffmpeg.so.<soname}" which
would be the only payload in the RPM Fusion -freeworld package.
This is exactly how I intend to structure my "notcurses-minimal"
for Debian, so it oughtn't be much extra work, excellent:
https://github.com/dankamongmen/notcurses/issues/339
Alright, I'll look into this. BTW, while I've read the Packaging
Guidelines at https://docs.fedoraproject.org/en-US/packaging-guidelines/,
there seem to be some operational details that I'm missing. For
instance, it seems I need file a bug once I have my source and
binary RPMs -- where can I find details on the necessary
information in that bug? Sorry if I've overlooked it :/.
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
7:55 a.m.
On Mon, Apr 06, 2020 at 08:20:47AM -0400, Nick Black wrote:
hello there in RPM land! i'm a longtime linux user/developer.
my first Linux install was RedHat 5.1 in the summer of 1998,
and i've been Free ever since.
Hey hey, it's a small world. :)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
1:32 p.m.
On Mon, Apr 06, 2020 at 08:20:47AM -0400, Nick Black wrote:
(i don't see any of these posts thus far in 2020, so perhaps
they've fallen out of vogue? i'm merely blindly complying with
the instructions at [0]).
hello there in RPM land! i'm a longtime linux user/developer.
my first Linux install was RedHat 5.1 in the summer of 1998,
and i've been Free ever since. i primarily run Debian and Arch
these days, but do some RHEL work professionally, and am very
interested in ensuring my software runs on rawhide and friends.
my immediate motivation for joining the Fedora community is
packaging up a recent library of mine, "notcurses", best
summarized as a baby of ncurses and ffmpeg [1]. there's a demo
here [2] that you might find entertaining. i've written a book
which is available for purchase [3] or free download [4]. i've
spoken with Mssr. David Cantrell, a fellow Yellow Jacket, and
believe in him to have secured a sponsor.
Greetings and welcome!
i'd then like to look into getting my disk-management tool
"growlight" and perhaps my network security recon tool
"omphalos" into rawhide. more than that, i hope to become more
expert with this family of Linuxes.
hack on! --nick
[0] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[1] https://nick-black.com/dankwiki/index.php/Notcurses
[2] https://www.youtube.com/watch?v=-H1WkopWJNM&feature=youtu.be
[3] https://www.amazon.com/dp/B086PNVNC9
[4] https://nick-black.com/htp-notcurses.pdf
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1491
days inactive
1491
days old
10 comments
6 participants
participants (6)
-
David Cantrell -
Nick Black -
Nick Black -
Richard Shaw -
Solomon Peachy -
stan