Hello.
I’m a kernel newbie and try to get involved into the Kernel development. So I’d
like to start with small bug fixes related to any subsystem (fs is preferred
since I familiar with it the most) or something like that.
Is there some kernel bug tracker where anybody could pick a bug to
omething like that.
>
> Is there some kernel bug tracker where anybody could pick a bug to fix and
> then send patches?
https://bugzilla.kernel.org/
There's as well per linux distribution / vendor bug reporting web
interfaces, like http://bugs.debian.org/ and/or
https://bugs.launchpad.
Hi Anatoly,
Thank you very much for your response. https://bugzilla.kernel.org looks
exactly what I was looking for.
--
Regards,
Adverg Ebashinskii
___
Kernelnewbies mailing list
[email protected]
https://lists.kernelnewbies.org
enough that i do not claim authorship.
So how about
Suggested-by: Thomas Schmitt
I found the bug and suggested an obvious fix.
The most kernel merit i can claim is that i grepped through the kernel
sources for callers of iso_date() and found them all ready for the change
of result type.
So
Hi Valdis,
> You might want to read this
Thanks for the info it was very interesting to read. My primary intention of
getting into the Linux Kernel Development is that I myself used to be a C/Linux
developer for years on the user side and pretty well-versed in the Linux
user-space API.
n which you want to participate in. It might
be virtualization, networking, storage, drivers, etc.. Any of that. Go to the
appropriate kernel bug tracker, pick a bug and then try to reproduce it,
fix it and send it as a patch. I tried many different strategies in
last 8 months, but it seems that this on
n which you want to participate in. It might
be virtualization, networking, storage, drivers, etc.. Any of that. Go to the
appropriate kernel bug tracker, pick a bug and then try to reproduce it,
fix it and send it as a patch. I tried many different strategies in
last 8 months, but it seems that this on
Hi,
I've started to take a look at TODO entries in the staging drivers
subtree and found some issues in pi433 I'd like to work on. Before
starting to prepare my patch, I tried to check the LKML and the bug
tracker to make sure nobody was working on the same issues as me
(this driver s
On Fri, Nov 29, 2019 at 3:04 PM Jeffrey Walton wrote:
> ...
> So now I am at:
>
> $ gcc -Wall -g2 -O1 ktls.c -o ktls
> $ ./ktls
> setsockopt failed, 524, Unknown error 524
Now open in the Fedora bug tracker:
https://bugzilla.redhat.com/show_
Hi Thomas,
Thanks for the brief explanation of the bugs.
> i'll hand over my patch as guideline, or as
> base for own work, or just for review, testing, and posting
If you could share your patch here to understand the problem better I would
gladly dig into it.
--
Regards,
Adverg Ebas
> Ok. Here is the simple one. The other comes in a separate mail.
Hello Thomas,
I will try to submit the simplest one first (my very first patch). There are to
questions: 1. When submitting the patch should I include you in the copy as the
original author? 2. Can I also co-sign the patch b
Is there a specific place where I can coordinate
> with the rest of the kernel dev community and make people aware I'm
> working on this particular issue ? (apart from the bug tracker, which
> doesn't seem to be very active when it comes to the staging subtree)
No need to
>Your best source for low-hanging fruit these days is probably drivers/staging,
> as pretty much everything under there is *known* to be less-than-optimal.
Thanks for the reply. The reason I looked for some bugs is that I’m not really
interested in driver development and digging into details
Hi,
maybe i should not have pasted my patches into a new mail.
My mail client shows the first mail as three mails. Possibly an effect
of the mailbox-like format which it got by pasting in two send-ready
git patches.
Strangely it shows the second mail with the Rock Ridge patch as a
single one.
Sor
On Mon, 28 May 2018 23:07:06 -0400, Hugo Lefeuvre said:
> Did I miss something ? Is there a specific place where I can coordinate
> with the rest of the kernel dev community and make people aware I'm
> working on this particular issue ? (apart from the bug tracker, which
> doesn&
e network card
> drivers? I believe the choices are
> linux-modules or linux-modules-extras.
Hi Jeffrey,
The best course of action here would be to file a bug on Ubuntu's bug
tracker: https://bugs.launchpad.net/ubuntu/+source/linux
Your instinct is correct though. The most commo
t 3:04 PM Jeffrey Walton wrote:
> > ...
> > So now I am at:
> >
> > $ gcc -Wall -g2 -O1 ktls.c -o ktls
> > $ ./ktls
> > setsockopt failed, 524, Unknown error 524
>
> Now open in the Fedora bug tracker:
>
or small easy patches to start with.
Hint: Many long-time kernel developers say the bugzilla is where kernel bugs go
to die.
That's because if it's an open bug in the bugzilla, one or more of the
following things are probably true:
* The bug has actually already been fixed but nobody
e:
>> > ...
>> > So now I am at:
>> >
>> > $ gcc -Wall -g2 -O1 ktls.c -o ktls
>> > $ ./ktls
>> > setsockopt failed, 524, Unknown error 524
>>
>> Now open in the Fedora bug tracker:
>> https://bugzilla.redhat.com/show_bug.cgi?
On Fri, 03 Sep 2021 13:00:55 +0200, "Thomas Schmitt" said:
> I could offer bugs of isofs with explanations and patch proposals:
>
> - isofs: prevent file time rollover after year 2038
> Change the return type of function iso_date() from int to time64_t.
The tricky part is, of course, that for t
Wall -g2 -O1 ktls.c -o ktls
> > $ ./ktls
> > setsockopt failed, 524, Unknown error 524
>
> Now open in the Fedora bug tracker:
> https://bugzilla.redhat.com/show_bug.cgi?id=1778348
Looks like the 'unknown error' issue is a glibc strerror() problem. On the
kern
-20. I hope the tester of this patch still
has the machine to confirm that the patch is still good.)
What is obviously missing with my skills is ability to get attention of
kernel developers for isofs and their trust that the proposals don't make
things worse.
As developer of libisof
Hi,
Valdis Klētnieks wrote:
> The tricky part is, of course, that for this to work correctly, you need
> to have 64-bit timestamps in the on-disk format.
Initially yes. In
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627
i sketched what it thought was needed to do.
But by the muc
Hi,
Adverg Ebashinskii wrote:
> If you could share your patch here to understand the problem better I would
> gladly dig into it.
Ok. Here is the simple one. The other comes in a separate mail.
The following texts stem from git format-patch. If submitting for real,
i would send them by git send-
Hi,
second patch proposal for isofs because Adverg Ebashinskii wrote:
> If you could share your patch here to understand the problem better I would
> gladly dig into it.
-cover-letter.patch
From 3d484405f0ad8d10ef490281
25 matches
Mail list logo
