Re: I may volunteer to be a package maintainer
On 11/8/18, Jochen Spieker <email@example.com> wrote:
> Robert Arkiletian:
>> I noticed that Debian and hence Ubuntu have dropped the "python-fltk"
>> If I volunteer to be the maintainer of the package is there
>> documentation I can read to learn how to become a package maintainer?
> You already received the relevant link for that.
There's also the Debian-Mentors listserv:
VERY patient responders on that list. If for any reason you don't
receive an immediate response, you need to just give it time for
someone to get a free moment to help.
You can find "debian-policy" as a package, too. I THOUGHT that
something similar to "maint-guide" just like Long Wind's link was also
available, but it's not pulling up in Buster. Ok, yup, just checked my
archive file hoard, and there's maint-guide from 2015 and 2017.
Searches for "developer", "manual", and "guide" by themselves used to
bring up LOTS of possibilities. Again... not in Buster? :)
>> Also, if this package is maintained in Debian will it also need a
>> maintainer in Ubuntu or will I also have to do that too. If yes, then
>> can I just maintain it for Ubuntu?
> If you maintain it in Debian, chances are that Ubuntu will just pick up
> automatically. I do not know the exact processes behind that. If you
> only maintain it in Ubuntu, Debian will most certainly not include it
> because you need a maintainer in Debian in any case.
My choice to primarily follow Debian quite a long time ago now was
based on a graph of the Linux family tree. Debian inspires a lot of
derivatives so Developers' work here stands a larger chance of helping
more users overall than if one opts to develop for a spinoff "child"
For me, it's just a personal *_CHOICE_* thing. It's why I'm trying to
self-teach about Linux itself these days, too (k/t Linux From
Scratch/LFS). Top of the family tree. :)
> Be it as may, Debian does not require any contributor to also contribute
> directly to Ubuntu. Ubuntu just uses a lot of work that was originally
> done for Debian. (I do not mean that as an insult, that's the way free
> software works.)
>> The main reason I ask that is I know Debian supports many
>> architectures, which I don't have access to. I was mainly just
>> interested in maintaining the AMD64 arch. Is this possible?
> I do not think that you have to worry much about that. I expect most
> package maintainers only have direct access to one or two architectures
> and the main one being AMD64. The Debian build infrastructure will do
> most of the work and I think if you need access to a machine of a
> different architecture for debugging you can always ask the maintainers
> of that architecture.
What about QEMU? I've used it a few times but never got so far as to
try outside of i386 and x86_64. Is QEMU viable as a starting point
where using it would at least save a little bit of testing/configuring
time for those who have the actual equipment?
Or have I completely misunderstood how QEMU operates? Totally possible
(!), but its description includes things like "full system emulation
of some architecture" so that's why I brought it up. :)
Ok, yeah, something's wrong with my "apt-cache search". I wanted to
share some QEMU packages as final examples of available
architectures... and this is all Buster is offering:
xserver-xorg-video-qxl - X.Org X server -- QXL display driver
qemu - fast processor emulator, dummy package
Maybe things are on Developer hold? I don't remember that being a
thing when I was using testing in the past, though. Seems like it was
only apparent during upgrades. Feeling a little like I've just stepped
off into the Twilight Zone. Where'd everybody go?! :))
Talking Rock, Pickens County, Georgia, USA
* runs with duct tape *