Examine individual changes
From Gentoo Wiki
This page allows you to examine the variables generated by the Abuse Filter for an individual change, and test it against filters.
Variables generated for this change
| Variable | Value |
|---|---|
Edit count of the user (user_editcount) | 22 |
Name of the user account (user_name) | '7upLime' |
Age of the user account (user_age) | 59539477 |
Page ID (page_id) | 0 |
Page namespace (page_namespace) | 2 |
Page title (without namespace) (page_title) | '7upLime/notes/ebuild hacking howto' |
Full page title (page_prefixedtitle) | 'User:7upLime/notes/ebuild hacking howto' |
Action (action) | 'edit' |
Edit summary/reason (summary) | 'Intro' |
Old content model (old_content_model) | '' |
New content model (new_content_model) | 'wikitext' |
Old page wikitext, before the edit (old_wikitext) | '' |
New page wikitext, after the edit (new_wikitext) | '= ebuild Hacking HOWTO =
My personal workflow (always ready to accept suggesions) for hacking on Gentoo ebuilds.
A Gentoo user can see the merging process split in its different phases and can intervene manually at each step.</br>
One can work on a project at a certain release version, as downloaded and unpacked by portage. If you have a testing machine (preferably separated from your main machine, but not required) with all the tools installed, you can easily play with the sources, compile them and eventually start again from freshly unpacked sources if what you've done is messy; the objective of all of this is developing your own patch for that specific ebuild.
Once you have a patch file for an ebuild, you add that to the patches folder in your personal overlay's ebuild (your own gentoo repo).
The patch can now remain in your personal overlay, or being submitted for review to the gentoo community, or if it makes sense, be submitted to the project's upstream.
In the rest of this article, I'm going to outline my personal workflow.
== Picking a Bug to work on ==
The first step would be of course to have a direction.
Sometimes help is well accepted to solve bugs that affect the generality of users.
{{Link|https://bugs.gentoo.org|bugs.gentoo.org}} could easily be the first place to check, to find something interesting to work on.
Once something interesting has been found, like one of {{Link|https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=1|those}} issues related to the {{Link|https://wiki.gentoo.org/wiki/Modern_C_porting#How_do_I_reproduce_these_bugs.3F|Modernizing C}} project, it is important to verify if the bug still persists at the version of the .ebuild marked in the bug.
=== Setting up a development environment ===
I'd like to go with the container-based approach.
I would start with an official gentoo image on docker hub, to then have it updated and installing the toolchain and dependencies using binary packages. In the current use case (modernizing C), emerging clang/gcc can be quite time-consuming; keeping in mind that we're gonna throw the container afterwards, I think that Gentoo's binary packages would brilliantly serve the purpose of setting up our environment fast.' |
Unified diff of changes made by edit (edit_diff) | '@@ -1,0 +1,22 @@
+= ebuild Hacking HOWTO =
+My personal workflow (always ready to accept suggesions) for hacking on Gentoo ebuilds.
+
+A Gentoo user can see the merging process split in its different phases and can intervene manually at each step.</br>
+
+One can work on a project at a certain release version, as downloaded and unpacked by portage. If you have a testing machine (preferably separated from your main machine, but not required) with all the tools installed, you can easily play with the sources, compile them and eventually start again from freshly unpacked sources if what you've done is messy; the objective of all of this is developing your own patch for that specific ebuild.
+
+Once you have a patch file for an ebuild, you add that to the patches folder in your personal overlay's ebuild (your own gentoo repo).
+The patch can now remain in your personal overlay, or being submitted for review to the gentoo community, or if it makes sense, be submitted to the project's upstream.
+
+In the rest of this article, I'm going to outline my personal workflow.
+
+== Picking a Bug to work on ==
+The first step would be of course to have a direction.
+Sometimes help is well accepted to solve bugs that affect the generality of users.
+{{Link|https://bugs.gentoo.org|bugs.gentoo.org}} could easily be the first place to check, to find something interesting to work on.
+
+Once something interesting has been found, like one of {{Link|https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=1|those}} issues related to the {{Link|https://wiki.gentoo.org/wiki/Modern_C_porting#How_do_I_reproduce_these_bugs.3F|Modernizing C}} project, it is important to verify if the bug still persists at the version of the .ebuild marked in the bug.
+
+=== Setting up a development environment ===
+I'd like to go with the container-based approach.
+I would start with an official gentoo image on docker hub, to then have it updated and installing the toolchain and dependencies using binary packages. In the current use case (modernizing C), emerging clang/gcc can be quite time-consuming; keeping in mind that we're gonna throw the container afterwards, I think that Gentoo's binary packages would brilliantly serve the purpose of setting up our environment fast.
' |
Old page size (old_size) | 0 |
Lines added in edit (added_lines) | [
0 => '= ebuild Hacking HOWTO =',
1 => 'My personal workflow (always ready to accept suggesions) for hacking on Gentoo ebuilds.',
2 => '',
3 => 'A Gentoo user can see the merging process split in its different phases and can intervene manually at each step.</br>',
4 => '',
5 => 'One can work on a project at a certain release version, as downloaded and unpacked by portage. If you have a testing machine (preferably separated from your main machine, but not required) with all the tools installed, you can easily play with the sources, compile them and eventually start again from freshly unpacked sources if what you've done is messy; the objective of all of this is developing your own patch for that specific ebuild. ',
6 => '',
7 => 'Once you have a patch file for an ebuild, you add that to the patches folder in your personal overlay's ebuild (your own gentoo repo).',
8 => 'The patch can now remain in your personal overlay, or being submitted for review to the gentoo community, or if it makes sense, be submitted to the project's upstream.',
9 => '',
10 => 'In the rest of this article, I'm going to outline my personal workflow.',
11 => '',
12 => '== Picking a Bug to work on ==',
13 => 'The first step would be of course to have a direction.',
14 => 'Sometimes help is well accepted to solve bugs that affect the generality of users.',
15 => '{{Link|https://bugs.gentoo.org|bugs.gentoo.org}} could easily be the first place to check, to find something interesting to work on.',
16 => '',
17 => 'Once something interesting has been found, like one of {{Link|https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=1|those}} issues related to the {{Link|https://wiki.gentoo.org/wiki/Modern_C_porting#How_do_I_reproduce_these_bugs.3F|Modernizing C}} project, it is important to verify if the bug still persists at the version of the .ebuild marked in the bug.',
18 => '',
19 => '=== Setting up a development environment ===',
20 => 'I'd like to go with the container-based approach.',
21 => 'I would start with an official gentoo image on docker hub, to then have it updated and installing the toolchain and dependencies using binary packages. In the current use case (modernizing C), emerging clang/gcc can be quite time-consuming; keeping in mind that we're gonna throw the container afterwards, I think that Gentoo's binary packages would brilliantly serve the purpose of setting up our environment fast.'
] |
Lines removed in edit (removed_lines) | [] |
New page text, stripped of any markup (new_text) | 'ebuild Hacking HOWTO[edit | edit source]
My personal workflow (always ready to accept suggesions) for hacking on Gentoo ebuilds.
A Gentoo user can see the merging process split in its different phases and can intervene manually at each step.
One can work on a project at a certain release version, as downloaded and unpacked by portage. If you have a testing machine (preferably separated from your main machine, but not required) with all the tools installed, you can easily play with the sources, compile them and eventually start again from freshly unpacked sources if what you've done is messy; the objective of all of this is developing your own patch for that specific ebuild.
Once you have a patch file for an ebuild, you add that to the patches folder in your personal overlay's ebuild (your own gentoo repo).
The patch can now remain in your personal overlay, or being submitted for review to the gentoo community, or if it makes sense, be submitted to the project's upstream.
In the rest of this article, I'm going to outline my personal workflow.
Picking a Bug to work on[edit | edit source]
The first step would be of course to have a direction.
Sometimes help is well accepted to solve bugs that affect the generality of users.
bugs.gentoo.org could easily be the first place to check, to find something interesting to work on.
Once something interesting has been found, like one of those issues related to the Modernizing C project, it is important to verify if the bug still persists at the version of the .ebuild marked in the bug.
Setting up a development environment[edit | edit source]
I'd like to go with the container-based approach.
I would start with an official gentoo image on docker hub, to then have it updated and installing the toolchain and dependencies using binary packages. In the current use case (modernizing C), emerging clang/gcc can be quite time-consuming; keeping in mind that we're gonna throw the container afterwards, I think that Gentoo's binary packages would brilliantly serve the purpose of setting up our environment fast.' |
Parsed HTML source of the new revision (new_html) | '<div class="mw-parser-output"><h1><span class="mw-headline" id="ebuild_Hacking_HOWTO">ebuild Hacking HOWTO</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=User:7upLime/notes/ebuild_hacking_howto&veaction=edit&section=1" class="mw-editsection-visualeditor" title="Edit section: ebuild Hacking HOWTO">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=User:7upLime/notes/ebuild_hacking_howto&action=edit&section=1" title="Edit section: ebuild Hacking HOWTO">edit source</a><span class="mw-editsection-bracket">]</span></span></h1>
<p>My personal workflow (always ready to accept suggesions) for hacking on Gentoo ebuilds.
</p><p>A Gentoo user can see the merging process split in its different phases and can intervene manually at each step.<br />
</p><p>One can work on a project at a certain release version, as downloaded and unpacked by portage. If you have a testing machine (preferably separated from your main machine, but not required) with all the tools installed, you can easily play with the sources, compile them and eventually start again from freshly unpacked sources if what you've done is messy; the objective of all of this is developing your own patch for that specific ebuild.
</p><p>Once you have a patch file for an ebuild, you add that to the patches folder in your personal overlay's ebuild (your own gentoo repo).
The patch can now remain in your personal overlay, or being submitted for review to the gentoo community, or if it makes sense, be submitted to the project's upstream.
</p><p>In the rest of this article, I'm going to outline my personal workflow.
</p>
<h2><span class="mw-headline" id="Picking_a_Bug_to_work_on">Picking a Bug to work on</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=User:7upLime/notes/ebuild_hacking_howto&veaction=edit&section=2" class="mw-editsection-visualeditor" title="Edit section: Picking a Bug to work on">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=User:7upLime/notes/ebuild_hacking_howto&action=edit&section=2" title="Edit section: Picking a Bug to work on">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<p>The first step would be of course to have a direction.
Sometimes help is well accepted to solve bugs that affect the generality of users.
<a href="/index.php?title=Https://bugs.gentoo.org&action=edit&redlink=1" class="new" title="Https://bugs.gentoo.org (page does not exist)">bugs.gentoo.org</a> could easily be the first place to check, to find something interesting to work on.
</p><p>Once something interesting has been found, like one of <a href="/index.php?title=Those&action=edit&redlink=1" class="new" title="Those (page does not exist)">those</a> issues related to the <a href="/index.php?title=Https://wiki.gentoo.org/wiki/Modern_C_porting&action=edit&redlink=1" class="new" title="Https://wiki.gentoo.org/wiki/Modern C porting (page does not exist)">Modernizing C</a> project, it is important to verify if the bug still persists at the version of the .ebuild marked in the bug.
</p>
<h3><span class="mw-headline" id="Setting_up_a_development_environment">Setting up a development environment</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=User:7upLime/notes/ebuild_hacking_howto&veaction=edit&section=3" class="mw-editsection-visualeditor" title="Edit section: Setting up a development environment">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=User:7upLime/notes/ebuild_hacking_howto&action=edit&section=3" title="Edit section: Setting up a development environment">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<p>I'd like to go with the container-based approach.
I would start with an official gentoo image on docker hub, to then have it updated and installing the toolchain and dependencies using binary packages. In the current use case (modernizing C), emerging clang/gcc can be quite time-consuming; keeping in mind that we're gonna throw the container afterwards, I think that Gentoo's binary packages would brilliantly serve the purpose of setting up our environment fast.
</p>
' |
Unix timestamp of change (timestamp) | 1706010516 |