mirror of
https://github.com/avinal/avinal.github.io.git
synced 2026-07-03 23:30:09 +05:30
added hugo website
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com> rh-pre-commit.version: 2.2.0 rh-pre-commit.check-secrets: ENABLED
This commit is contained in:
@@ -0,0 +1,5 @@
|
||||
+++
|
||||
title = '{{ replace .File.ContentBaseName "-" " " | title }}'
|
||||
date = {{ .Date }}
|
||||
draft = true
|
||||
+++
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,541 @@
|
||||
/*
|
||||
! tailwindcss v3.3.6 | MIT License | https://tailwindcss.com
|
||||
*/
|
||||
|
||||
/*
|
||||
1. Prevent padding and border from affecting element width. (https://github.com/mozdevs/cssremedy/issues/4)
|
||||
2. Allow adding a border to an element by just adding a border-width. (https://github.com/tailwindcss/tailwindcss/pull/116)
|
||||
*/
|
||||
|
||||
*,
|
||||
::before,
|
||||
::after {
|
||||
box-sizing: border-box;
|
||||
/* 1 */
|
||||
border-width: 0;
|
||||
/* 2 */
|
||||
border-style: solid;
|
||||
/* 2 */
|
||||
border-color: #e5e7eb;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
::before,
|
||||
::after {
|
||||
--tw-content: '';
|
||||
}
|
||||
|
||||
/*
|
||||
1. Use a consistent sensible line-height in all browsers.
|
||||
2. Prevent adjustments of font size after orientation changes in iOS.
|
||||
3. Use a more readable tab size.
|
||||
4. Use the user's configured `sans` font-family by default.
|
||||
5. Use the user's configured `sans` font-feature-settings by default.
|
||||
6. Use the user's configured `sans` font-variation-settings by default.
|
||||
*/
|
||||
|
||||
html {
|
||||
line-height: 1.5;
|
||||
/* 1 */
|
||||
-webkit-text-size-adjust: 100%;
|
||||
/* 2 */
|
||||
-moz-tab-size: 4;
|
||||
/* 3 */
|
||||
-o-tab-size: 4;
|
||||
tab-size: 4;
|
||||
/* 3 */
|
||||
font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
|
||||
/* 4 */
|
||||
font-feature-settings: normal;
|
||||
/* 5 */
|
||||
font-variation-settings: normal;
|
||||
/* 6 */
|
||||
}
|
||||
|
||||
/*
|
||||
1. Remove the margin in all browsers.
|
||||
2. Inherit line-height from `html` so users can set them as a class directly on the `html` element.
|
||||
*/
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
/* 1 */
|
||||
line-height: inherit;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
1. Add the correct height in Firefox.
|
||||
2. Correct the inheritance of border color in Firefox. (https://bugzilla.mozilla.org/show_bug.cgi?id=190655)
|
||||
3. Ensure horizontal rules are visible by default.
|
||||
*/
|
||||
|
||||
hr {
|
||||
height: 0;
|
||||
/* 1 */
|
||||
color: inherit;
|
||||
/* 2 */
|
||||
border-top-width: 1px;
|
||||
/* 3 */
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct text decoration in Chrome, Edge, and Safari.
|
||||
*/
|
||||
|
||||
abbr:where([title]) {
|
||||
-webkit-text-decoration: underline dotted;
|
||||
text-decoration: underline dotted;
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the default font size and weight for headings.
|
||||
*/
|
||||
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6 {
|
||||
font-size: inherit;
|
||||
font-weight: inherit;
|
||||
}
|
||||
|
||||
/*
|
||||
Reset links to optimize for opt-in styling instead of opt-out.
|
||||
*/
|
||||
|
||||
a {
|
||||
color: inherit;
|
||||
text-decoration: inherit;
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct font weight in Edge and Safari.
|
||||
*/
|
||||
|
||||
b,
|
||||
strong {
|
||||
font-weight: bolder;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Use the user's configured `mono` font-family by default.
|
||||
2. Use the user's configured `mono` font-feature-settings by default.
|
||||
3. Use the user's configured `mono` font-variation-settings by default.
|
||||
4. Correct the odd `em` font sizing in all browsers.
|
||||
*/
|
||||
|
||||
code,
|
||||
kbd,
|
||||
samp,
|
||||
pre {
|
||||
font-family: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace;
|
||||
/* 1 */
|
||||
font-feature-settings: normal;
|
||||
/* 2 */
|
||||
font-variation-settings: normal;
|
||||
/* 3 */
|
||||
font-size: 1em;
|
||||
/* 4 */
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct font size in all browsers.
|
||||
*/
|
||||
|
||||
small {
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
/*
|
||||
Prevent `sub` and `sup` elements from affecting the line height in all browsers.
|
||||
*/
|
||||
|
||||
sub,
|
||||
sup {
|
||||
font-size: 75%;
|
||||
line-height: 0;
|
||||
position: relative;
|
||||
vertical-align: baseline;
|
||||
}
|
||||
|
||||
sub {
|
||||
bottom: -0.25em;
|
||||
}
|
||||
|
||||
sup {
|
||||
top: -0.5em;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Remove text indentation from table contents in Chrome and Safari. (https://bugs.chromium.org/p/chromium/issues/detail?id=999088, https://bugs.webkit.org/show_bug.cgi?id=201297)
|
||||
2. Correct table border color inheritance in all Chrome and Safari. (https://bugs.chromium.org/p/chromium/issues/detail?id=935729, https://bugs.webkit.org/show_bug.cgi?id=195016)
|
||||
3. Remove gaps between table borders by default.
|
||||
*/
|
||||
|
||||
table {
|
||||
text-indent: 0;
|
||||
/* 1 */
|
||||
border-color: inherit;
|
||||
/* 2 */
|
||||
border-collapse: collapse;
|
||||
/* 3 */
|
||||
}
|
||||
|
||||
/*
|
||||
1. Change the font styles in all browsers.
|
||||
2. Remove the margin in Firefox and Safari.
|
||||
3. Remove default padding in all browsers.
|
||||
*/
|
||||
|
||||
button,
|
||||
input,
|
||||
optgroup,
|
||||
select,
|
||||
textarea {
|
||||
font-family: inherit;
|
||||
/* 1 */
|
||||
font-feature-settings: inherit;
|
||||
/* 1 */
|
||||
font-variation-settings: inherit;
|
||||
/* 1 */
|
||||
font-size: 100%;
|
||||
/* 1 */
|
||||
font-weight: inherit;
|
||||
/* 1 */
|
||||
line-height: inherit;
|
||||
/* 1 */
|
||||
color: inherit;
|
||||
/* 1 */
|
||||
margin: 0;
|
||||
/* 2 */
|
||||
padding: 0;
|
||||
/* 3 */
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the inheritance of text transform in Edge and Firefox.
|
||||
*/
|
||||
|
||||
button,
|
||||
select {
|
||||
text-transform: none;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Correct the inability to style clickable types in iOS and Safari.
|
||||
2. Remove default button styles.
|
||||
*/
|
||||
|
||||
button,
|
||||
[type='button'],
|
||||
[type='reset'],
|
||||
[type='submit'] {
|
||||
-webkit-appearance: button;
|
||||
/* 1 */
|
||||
background-color: transparent;
|
||||
/* 2 */
|
||||
background-image: none;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Use the modern Firefox focus style for all focusable elements.
|
||||
*/
|
||||
|
||||
:-moz-focusring {
|
||||
outline: auto;
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the additional `:invalid` styles in Firefox. (https://github.com/mozilla/gecko-dev/blob/2f9eacd9d3d995c937b4251a5557d95d494c9be1/layout/style/res/forms.css#L728-L737)
|
||||
*/
|
||||
|
||||
:-moz-ui-invalid {
|
||||
box-shadow: none;
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct vertical alignment in Chrome and Firefox.
|
||||
*/
|
||||
|
||||
progress {
|
||||
vertical-align: baseline;
|
||||
}
|
||||
|
||||
/*
|
||||
Correct the cursor style of increment and decrement buttons in Safari.
|
||||
*/
|
||||
|
||||
::-webkit-inner-spin-button,
|
||||
::-webkit-outer-spin-button {
|
||||
height: auto;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Correct the odd appearance in Chrome and Safari.
|
||||
2. Correct the outline style in Safari.
|
||||
*/
|
||||
|
||||
[type='search'] {
|
||||
-webkit-appearance: textfield;
|
||||
/* 1 */
|
||||
outline-offset: -2px;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the inner padding in Chrome and Safari on macOS.
|
||||
*/
|
||||
|
||||
::-webkit-search-decoration {
|
||||
-webkit-appearance: none;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Correct the inability to style clickable types in iOS and Safari.
|
||||
2. Change font properties to `inherit` in Safari.
|
||||
*/
|
||||
|
||||
::-webkit-file-upload-button {
|
||||
-webkit-appearance: button;
|
||||
/* 1 */
|
||||
font: inherit;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct display in Chrome and Safari.
|
||||
*/
|
||||
|
||||
summary {
|
||||
display: list-item;
|
||||
}
|
||||
|
||||
/*
|
||||
Removes the default spacing and border for appropriate elements.
|
||||
*/
|
||||
|
||||
blockquote,
|
||||
dl,
|
||||
dd,
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
hr,
|
||||
figure,
|
||||
p,
|
||||
pre {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
fieldset {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
legend {
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
ol,
|
||||
ul,
|
||||
menu {
|
||||
list-style: none;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
/*
|
||||
Reset default styling for dialogs.
|
||||
*/
|
||||
|
||||
dialog {
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
/*
|
||||
Prevent resizing textareas horizontally by default.
|
||||
*/
|
||||
|
||||
textarea {
|
||||
resize: vertical;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Reset the default placeholder opacity in Firefox. (https://github.com/tailwindlabs/tailwindcss/issues/3300)
|
||||
2. Set the default placeholder color to the user's configured gray 400 color.
|
||||
*/
|
||||
|
||||
input::-moz-placeholder, textarea::-moz-placeholder {
|
||||
opacity: 1;
|
||||
/* 1 */
|
||||
color: #9ca3af;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
input::placeholder,
|
||||
textarea::placeholder {
|
||||
opacity: 1;
|
||||
/* 1 */
|
||||
color: #9ca3af;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Set the default cursor for buttons.
|
||||
*/
|
||||
|
||||
button,
|
||||
[role="button"] {
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
/*
|
||||
Make sure disabled buttons don't get the pointer cursor.
|
||||
*/
|
||||
|
||||
:disabled {
|
||||
cursor: default;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Make replaced elements `display: block` by default. (https://github.com/mozdevs/cssremedy/issues/14)
|
||||
2. Add `vertical-align: middle` to align replaced elements more sensibly by default. (https://github.com/jensimmons/cssremedy/issues/14#issuecomment-634934210)
|
||||
This can trigger a poorly considered lint error in some tools but is included by design.
|
||||
*/
|
||||
|
||||
img,
|
||||
svg,
|
||||
video,
|
||||
canvas,
|
||||
audio,
|
||||
iframe,
|
||||
embed,
|
||||
object {
|
||||
display: block;
|
||||
/* 1 */
|
||||
vertical-align: middle;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Constrain images and videos to the parent width and preserve their intrinsic aspect ratio. (https://github.com/mozdevs/cssremedy/issues/14)
|
||||
*/
|
||||
|
||||
img,
|
||||
video {
|
||||
max-width: 100%;
|
||||
height: auto;
|
||||
}
|
||||
|
||||
/* Make elements with the HTML hidden attribute stay hidden by default */
|
||||
|
||||
[hidden] {
|
||||
display: none;
|
||||
}
|
||||
|
||||
*, ::before, ::after {
|
||||
--tw-border-spacing-x: 0;
|
||||
--tw-border-spacing-y: 0;
|
||||
--tw-translate-x: 0;
|
||||
--tw-translate-y: 0;
|
||||
--tw-rotate: 0;
|
||||
--tw-skew-x: 0;
|
||||
--tw-skew-y: 0;
|
||||
--tw-scale-x: 1;
|
||||
--tw-scale-y: 1;
|
||||
--tw-pan-x: ;
|
||||
--tw-pan-y: ;
|
||||
--tw-pinch-zoom: ;
|
||||
--tw-scroll-snap-strictness: proximity;
|
||||
--tw-gradient-from-position: ;
|
||||
--tw-gradient-via-position: ;
|
||||
--tw-gradient-to-position: ;
|
||||
--tw-ordinal: ;
|
||||
--tw-slashed-zero: ;
|
||||
--tw-numeric-figure: ;
|
||||
--tw-numeric-spacing: ;
|
||||
--tw-numeric-fraction: ;
|
||||
--tw-ring-inset: ;
|
||||
--tw-ring-offset-width: 0px;
|
||||
--tw-ring-offset-color: #fff;
|
||||
--tw-ring-color: rgb(59 130 246 / 0.5);
|
||||
--tw-ring-offset-shadow: 0 0 #0000;
|
||||
--tw-ring-shadow: 0 0 #0000;
|
||||
--tw-shadow: 0 0 #0000;
|
||||
--tw-shadow-colored: 0 0 #0000;
|
||||
--tw-blur: ;
|
||||
--tw-brightness: ;
|
||||
--tw-contrast: ;
|
||||
--tw-grayscale: ;
|
||||
--tw-hue-rotate: ;
|
||||
--tw-invert: ;
|
||||
--tw-saturate: ;
|
||||
--tw-sepia: ;
|
||||
--tw-drop-shadow: ;
|
||||
--tw-backdrop-blur: ;
|
||||
--tw-backdrop-brightness: ;
|
||||
--tw-backdrop-contrast: ;
|
||||
--tw-backdrop-grayscale: ;
|
||||
--tw-backdrop-hue-rotate: ;
|
||||
--tw-backdrop-invert: ;
|
||||
--tw-backdrop-opacity: ;
|
||||
--tw-backdrop-saturate: ;
|
||||
--tw-backdrop-sepia: ;
|
||||
}
|
||||
|
||||
::backdrop {
|
||||
--tw-border-spacing-x: 0;
|
||||
--tw-border-spacing-y: 0;
|
||||
--tw-translate-x: 0;
|
||||
--tw-translate-y: 0;
|
||||
--tw-rotate: 0;
|
||||
--tw-skew-x: 0;
|
||||
--tw-skew-y: 0;
|
||||
--tw-scale-x: 1;
|
||||
--tw-scale-y: 1;
|
||||
--tw-pan-x: ;
|
||||
--tw-pan-y: ;
|
||||
--tw-pinch-zoom: ;
|
||||
--tw-scroll-snap-strictness: proximity;
|
||||
--tw-gradient-from-position: ;
|
||||
--tw-gradient-via-position: ;
|
||||
--tw-gradient-to-position: ;
|
||||
--tw-ordinal: ;
|
||||
--tw-slashed-zero: ;
|
||||
--tw-numeric-figure: ;
|
||||
--tw-numeric-spacing: ;
|
||||
--tw-numeric-fraction: ;
|
||||
--tw-ring-inset: ;
|
||||
--tw-ring-offset-width: 0px;
|
||||
--tw-ring-offset-color: #fff;
|
||||
--tw-ring-color: rgb(59 130 246 / 0.5);
|
||||
--tw-ring-offset-shadow: 0 0 #0000;
|
||||
--tw-ring-shadow: 0 0 #0000;
|
||||
--tw-shadow: 0 0 #0000;
|
||||
--tw-shadow-colored: 0 0 #0000;
|
||||
--tw-blur: ;
|
||||
--tw-brightness: ;
|
||||
--tw-contrast: ;
|
||||
--tw-grayscale: ;
|
||||
--tw-hue-rotate: ;
|
||||
--tw-invert: ;
|
||||
--tw-saturate: ;
|
||||
--tw-sepia: ;
|
||||
--tw-drop-shadow: ;
|
||||
--tw-backdrop-blur: ;
|
||||
--tw-backdrop-brightness: ;
|
||||
--tw-backdrop-contrast: ;
|
||||
--tw-backdrop-grayscale: ;
|
||||
--tw-backdrop-hue-rotate: ;
|
||||
--tw-backdrop-invert: ;
|
||||
--tw-backdrop-opacity: ;
|
||||
--tw-backdrop-saturate: ;
|
||||
--tw-backdrop-sepia: ;
|
||||
}
|
||||
@@ -0,0 +1,21 @@
|
||||
window.remark_config = {
|
||||
host: "https://remark42.avinal.space",
|
||||
site_id: "remark",
|
||||
show_rss_subscription: false,
|
||||
theme: 'dark',
|
||||
no_footer: true,
|
||||
};
|
||||
|
||||
!(function (e, n) {
|
||||
for (var o = 0; o < e.length; o++) {
|
||||
var r = n.createElement("script"),
|
||||
c = ".js",
|
||||
d = n.head || n.body;
|
||||
"noModule" in r
|
||||
? ((r.type = "module"), (c = ".mjs"))
|
||||
: (r.async = !0),
|
||||
(r.defer = !0),
|
||||
(r.src = remark_config.host + "/web/" + e[o] + c),
|
||||
d.appendChild(r);
|
||||
}
|
||||
})(remark_config.components || ["embed"], document);
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
date: "2023-01-01T08:00:00-07:00"
|
||||
draft: false
|
||||
title: Home
|
||||
---
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
date: "2023-01-01T08:30:00-07:00"
|
||||
draft: false
|
||||
title: Posts
|
||||
---
|
||||
|
||||
All the posts.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
category: article
|
||||
date: 2012-02-27T22:47:00
|
||||
description: The Big Red Ants
|
||||
image: /images/ants.webp
|
||||
tags:
|
||||
- ants
|
||||
- sav
|
||||
title: The Big Red Ants
|
||||
---
|
||||
|
||||
In a bird's eye view if we see around us, ants are the common and
|
||||
tiniest living entitiy seen by naked eye. One of them are the big red
|
||||
ants, in my view they are unique from others in two ways, first they
|
||||
live on trees and second their anteenas are too long and bent in middle,
|
||||
seems like their fore legs. Their mandible (mouth) seems like eagle's
|
||||
beak.
|
||||
|
||||
As I observed them making and reparing their nests, I concluded that
|
||||
they are very laborious and intellectual. They create their nests by
|
||||
binding two or more leaves (maybe up to 500) together. They stich the
|
||||
leaves using a stinky white substance either excreted by themselves or
|
||||
from trees. This substance is like web of spider. At first builder ants
|
||||
creates an array at the blade of two leaves. Then they make ant-cranes
|
||||
or ant-chain like chain of monomer to form a polymer. They catch the
|
||||
leaves and pull each other to stich. After some time, the parliament of
|
||||
leaves transforms into a leaf-sac called their nest. They also weave
|
||||
translucent cloth like structure to cover remainings of leaf. A nest
|
||||
hangs by a branch of the trees.
|
||||
|
||||
A nest is skillfully divided into living rooms, barracks, storehouse,
|
||||
egg room and queen's room. The eggroom, lies at the center of nest to
|
||||
protect from outer attack until last time. Besides that, lies queen's
|
||||
room. Living rooms are sequenncly joined with eggroom. There are
|
||||
different rooms for workers, food searchers etc. The partition of the
|
||||
room resembles atom's electron shell, one upon another. At last barracks
|
||||
are the outermost rooms, just like outermost orbit of electron. The
|
||||
defence system is strongest at the nest's opening. A nest may size as
|
||||
2-3 footballs and have 50 to 10000 ants. There may be more openings.
|
||||
|
||||
Now about their attacking and protecting skills. A solider is unique
|
||||
from other ants. It is equipped with many attacking and defending
|
||||
skills. Normally they do not attack. They are social insects. If someone
|
||||
attacks, all other ants go inside, and soldiers come out. They spread
|
||||
allover the nest. They are very sensetive and have sharp vision. If any
|
||||
one of them see their enemy the stand on their hind legs, swinging,
|
||||
their forelegs and anteens in their air as scolding someone. Their spit
|
||||
contains formic acid, present at the end of the abdomen below the
|
||||
rectum. If their nest is broken and eggs fall on ground then the ants
|
||||
make a dome, like the dome of Taj mahal to save the eggs till last their
|
||||
breadth. This shows their caring skills.
|
||||
|
||||
The most amazing is their discipline. They can easily beat a human in
|
||||
race of discipline. Humans must learn from it. When two ants meet, they
|
||||
touch their anteena to communicate. When they walk in a queue, they seem
|
||||
like twinkling dots and dashes. I want to conclude that **All tiny
|
||||
things are not really tiny. It may be as a space having infinite
|
||||
mysteries one has to explore it.**
|
||||
|
||||
Photo Attribution : Photo by Michael Willinger from Pexels:
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
category: article
|
||||
date: 2019-09-21T15:47:00
|
||||
description: प्रकृति की सुंदरता और कलाकारी हिमालय की कण-कण में झलकती है। प्रकृति ने
|
||||
प्रेम को भी हिमालय के जितना ही विशाल और अलौकिक बनाया है । ये एक अलग चर्चा का विषय
|
||||
है कि हिमालय पहले आया या प्रेम। मैं तो प्रेम के पक्ष में हूँ । वो हर अणु-परमाणु
|
||||
जिन्होंने इतने बड़ा पहाड़ खड़ा किया वो सब आपस में प्रेम से बंधे हुए हैं।
|
||||
image: /images/fedora-night.webp
|
||||
tags:
|
||||
- love
|
||||
- article
|
||||
- hindi
|
||||
title: प्रेम रतन धन पायो
|
||||
---
|
||||
|
||||
टूटता तारा देखना एक अलौकिक अनुभव है। हिमाद्रि के छत से आसमान कुछ ज्यादा ही करीब प्रतीत होता है । लोग सदियों से हिमालय को पूजते आयें हैं ।
|
||||
दादा-दादी कहा करते थे ये जिंदा पहाड़ हैं । सारी बातें सुनते हैं लोगों की । उनके दुख दर्द दूर करते हैं, ये देवता हैं । आजकल जब रोज़ क्लास
|
||||
आते जाते दूर पहाड़ों की चोटियाँ देखता हूँ तो उनकी विशालता का अनुभव होता हैं । एक पल को अगर ये मान लिया जाए की हमारी सारी धार्मिक किताबें
|
||||
वो कहानियाँ हैं जो पथिक लेखकों के द्वारा लिखी गयी हैं तो सारी बातें साफ हो जाती है कि क्यूँ देवी-देवताओं ने हिमालय को अपनाया है। टूटता
|
||||
तारा देखना अलौकिक है पर हिमालय की श्रेणियों से टूटता तारा देखना दैविक है । और वो कहते हैं न जिसमें न कोई तर्क हो न ही हाथों की सफाई वो
|
||||
दैविक है। टूटते तारो के बारे में लोगों के बहुत सारे विश्वास हैं । कभी विभीषिका का पूर्वाभास माने जाने वाले इन टूटते तारे आज इच्छा पूरक के
|
||||
प्रतीक हैं । कुछ लोगों का ये भी मानना है कि टूटते तारे दिवंगत लोगों का संकेत हैं । हिमालय की कन्दराओं में न जाने कितने ही ऋषि-मुनियों ने
|
||||
तप करते हुए अपना जीवन अर्पित कर दिया । इसलिए हिमालय की पहाड़ों से टूटता तारा देखना दैविक हैं क्योंकि शायद वो तारे उन ऋषि-मुनियों की पवित्र
|
||||
आत्माओं का संकेत हैं ।
|
||||
|
||||
प्रकृति की सुंदरता और कलाकारी हिमालय की कण-कण में झलकती है। प्रकृति ने प्रेम को भी हिमालय के जितना ही विशाल और अलौकिक बनाया है । ये एक
|
||||
अलग चर्चा का विषय है कि हिमालय पहले आया या प्रेम। मैं तो प्रेम के पक्ष में हूँ । वो हर अणु-परमाणु जिन्होंने इतने बड़ा पहाड़ खड़ा किया वो सब
|
||||
आपस में प्रेम से बंधे हुए हैं। ये पृथ्वी, सूर्य, चंद्रमा, आकाश-गंगा इत्यादि सब प्रेम से बंधे हुए हैं । और हिमाद्रि के छत पर मैं इसी प्रेम
|
||||
के आगोश में आकर भावशून्य होकर तारों को निहार रहा था । तभी मानो सदियों की मन्नत पूरी हुई और मुझे एक टूटता तारा दिखा । आप मेरी स्थिति की
|
||||
जटिलता का अनुभव इस प्रकार से लगा सकते हैं कि लोग टूटते तारे से मन्नत मांगते हैं और मैं टूटता तारा ही मन्नत में मांग रहा था । इससे पहले की
|
||||
मैं पिछली जटिलता से बाहर आता की दूसरी जटिलता सामने आ पड़ी की तारा तो दिख गया पर मैं माँगूँ क्या ? और अगर आप सोच रहे की भाई पैसे मांग लो
|
||||
शोहरत , नाम , शक्ति और पता नहीं क्या-क्या ? मांग तो लेता पर अगर आप मेरी जगह इसी स्थिति में होते तो शायद आपको भी ये सब याद न आता । तो मैं
|
||||
एक पल को ये आकलन करने लगा की क्या कुछ ऐसा है जिसकी मुझे बहुत जरूरत है पर मेरे पास हो नहीं । और आपको पता है की गहरी सोच में जाने पर अक्सर
|
||||
क्या होता है। अब वो लोग जो ये सोच रहे की भाईसाब आप हर कहानी(सच्ची घटना का विवरण वाली कहानी 😊) में सो क्यूँ जाते हैं। सच बताऊँ तो इसका
|
||||
कोई सटीक जबाव नहीं है मेरे पास, पर अध्यात्म ये कहता है की जब आप सो रहे होते हैं तो आपका मन चेतना के कई स्थिति से गुजरता है। जब आप परम
|
||||
चैतन्य अवस्था में होते हैं तो रहस्य, प्रतिभज्ञान इत्यादि के रास्ते खुल जाते हैं। और विज्ञान ये भी कहता है कि निद्रा के माध्यम से इस
|
||||
अवस्था में जाना उतना ही अनिश्चित है जितना किसी बाला का मेरे लिए प्रेम-प्रस्ताव । सरल शब्दों में – मैं कुछ समय के लिए सो गया।
|
||||
|
||||
आज से ठीक 2 महीने पहले अगर ये मुझसे कोई पूछता की क्या चाहिए तुम्हें तो शायद मेरे पास जबाव होता। दोस्त तो बहुत हैं पर जब कोई ऐसा हो जो
|
||||
आपके अधूरे वाक्य पूरे कर सके, कोई ऐसा जो आपकी भावनाओं को आपकी तरह समझ सके, कोई ऐसा जो आपको आपके असल रूप में पसंद करता हो । आपको लग रहा
|
||||
होगा की मैं एक प्रेमिका का विवरण दे रहा हूँ, पर नहीं या शायद हाँ , मैं समझता हूँ की अधिकतर लोग प्रेमिका शब्द का प्रयोग अनुचित ढंग से करते
|
||||
हैं। जहां प्रेम है वहाँ प्रेमी-प्रेमिका होंगे फिर वो भाई-बहन का रिश्ता हो या माँ-बेटे का । एक पल को सोचो तो ऊपर के विवरण के लिए कोई सबसे
|
||||
सटीक उत्तर है तो वो है माँ। जब आप उन माँ-बाप जिन्होंने आपको जन्म दिया, आपका पालन-पोषण किया , आपको इस लायक बनाया कि आप इस वक़्त ये लेख पढ़
|
||||
पा रहे हैं , उनको अपनी प्रेमी-प्रेमिका नहीं कह सकते तो शायद किसी और लड़के-लड़की को कहने का आपको कोई हक़ नहीं है। पर ये बात निजी समझदारी की
|
||||
है और मैं माँ-बाप के बारे में बिलकुल भी बात नहीं कर रहा, इन 2-4 पन्ने में उनको चित्रित कर पाना दुष्कर है। अगर माँ है तो ये अलग व्यक्ति
|
||||
क्यूँ ? लोग कहते हैं क्योंकि भगवान हर जगह नहीं हो सकते इसलिए उन्होंने माँ बनाई। पर मैं कहता हूँ माँ भी हर जगह नहीं हो सकती इसलिए भगवान ने
|
||||
दोस्त बनाए और विशेष लोग भी बनाए। आज तक बहुत सारे लोग आए-गए , कई बार लगा की शायद वो विशेष व्यक्ति मिलने ही वाला है पर वो भ्रम था शायद ये
|
||||
भी हो। मैं ये नहीं कह सकता की मेरी खोज पूर्ण हो गयी पर हाँ एक पड़ाव तो जरूर आ गया है। उस पहली मुलाक़ात में एक पल को ऐसा लगा मानो किसी
|
||||
चमत्कारी दर्जी ने कपड़े की जगह एक पूरा आदमी सिल कर दिया हो। सब कुछ एकदम नाप के अनुरूप। शायद कई सालों के बाद मैं खुशियों का बवंडर अपने अंदर
|
||||
महसूस कर रहा था। आप पूछेंगे इसमें प्रेम कहाँ है? हिमालय जितना विशाल है उतना ही गहरा भी है , यहाँ भी प्रेम गहराई में है । प्रेम का होना
|
||||
जरूरी है दिखावा तो हर कोई कर लेता है। कबीर ने अपने एक दोहे में कहा है :
|
||||
|
||||
**बूंद समानी समूंद में , जानत है सब कोई; समूंद समाना बूंद में , बूझे बिरला कोई।**
|
||||
|
||||
मैं इस दोहे को प्रेम के संदर्भ में व्याख्या करना चाहूँगा। लोग बूंद हैं और प्रेम समुद्र, लोगों को प्रेम में पड़ते सबने देखा है या सुना है,
|
||||
पर जो प्रेम लोगों के अंदर व्याप्त है ये हर कोई नहीं समझता। मैं उस विशेष व्यक्ति का कृतज्ञ हूँ जिसने ने मुझे इस दोहे के मूल भाव का अहसास
|
||||
करवाया।
|
||||
|
||||
कभी-कभी डर लगता है, खोने का उसे। आजकल दुनिया में सब अनिश्चित है। कब-क्या हो जाए ये कोई नहीं बता सकता। पहले सिर्फ पृथ्वी थी फिर लोग हुए और
|
||||
तब से पृथ्वी अस्थमा की मरीज है। किसी प्रसिद्ध कवि ने लिखा है :
|
||||
|
||||
**आज आदमी में विष इतना भर गया है, की विषधरों का वंश उनसे डर गया है,**
|
||||
**कल को कहते सुनोगे , आदमी काटा और साँप मर गया है।**
|
||||
|
||||
ठंडी-ठंडी हवाओं ने मेरी सारी नींद उड़ा दी। प्रकृति शायद मुझे खुश करके मारना चाहती थी। आसमान ने एक बड़े काले पर्दे का रूप ले लिया था और उस
|
||||
पर्दे पर दसियो उजले साँप रेंगते नज़र आ रहे थे। मानो दस सालो के टूटते तारे एक साथ दिख रहे हों और आसमान कह रहा हो – जो चाहिए, जितना चाहिए
|
||||
माँग लो। और मैंने सच में माँग लिए , लगभग सब कुछ । और उसको हमेशा पास रखने की दुआ तो नहीं माँग सका , पर वो जहां रहे, खुश रहे, सलामत रहे।
|
||||
@@ -0,0 +1,406 @@
|
||||
---
|
||||
title: Configure Logitech MX Master 3S using LogiOps
|
||||
date: 2023-09-25T20:47:00
|
||||
category: blogs
|
||||
tags: [fedora, mouse, "logid", "logitech", "logiops", "mx-master-3s"]
|
||||
image: "/images/mouse-building.webp"
|
||||
description: "I brought Logitech MX Master 3S mouse and it is a great mouse. It
|
||||
has a lot of features and I am still exploring them. One of the features is to
|
||||
configure the mouse using LogiOps. LogiOps is a command line tool to configure
|
||||
Logitech devices on Linux distos."
|
||||
---
|
||||
|
||||
I brought Logitech MX Master 3S mouse, and it is a great mouse. It has a lot of
|
||||
features, and I am still exploring them. One of the features is to configure the
|
||||
mouse using LogiOps. LogiOps is a command line tool to configure Logitech
|
||||
devices on Linux distros, since Logitech provides official tools to configure the
|
||||
mouse on Windows and macOS.
|
||||
|
||||
## Logitech MX Master 3S
|
||||
|
||||
Although I use keyboard shortcuts for most of my work, I still use the mouse a
|
||||
lot. It is usually very helpful to have a good mouse, especially when you have
|
||||
to scroll thousands of lines of code and documentation. This mouse features a
|
||||
superfast scroll wheel that can scroll thousands of lines in a second. In total
|
||||
there are 7 buttons on the mouse. The mouse can be connected to the computer via
|
||||
Bluetooth or a USB receiver. It can also be connected to multiple devices at the
|
||||
same time and can be switched between them using a button on the bottom of the
|
||||
mouse. The mouse can be charged using a USB-C cable, and it can be used while
|
||||
charging as well. You can see a 3D model of the mouse below. You can rotate the model using your
|
||||
mouse or touchpad.
|
||||
|
||||
<iframe class="aspect-video w-full" title="Logitech MX Master 3 Mouse Black" frameborder="0" allowfullscreen
|
||||
mozallowfullscreen="true" webkitallowfullscreen="true" allow="autoplay; fullscreen; xr-spatial-tracking"
|
||||
xr-spatial-tracking execution-while-out-of-viewport execution-while-not-rendered web-share
|
||||
src="https://sketchfab.com/models/c15eda7cd7874423a8c31d55193b9ff2/embed?ui_theme=dark&dnt=1"> </iframe>
|
||||
|
||||
The best part about this mouse is that it is very comfortable to use and highly
|
||||
customizable. You can customize most of the buttons and even extend the functionality
|
||||
by adding gestures. You can also customize the scroll wheel and the scroll
|
||||
direction as well as the DPI and the pointer speed. All this can be done using
|
||||
LogiOps.
|
||||
|
||||
## Installing LogiOps
|
||||
|
||||
It is an open source tool with code available on [GitHub](https://github.com/PixlOne/logiops).
|
||||
This blog post will show you how to install and configure LogiOps on Fedora. The
|
||||
steps should be similar for other Linux distros and other Logitech mice as well.
|
||||
You can directly install using `dnf` but for latest version, you can build from
|
||||
source.
|
||||
|
||||
- Install the dependencies.
|
||||
|
||||
```bash
|
||||
sudo dnf install cmake libevdev-devel systemd-devel libconfig-devel gcc-c++ glib2-devel
|
||||
```
|
||||
|
||||
- Clone the repository.
|
||||
|
||||
```bash
|
||||
git clone https://github.com/PixlOne/logiops.git
|
||||
```
|
||||
|
||||
- Build and install.
|
||||
|
||||
```bash
|
||||
cd logiops
|
||||
mkdir build
|
||||
cd build
|
||||
cmake -DCMAKE_BUILD_TYPE=Release ..
|
||||
make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
## Configuring LogiOps
|
||||
|
||||
In this blog post I will show you what buttons are available and how you can configure
|
||||
actions (*keypress* or *gestures*) on them. Let us take a look at all the available buttons.
|
||||
|
||||
|
||||
|
||||
You can also get a table of available buttons, their CID and available features
|
||||
by running logid in debug mode.
|
||||
|
||||
```bash
|
||||
sudo logid -d
|
||||
```
|
||||
|
||||
You can get output like this:
|
||||
|
||||
```bash
|
||||
[INFO] Device found: MX Master 3S on /dev/hidraw4:255
|
||||
[DEBUG] /dev/hidraw4:255 remappable buttons:
|
||||
[DEBUG] CID | reprog? | fn key? | mouse key? | gesture support?
|
||||
[DEBUG] 0x50 | | | YES |
|
||||
[DEBUG] 0x51 | | | YES |
|
||||
[DEBUG] 0x52 | YES | | YES | YES
|
||||
[DEBUG] 0x53 | YES | | YES | YES
|
||||
[DEBUG] 0x56 | YES | | YES | YES
|
||||
[DEBUG] 0xc3 | YES | | YES | YES
|
||||
[DEBUG] 0xc4 | YES | | YES | YES
|
||||
[DEBUG] 0xd7 | YES | | | YES
|
||||
[DEBUG] Thumb wheel detected (0x2150), capabilities:
|
||||
[DEBUG] timestamp | touch | proximity | single tap
|
||||
[DEBUG] YES | YES | YES | YES
|
||||
[DEBUG] Thumb wheel resolution: native (18), diverted (120)
|
||||
```
|
||||
|
||||
You can see thumb wheel has some cool features like touch, proximity and single
|
||||
tap. Furthermore, you can configure these features in the configuration file. You can also
|
||||
configure the thumb wheel resolution.
|
||||
|
||||
### Create a configuration file
|
||||
|
||||
LogiOps uses a configuration file to configure the mouse. By default, the
|
||||
configuration file is located at `/etc/logid.cfg`. If you cannot
|
||||
find the file, you can create one. You can copy the default configuration file
|
||||
and edit it. You can find the default configuration file
|
||||
[here](https://github.com/PixlOne/logiops/blob/main/logid.example.cfg). You can
|
||||
read the documentation for the configuration file in [this wiki](https://github.com/PixlOne/logiops/wiki/Configuration).
|
||||
|
||||
```bash
|
||||
sudo touch /etc/logid.cfg
|
||||
```
|
||||
|
||||
You can also pass a custom path for the configuration file using `-c` flag. But
|
||||
it never worked for me, so I am going to skip this part.
|
||||
|
||||
### Understanding the configuration options
|
||||
|
||||
You can obviously read the documentation for the configuration file, but I will
|
||||
focus on easy understanding of the options that will be more than enough for most
|
||||
users. I will be building the configuration file step by step and finally show
|
||||
you the complete configuration file.
|
||||
|
||||
- Add a device and define its name
|
||||
|
||||
```cpp
|
||||
devices: (
|
||||
{
|
||||
name: "MX Master 3S";
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
- Configure smartshift
|
||||
|
||||
```cpp
|
||||
smartshift:
|
||||
{
|
||||
on: true;
|
||||
threshold: 30;
|
||||
torque: 50;
|
||||
}
|
||||
```
|
||||
|
||||
- Configure hires scrolling
|
||||
|
||||
```cpp
|
||||
hiresscroll:
|
||||
{
|
||||
hires: true;
|
||||
invert: false;
|
||||
target: false;
|
||||
}
|
||||
```
|
||||
|
||||
- Configure dpi
|
||||
|
||||
```cpp
|
||||
dpi: 2000;
|
||||
```
|
||||
|
||||
Next we will see how to configure the buttons.
|
||||
|
||||
#### Buttons
|
||||
|
||||
Every button has a CID. You can see the CID of the buttons in the debug output
|
||||
as well as in the image above. Every remappable button has some actions that can
|
||||
be configured. You can configure a keypress or a gesture or a combination of
|
||||
both.
|
||||
|
||||
There can be two situations when you configure a button. Either you want to
|
||||
configure the button for a specific keypress, or you want to configure the button
|
||||
for a specific gesture. You can also configure the button for both keypress and
|
||||
gesture. In this case, the keypress will be triggered when you press the button
|
||||
and the gesture will be triggered when you press the button and move the mouse
|
||||
in a specific direction. The buttons can also be configured to toggle specific
|
||||
fetcures of the mouse like smartshift, hires scrolling, etc.
|
||||
|
||||
First create a button section for the button you want to configure.
|
||||
|
||||
```cpp
|
||||
buttons: (
|
||||
{
|
||||
<first-button>
|
||||
},
|
||||
{
|
||||
<second-button>
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
- Configure only a keypress, let's configure the wheel button to take screenshot
|
||||
|
||||
```cpp
|
||||
{
|
||||
cid: 0x52;
|
||||
action =
|
||||
{
|
||||
type: "keypress";
|
||||
keys: ["KEY_PRINT"]
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
- Configure the top button to toggle SmartShift
|
||||
|
||||
```cpp
|
||||
{
|
||||
cid: 0xc4;
|
||||
action =
|
||||
{
|
||||
type: "ToggleSmartShift";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- configure the gesture button for the following (sway based gestures)
|
||||
- keypress: Opens Terminal
|
||||
- Up gesture: Snaps current window to top
|
||||
- Down gesture: Snaps current window to bottom
|
||||
- Left gesture: Snaps current window to left
|
||||
- Right gesture: Snaps current window to right
|
||||
|
||||
```cpp
|
||||
{
|
||||
cid: 0xc3;
|
||||
action =
|
||||
{
|
||||
type: "Gestures";
|
||||
gestures: (
|
||||
{
|
||||
direction: "Up";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_UP"];
|
||||
};
|
||||
},
|
||||
{
|
||||
direction: "Down";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_DOWN"];
|
||||
};
|
||||
},
|
||||
{
|
||||
direction: "Left";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_LEFT"];
|
||||
};
|
||||
},
|
||||
{
|
||||
direction: "Right";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys = ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_RIGHT"];
|
||||
}
|
||||
},
|
||||
{
|
||||
direction: "None"
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_ENTER"];
|
||||
}
|
||||
}
|
||||
);
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
The keypress while using with gestures is defined as direction **None**. These are
|
||||
just some examples, you can go through the documentation to see all the available
|
||||
options.
|
||||
|
||||
### Complete configuration file
|
||||
|
||||
Here is the complete configuration file that I use.
|
||||
|
||||
```cpp
|
||||
devices: (
|
||||
{
|
||||
name: "MX Master 3S";
|
||||
smartshift:
|
||||
{
|
||||
on: true;
|
||||
threshold: 30;
|
||||
torque: 50;
|
||||
};
|
||||
hiresscroll:
|
||||
{
|
||||
hires: true;
|
||||
invert: false;
|
||||
target: false;
|
||||
};
|
||||
dpi: 2000;
|
||||
|
||||
buttons: (
|
||||
{
|
||||
cid: 0xc3;
|
||||
action =
|
||||
{
|
||||
type: "Gestures";
|
||||
gestures: (
|
||||
{
|
||||
direction: "Up";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_UP"];
|
||||
};
|
||||
},
|
||||
{
|
||||
direction: "Down";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_DOWN"];
|
||||
};
|
||||
},
|
||||
{
|
||||
direction: "Left";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_LEFT"];
|
||||
};
|
||||
},
|
||||
{
|
||||
direction: "Right";
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys = ["KEY_LEFTMETA", "KEY_LEFTSHIFT", "KEY_RIGHT"];
|
||||
}
|
||||
},
|
||||
{
|
||||
direction: "None"
|
||||
mode: "OnRelease";
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_LEFTMETA", "KEY_ENTER"];
|
||||
}
|
||||
}
|
||||
);
|
||||
};
|
||||
},
|
||||
{
|
||||
cid: 0x52;
|
||||
action =
|
||||
{
|
||||
type: "Keypress";
|
||||
keys: ["KEY_RIGHTCTRL", "KEY_PRINT"]
|
||||
};
|
||||
},
|
||||
{
|
||||
cid: 0xc4;
|
||||
action =
|
||||
{
|
||||
type: "ToggleSmartshift";
|
||||
};
|
||||
}
|
||||
);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
## Post Configuration
|
||||
|
||||
Once configured you will need to restart the logid service.
|
||||
|
||||
```bash
|
||||
sudo systemctl restart logid
|
||||
```
|
||||
|
||||
Voila! You have successfully configured your Logitech mouse.
|
||||
|
||||
## References
|
||||
|
||||
- [LogiOps](https://github.com/PixlOne/logiops)
|
||||
- [My Configurations](https://gist.github.com/avinal/2acfc0ac2952f4354dd3b4b78b8ccb2b)
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: Installing Fedora with automatic and custom partioning
|
||||
date: 2023-01-19 23:02
|
||||
category: blog
|
||||
tags: [fedora, partioning]
|
||||
image: ""
|
||||
draft: true
|
||||
---
|
||||
|
||||
Fedora is one of the most popular Linux distribution for daily uses as well as
|
||||
development purpose. I have been a Linux user since 2019 and switched through
|
||||
multiple distros since then. For a long time I was stuck with Ubuntu and now
|
||||
finally Fedora. Fedora is an amazing distribution. You get to enjoy the latest
|
||||
of almost everything. But this all starts with installing Fedora on your system.
|
||||
Although Fedora is one of the most easy-to-install distribution out there, a lot
|
||||
of people struggle to install it the right way. There is a lot of tutorials and
|
||||
blogs as well, but I couldn't find one that answers all my questions and still is
|
||||
easy to understand and follow along. So I decided to write one.
|
||||
|
||||
## What is the best for me?
|
||||
|
||||
## Complete automatic installation
|
||||
|
||||
## Semi-automatic custom partitioning
|
||||
|
||||
## Advanced custom partitioning
|
||||
|
||||
### Partition Scheme
|
||||
|
||||
| Mount Points | Filesystem | Size (minimum) | Remarks |
|
||||
| --- | --- | --- | --- |
|
||||
| `/boot/efi` | EFI | | |
|
||||
| `/boot` | ext4 | | |
|
||||
| `/` | ext4 | | |
|
||||
| `/home` | btrfs | | |
|
||||
|
||||
## References
|
||||
@@ -0,0 +1,301 @@
|
||||
---
|
||||
category: blogs
|
||||
date: 2023-07-19T18:08:00
|
||||
description: In the last post, I described how to install Tekton Results on a Kubernetes
|
||||
cluster. In this post, we will see how to use Tekton Results to store the results
|
||||
of a PipelineRun and how to retrive them later.
|
||||
image: /images/tekton-results-retrieve.webp
|
||||
tags:
|
||||
- tekton
|
||||
- kubernetes
|
||||
- redhat
|
||||
- openshift
|
||||
- results
|
||||
title: Tekton Results - Storing and Retrieving Results
|
||||
---
|
||||
|
||||
In the [last post](/posts/blogs/hey-tekton-results/), I described how to install
|
||||
Tekton Results on a Kubernetes cluster. In this post, we will see how to use Tekton
|
||||
Results to store the results of a PipelineRun and how to retrive them later.
|
||||
|
||||
## Creating a PipelineRun/TaskRun
|
||||
|
||||
Let us create a simple PipelineRun to see how Tekton Results works. Here is a simple
|
||||
PipelineRun that I created for this demo.
|
||||
|
||||
- Create a PipelineRun YAML file.
|
||||
|
||||
```sh
|
||||
cat <<EOF > demo-pipeline-run.yaml
|
||||
apiVersion: tekton.dev/v1beta1
|
||||
kind: PipelineRun
|
||||
metadata:
|
||||
name: demo-pipeline-run
|
||||
spec:
|
||||
pipelineRef:
|
||||
name: demo-pipeline
|
||||
tasks:
|
||||
- name: demo-task
|
||||
taskSpec:
|
||||
steps:
|
||||
- name: demo-step
|
||||
image: alpine
|
||||
script: |
|
||||
echo "Hello World"
|
||||
EOF
|
||||
```
|
||||
|
||||
- Create the PipelineRun.
|
||||
|
||||
```bash
|
||||
kubectl apply --filename demo-pipeline-run.yaml
|
||||
```
|
||||
|
||||
## Querying the Results API
|
||||
|
||||
There are three ways to query the Results API. The simplest way is to use
|
||||
`tkn-results` CLI. You can also use `curl` or any other HTTP client as well as
|
||||
a gRPC client. I will go through all three methods. Before we start, we have to
|
||||
create a ServiceAccount and a ClusterRoleBinding to access the API.
|
||||
|
||||
- Create a ServiceAccount for quering the API.
|
||||
|
||||
```bash
|
||||
kubectl create sa tekton-results-query -n tekton-pipelines
|
||||
```
|
||||
|
||||
- Grant readonly permissions to the ServiceAccount
|
||||
|
||||
```bash
|
||||
kubectl create clusterrolebinding tekton-results-query \
|
||||
--clusterrole=tekton-results-readonly
|
||||
--serviceaccount=tekton-pipelines:tekton-results-query
|
||||
```
|
||||
|
||||
- Create an access token
|
||||
|
||||
```bash
|
||||
export ACCESS_TOKEN=$(kubectl create token tekton-results-query -n tekton-pipelines)
|
||||
```
|
||||
|
||||
- Expose the results API server, this will block so run in a separate shell.
|
||||
|
||||
```bash
|
||||
kubectl port-forward --namespace tekton-pipelines \
|
||||
service/tekton-results-api-service 8080:8080
|
||||
```
|
||||
|
||||
### Using `tkn-results` CLI
|
||||
|
||||
We are not releasing the CLI yet, but you can install it using Go. You will need
|
||||
[Go](https://golang.org/doc/install) installed on your machine.
|
||||
|
||||
- Install `tkn-results`
|
||||
|
||||
```bash
|
||||
GOBIN=${TKN_PLUGINS_DIR:-"${HOME}/.config/tkn/plugins"} \
|
||||
go install github.com/tektoncd/results/tools/tkn-results@latest
|
||||
```
|
||||
|
||||
- Query the API, pass `--insecure` flag if you are using a self-signed certificate. In place of `default` you can pass the namespace name. `-` means all namespaces.
|
||||
|
||||
```bash
|
||||
tkn-results list --insecure \
|
||||
--addr http://localhost:8080
|
||||
--authtoken $ACCESS_TOKEN
|
||||
default
|
||||
```
|
||||
|
||||
You will get a response like below.
|
||||
|
||||
```bash
|
||||
Name Start Update
|
||||
default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be 2023-06-13 12:04:49 +0530 IST 2023-06-13 12:09:07 +0530 IST
|
||||
```
|
||||
|
||||
- Similarly you can query Records for a particular PipelineRun or TaskRun Result.
|
||||
|
||||
```bash
|
||||
tkn-results records list --insecure \
|
||||
--addr http://localhost:8080
|
||||
--authtoken $ACCESS_TOKEN
|
||||
default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be
|
||||
```
|
||||
|
||||
You will get a response like below. Notice that there are two records, one for the PipelineRun and one for the TaskRun.
|
||||
|
||||
```bash
|
||||
Name Type Start Update
|
||||
default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be/records/dcb7926e-42e8-4338-ab7d-0b67e02389be tekton.dev/v1beta1.PipelineRun 2023-06-13 12:04:51 +0530 IST 2023-06-13 12:19:09 +0530 IST
|
||||
default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be/records/64a0ab6e-9b90-4e5e-a072-e44d8ff27467 tekton.dev/v1beta1.TaskRun 2023-06-13 12:06:14 +0530 IST 2023-06-13 12:07:52 +0530 IST
|
||||
```
|
||||
|
||||
- Finally you can get a single record too.
|
||||
|
||||
```bash
|
||||
tkn-results records list --insecure \
|
||||
--addr http://localhost:8080
|
||||
--authtoken $ACCESS_TOKEN
|
||||
default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be/records/dcb7926e-42e8-4338-ab7d-0b67e02389be
|
||||
```
|
||||
|
||||
You will get a response like below.
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be/records/dcb7926e-42e8-4338-ab7d-0b67e02389be",
|
||||
"id": "50b13d54-2eb0-4a45-8399-853f2d4ba028",
|
||||
"uid": "50b13d54-2eb0-4a45-8399-853f2d4ba028",
|
||||
"data": {
|
||||
"type": "tekton.dev/v1beta1.PipelineRun",
|
||||
"value": "eyJraW5kIjogIlBpcGVsaW5lUn<base64-encode-data-truncated-for-brevity>"
|
||||
},
|
||||
"etag": "50b13d54-2eb0-4a45-8399-853f2d4ba028-1686638949162394019",
|
||||
"createdTime": "2023-06-13T06:34:51.320028Z",
|
||||
"createTime": "2023-06-13T06:34:51.320028Z",
|
||||
"updatedTime": "2023-06-13T06:49:09.162394Z",
|
||||
"updateTime": "2023-06-13T06:49:09.162394Z"
|
||||
}
|
||||
```
|
||||
|
||||
### Using `curl`
|
||||
|
||||
Using curl is similar to using `tkn-results` CLI. You can use the same access
|
||||
token and the same API server address. The only difference is that you have to
|
||||
pass the access token as a header and provide the API path depending on what
|
||||
you want to query.
|
||||
|
||||
- Query the results
|
||||
|
||||
```bash
|
||||
curl --insecure \
|
||||
-H "Authorization: Bearer $ACCESS_TOKEN"
|
||||
-H "Accept: application/json"
|
||||
https://localhost:8080/apis/results.tekton.dev/v1alpha2/parents/default/results
|
||||
```
|
||||
|
||||
You will get a response like below.
|
||||
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
"name": "default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be",
|
||||
"id": "50b13d54-2eb0-4a45-8399-853f2d4ba028",
|
||||
"uid": "50b13d54-2eb0-4a45-8399-853f2d4ba028",
|
||||
"createdTime": "2023-03-02T07:26:48.972907Z",
|
||||
"createTime": "2023-03-02T07:26:48.972907Z",
|
||||
"updatedTime": "2023-03-02T07:26:54.191114Z",
|
||||
"updateTime": "2023-03-02T07:26:54.191114Z",
|
||||
"annotations": {},
|
||||
"etag": "50b13d54-2eb0-4a45-8399-853f2d4ba028-1677742014191114634",
|
||||
"summary": {
|
||||
"record": "default/results/dcb7926e-42e8-4338-ab7d-0b67e02389be/records/dcb7926e-42e8-4338-ab7d-0b67e02389be",
|
||||
"type": "tekton.dev/v1beta1.PipelineRun",
|
||||
"startTime": null,
|
||||
"endTime": "2023-03-02T07:26:54Z",
|
||||
"status": "SUCCESS",
|
||||
"annotations": {}
|
||||
}
|
||||
}
|
||||
],
|
||||
"nextPageToken": ""
|
||||
}
|
||||
```
|
||||
|
||||
You can also use filters to query record for a particular (set of) PipelineRun
|
||||
or TaskRun. See the available filters [here](https://github.com/tektoncd/results/blob/main/docs/api/README.md#filtering).
|
||||
|
||||
### Using gRPC
|
||||
|
||||
You can also use gRPC to query the API. You can use the same access token. You
|
||||
will need to [install](https://github.com/grpc/grpc/blob/master/doc/command_line_tool.md)
|
||||
`grpc_cli` to query the API.
|
||||
|
||||
- Querying using gRPC will need cert. Here is how to export them.
|
||||
|
||||
```bash
|
||||
kubectl get secrets tekton-results-tls -n tekton-pipelines \
|
||||
--template='{{index .data "tls.crt"}}' | base64 -d > /tmp/results.crt
|
||||
export GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=/tmp/results.crt
|
||||
```
|
||||
|
||||
- List available services
|
||||
|
||||
```bash
|
||||
grpc_cli ls --channel_creds_type=ssl \
|
||||
--ssl_target=tekton-results-api-service.tekton-pipelines.svc.cluster.local \
|
||||
localhost:8080
|
||||
```
|
||||
|
||||
You will get a response like below.
|
||||
|
||||
```bash
|
||||
grpc.health.v1.Health
|
||||
grpc.reflection.v1alpha.ServerReflection
|
||||
tekton.results.v1alpha2.Results
|
||||
```
|
||||
|
||||
- List the Results
|
||||
|
||||
```bash
|
||||
grpc_cli call --channel_creds_type=ssl \
|
||||
--ssl_target=tekton-results-api-service.tekton-pipelines.svc.cluster.local \
|
||||
--call_creds=access_token=$ACCESS_TOKEN
|
||||
localhost:8080
|
||||
tekton.results.v1alpha2.Results.ListResults 'parent: "default"'
|
||||
```
|
||||
|
||||
You will get a response like below.
|
||||
|
||||
```bash
|
||||
connecting to localhost:8080
|
||||
|
||||
results {
|
||||
name: "default/results/7afa9067-5001-4d93-b715-49854a770412"
|
||||
id: "b74a3317-e6c0-421c-85d9-54b0f3d4b4c6"
|
||||
created_time {
|
||||
seconds: 1677742028
|
||||
nanos: 143729000
|
||||
}
|
||||
etag: "b74a3317-e6c0-421c-85d9-54b0f3d4b4c6-1677742039224211588"
|
||||
updated_time {
|
||||
seconds: 1677742039
|
||||
nanos: 224211000
|
||||
}
|
||||
uid: "b74a3317-e6c0-421c-85d9-54b0f3d4b4c6"
|
||||
create_time {
|
||||
seconds: 1677742028
|
||||
nanos: 143729000
|
||||
}
|
||||
update_time {
|
||||
seconds: 1677742039
|
||||
nanos: 224211000
|
||||
}
|
||||
summary {
|
||||
record: "default/results/7afa9067-5001-4d93-b715-49854a770412/records/7afa9067-5001-4d93-b715-49854a770412"
|
||||
type: "tekton.dev/v1beta1.TaskRun"
|
||||
end_time {
|
||||
seconds: 1677742039
|
||||
}
|
||||
status: SUCCESS
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Similar to curl you can pass filters here as well.
|
||||
|
||||
## Conclusion
|
||||
|
||||
In this post, we saw how to use Tekton Results to store the results of a PipelineRun
|
||||
or TaskRun and how to query them later. Tekton Results is still in alpha, we are
|
||||
working on adding more features to it. If you have any feedback or feature request,
|
||||
please feel free to open an issue [here](https://github.com/tektoncd/results/issues)
|
||||
or reach out to us on [Slack](https://tektoncd.slack.com/). Thanks for reading!
|
||||
|
||||
## References
|
||||
|
||||
- [Tekton Results](https://github.com/tektoncd/results)
|
||||
- [Tekton Pipelines](https://github.com/tektoncd/pipeline)
|
||||
- [Tekton Results API Specification](https://petstore.swagger.io/?url=https://raw.githubusercontent.com/tektoncd/results/v0.7.0/docs/api/openapi.yaml)
|
||||
- [Tekton Results CLI](https://github.com/tektoncd/results/tree/main/tools/tkn-results)
|
||||
@@ -0,0 +1,280 @@
|
||||
---
|
||||
category: development
|
||||
date: 2020-12-01T23:47:00
|
||||
description: The project was to Create the VLC User Documentation for Android Mobile
|
||||
Port which was previously hosted on VLC wiki pages. The major portion of this was
|
||||
to start everything from scratch including chapter separation, section organization.
|
||||
image: /images/day-of-cone.webp
|
||||
modified: 2020-12-31 23:19
|
||||
tags:
|
||||
- vlc
|
||||
- gsod
|
||||
- gsod2020
|
||||
title: Create the VLC User Documentation for one Mobile Port(Android)
|
||||
---
|
||||
|
||||
VideoLAN is a non-profit organization that develops software for playing
|
||||
video and other media formats. VLC media player (commonly known as just
|
||||
VLC) is a free and Open Source cross-platform multimedia player and
|
||||
framework that plays most multimedia files as well as DVDs, Audio CDs,
|
||||
VCDs, and various streaming protocols built by the VideoLAN organization
|
||||
and a team of volunteers. VLC for Android is a port of the VLC for
|
||||
Android OS.
|
||||
|
||||
The project was to Create the VLC User Documentation for Android Mobile
|
||||
Port which was previously hosted on VLC's wiki pages. The major portion
|
||||
of this was to start everything from scratch including chapter
|
||||
separation, section organization and an engaging and easy to follow for
|
||||
both technical and non-technical users. The original proposal can be
|
||||
found here.
|
||||
|
||||
## PROJECT GOALS
|
||||
|
||||
- Propose a new structure for documentation e.g. Chapter Separation,
|
||||
Sections etc
|
||||
- Proper balance between technical and non-technical descriptions to
|
||||
serve all kinds of users.
|
||||
- Adequate amount of screenshots in each section and other supporting
|
||||
media to make documentation more appealing.
|
||||
- Optimized for all Screen Sizes. Especially for Mobile Devices.
|
||||
- Ease of navigation
|
||||
|
||||
## COMMUNITY BONDING
|
||||
|
||||
This period was mostly utilized for collecting more information and many
|
||||
internal meetings to shape the projects and bonding with fellow writers,
|
||||
developers(mentors). I got to know more about the VLC organization and
|
||||
the project. We decided to create a skeleton of the project and then
|
||||
follow a Issue-Merge Request-Review-Merge system to keep the commit
|
||||
history clean and maintain the proper review of the work before it is
|
||||
merged.
|
||||
|
||||
I initially proposed that the new documentation should also use the same
|
||||
tools(Sphinx and GitLab Pages) because if in future we want to merge all
|
||||
the documentation into a single one, it will be easier to migrate and
|
||||
will provide a consistency across all documentations. Later I got to
|
||||
know that this will be an independent project and may not be merged
|
||||
since it solves a lot of problems. I was already familiar with the tools
|
||||
so it took no time to get started.
|
||||
|
||||
Nicolas Pomepuy, who is the lead developer of VLC for Android was
|
||||
assigned as my primary mentor and Simon Latapie as secondary mentor.
|
||||
|
||||
## DOCUMENTATION DEVELOPMENT PHASE
|
||||
|
||||
Initial Preparation I first moved my existing demo documentation to an
|
||||
entirely new repository with only the skeleton at the suggestion of my
|
||||
mentor. It was necessary to keep the commit history clean. The skeleton
|
||||
contained the empty directories representing the chapter separation. I
|
||||
got to learn “how to properly develop a project and contribute to open
|
||||
source”. This was a major lesson that got me familiar with the Merge
|
||||
Request and Review system.
|
||||
|
||||
The Development The next part was to frame the actual documentation
|
||||
pages and push to the repository. Since there was a significant
|
||||
time-zone difference we agreed to discuss by creating issues and
|
||||
sometimes my emails. There was one meeting every fortnight to check the
|
||||
process and discuss further development and blockers. Nicolas was really
|
||||
helpful and patient, answering each of my big-small queries.
|
||||
|
||||
Work Done
|
||||
|
||||
<style>
|
||||
table,td,th {
|
||||
border-collapse:collapse;
|
||||
border: 1px solid #000000;
|
||||
}
|
||||
</style>
|
||||
<table>
|
||||
<tr>
|
||||
<td><strong>Documentation</strong></td>
|
||||
<td><a href="https://avinal.videolan.me/vlc-android-user/">VLC for Android User Documentation </a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Project Repository</strong>
|
||||
</td>
|
||||
<td><a href="https://code.videolan.org/avinal/vlc-android-user">Projects · Avinal Kumar / VLC for Android User Documentation</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Commits</strong>
|
||||
</td>
|
||||
<td><a href="https://code.videolan.org/avinal/vlc-android-user/-/commits/master">Commits · Avinal Kumar / VLC for Android User Documentation</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Issues/Discussions</strong>
|
||||
</td>
|
||||
<td><a href="https://code.videolan.org/avinal/vlc-android-user/-/issues">Issues · Avinal Kumar / VLC for Android User Documentation</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Merge Requests</strong>
|
||||
</td>
|
||||
<td><a href="https://code.videolan.org/avinal/vlc-android-user/-/merge_requests">Merge Requests · Avinal Kumar / VLC for Android User Documentation</a>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Since the Android port of VLC can be installed on Android
|
||||
Smartphones/Tablets, Android TVs, Amazon Fire Devices and Chromebooks
|
||||
too, a full documentation will cover these all devices. Although these
|
||||
are different form factors, the features provided on each of them is
|
||||
exactly the same and the same documentation can be used for all these
|
||||
devices. As of now only Smartphones/Tablets are covered. And later
|
||||
additional pages will be added to reference different features/User
|
||||
Interface. Regardless of this addition the current documentation can
|
||||
serve a major part for all these form factors. Completed/Remaining
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td><strong>Chapters</strong>
|
||||
</td>
|
||||
<td><strong>Sections</strong>
|
||||
</td>
|
||||
<td><strong>Status</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Settings</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>General Settings
|
||||
<li>Interface
|
||||
<li>Video
|
||||
<li>Subtitles
|
||||
<li>Audio
|
||||
<li>Casting
|
||||
<li>Advanced
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>ALL COMPLETED</strong>
|
||||
<p>
|
||||
<strong>FOR ALL FORM FACTORS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Video</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>Video Explorer
|
||||
<li>Video Player
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Audio</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>Audio Explorer
|
||||
<li>Audio Player
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Browse</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>Explorer
|
||||
<li>Local Network
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>ONLY SMB IN LOCAL NETWORK COMPLETED</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Installation</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>Smartphones/Tablets
|
||||
<li>Android TV
|
||||
<li>Fire Devices
|
||||
<li>Chromebooks
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>User Interface</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>Smartphones/Tablets
|
||||
<li>Android TV
|
||||
<li>Fire Devices
|
||||
<li>Chromebooks
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Support</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>FAQs
|
||||
<li>Help
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>IN PROGRESS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Guidelines</strong>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>Contribution Guideline
|
||||
<li>Screenshot Guidelines
|
||||
<li>READMEs
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><strong>IN PROGRESS</strong>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## CHALLENGES
|
||||
|
||||
The major obstacle was to get screenshots for all form factors. Since
|
||||
screenshots were the major part of this documentation it was necessary
|
||||
to provide proper screenshots in each chapter and with every step. For
|
||||
Android TV and Smartphone this was solved by using emulators instead of
|
||||
actual devices, but to emulate the actual scenario in an emulator was
|
||||
sometimes very difficult. There were many occasions where I was not able
|
||||
to gather the exact information about devices other than
|
||||
smartphones/tables. Since all form factors share a common pool of
|
||||
features, my mentor suggested that I focus on smartphones/tables. And to
|
||||
create issues mentioning missing parts so that it could be solved later.
|
||||
|
||||
## THANKS
|
||||
|
||||
I want to thank my mentors for being supporting and helpful. I want to
|
||||
thank every person at VLC and Google who were involved in this whole
|
||||
process. Thanks and Congrats to my fellow writer Abhishek Pratap Singh.
|
||||
This was a great opportunity to learn and meet awesome people. I learned
|
||||
a lot about Sphinx, reStructured Text and many other things.
|
||||
|
||||
## ATTRIBUTION
|
||||
|
||||
- [Image by Tom Bigelajzen](https://images.videolan.org/images/goodies/day-of-the-cones-ex2.jpg)
|
||||
@@ -0,0 +1,172 @@
|
||||
---
|
||||
category: blogs
|
||||
date: 2023-03-16T20:47:00
|
||||
description: Tekton Results aims to help users logically group CI/CD workload history
|
||||
and separate out long term result storage away from the Pipeline controller.
|
||||
image: /images/tekton-results-wall.webp
|
||||
tags:
|
||||
- tekton
|
||||
- kubernetes
|
||||
- redhat
|
||||
- openshift
|
||||
- results
|
||||
title: Tekton Results to the Rescue
|
||||
---
|
||||
|
||||
What do you do with your Tekton Pipelines once it finishes? Depending on if it
|
||||
failed or passed, you may keep it to inspect the logs. For most of the users/organizations
|
||||
the simplest step is to keep the completed TaskRuns/PipelineRuns object on the
|
||||
cluster to retrieve the data later.
|
||||
|
||||
Imagine having thousands of runs and although a single TaskRun object takes very
|
||||
small space compared to the scale of a production cluster, but these little
|
||||
things add up quickly, and soon your cluster will be burdened with objects that
|
||||
probably no one will ever revisit. The organization/user is keeping them
|
||||
just-in-case if they want to see the logs and other data later.
|
||||
|
||||
Although in most of the cases there is a pruning policy that takes care of these
|
||||
objects. But there are multiple problems with this approach.
|
||||
|
||||
- This type of storage is not reliable and very difficult to query.
|
||||
- If the scale is massive, this could lead to destabilization of the cluster.
|
||||
- If you have a pruning policy, the completed objects are cleaned, and you lose all the associated data as well.
|
||||
|
||||
So, what is the solution, how can you save your pipelines' data without having to keep them on cluster?
|
||||
|
||||
## Introducing Tekton Results
|
||||
|
||||
As mentioned on the [project repository](https://github.com/tektoncd/results):
|
||||
|
||||
> Tekton Results aims to help users logically group CI/CD workload history and
|
||||
> separate out long term result storage away from the Pipeline controller. This
|
||||
> allows you to:
|
||||
>
|
||||
> - Provide custom Result metadata about your CI/CD workflows not available in
|
||||
> the Tekton TaskRun/PipelineRun CRDs (for example: post-run actions)
|
||||
> - Group related workloads together (e.g. bundle related TaskRuns and PipelineRuns into a single unit)
|
||||
> - Make long-term result history independent of the Pipeline CRD controller,
|
||||
> letting you free up etcd resources for Run execution.
|
||||
|
||||
In short, Tekton results archives the run data (called results) and logs to an
|
||||
external storage. Now you can safely prune completed TaskRuns/PipelineRuns and
|
||||
save run data and logs for a later visit. Let us see how actually Tekton Results
|
||||
works under the hood.
|
||||
|
||||
### How Tekton Results Works?
|
||||
|
||||
Tekton Results is composed of two main components.
|
||||
|
||||
- A **watcher** to listen to creation/update of PipelineRuns or TaskRuns.
|
||||
- An **API Server** to query the persistent storage for data.
|
||||
|
||||
In addition to that, Tekton Results needs a working database connection that can
|
||||
be a persistent storage on the same cluster or hosted externally such as RDS.
|
||||
If no external storage is attached, logs are also stored on a persistent storage
|
||||
on the cluster, you may use a S3 (or compatible) storage solution for that.
|
||||
|
||||
The lifecycle of a _result_ is as below:
|
||||
|
||||
1. The first step is to create a Tekton PipelineRun or TaskRun.
|
||||
2. The Watcher listens for any changes in the TaskRun or PipelineRun.
|
||||
3. On change, Watcher updates (or creates) a corresponding `Record` or `Result` using the Results API.
|
||||
Watcher adds annotations to the TaskRuns or PipelineRuns with proper identifiers. Watcher uses
|
||||
these annotations to decide if the `Result` has been created/updated/finished or not.
|
||||
4. You can now query the Results data using the API. If the run state is incomplete yet, the response
|
||||
from the API will indicate that as well via the status flag.
|
||||
5. Once the TaskRun/PipelineRun has been completed, you can safely prune the resource object.
|
||||
|
||||
## Installing Tekton Results
|
||||
|
||||
Installing Tekton Results is easy. You can use Kubernetes or OpenShift cluster, for this particular
|
||||
demonstration, I will be using a Kind cluster and a local database.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) for a local Kubernetes cluster.
|
||||
- [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
|
||||
- [curl](https://curl.se/download.html) for querying the API.
|
||||
- [OpenSSL](https://www.openssl.org/source/) for generating certificates.
|
||||
|
||||
### Let's start
|
||||
|
||||
1. Create a Kind Cluster
|
||||
|
||||
```bash
|
||||
kind create cluster --name tekton-results
|
||||
kind export kubeconfig --name tekton-results
|
||||
```
|
||||
|
||||
2. [Tekton Pipelines](https://github.com/tektoncd/results) must be installed on
|
||||
the cluster. You can install it using the command below.
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
|
||||
```
|
||||
|
||||
3. Generate a database root password and store as a Kubernetes Secret. If you are using an external
|
||||
database, prove the credential for the same. Here is a bare minimum requirement as YAML.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: tekton-results-postgres
|
||||
namespace: tekton-pipelines
|
||||
type: Opaque
|
||||
data:
|
||||
POSTGRES_USER: postgres
|
||||
POSTGRES_PASSWORD: <your-password>
|
||||
```
|
||||
|
||||
You can directly use the command line as well:
|
||||
|
||||
```bash
|
||||
kubectl create secret generic tekton-results-postgres \
|
||||
--namespace="tekton-pipelines" \
|
||||
--from-literal=POSTGRES_USER=postgres \
|
||||
--from-literal=POSTGRES_PASSWORD=$(openssl rand -base64 20)
|
||||
```
|
||||
|
||||
4. Generate a cert/key pair. You may use any cert management software to generate this. You can even
|
||||
use cluster generated certs.
|
||||
|
||||
```bash
|
||||
openssl req -x509 \
|
||||
-newkey rsa:4096 \
|
||||
-keyout key.pem \
|
||||
-out cert.pem \
|
||||
-days 365 \
|
||||
-nodes \
|
||||
-subj "/CN=tekton-results-api-service.tekton-pipelines.svc.cluster.local" \
|
||||
-addext "subjectAltName = DNS:tekton-results-api-service.tekton-pipelines.svc.cluster.local"
|
||||
```
|
||||
|
||||
5. Create another TLS Kubernetes Secret with the name `tekon-results-tls` to store the cert/key pair.
|
||||
|
||||
```bash
|
||||
kubectl create secret tls -n tekton-pipelines tekton-results-tls \
|
||||
--cert=cert.pem \
|
||||
--key=key.pem
|
||||
```
|
||||
|
||||
6. Install Tekton Results
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://storage.googleapis.com/tekton-releases/results/latest/release.yaml
|
||||
```
|
||||
|
||||
7. You can check the status of the deployments using the below command. Do not worry
|
||||
if some deployments show `CrashLoopBackOff`. Wait for some time, and
|
||||
they should all be running.
|
||||
|
||||
```bash
|
||||
kubectl get pods -n tekton-pipelines --watch
|
||||
```
|
||||
|
||||
Once all deployments are ready, we can start creating some TaskRuns/PipelineRuns. In the next part
|
||||
of this blog, I will explain how to retrieve data from Tekton Results. Happy Reading.
|
||||
|
||||
## References
|
||||
|
||||
- [Tekton Results](https://github.com/tektoncd/results)
|
||||
- [Tekton Pipelines](https://github.com/tektoncd/pipeline)
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
category: blogs
|
||||
date: 2021-01-04T21:47:00
|
||||
image: /images/hrt-singapore.webp
|
||||
tags:
|
||||
- HRT
|
||||
- hudsonrivertrading
|
||||
- interview
|
||||
- internship
|
||||
title: HRT (Hudson River Trading) Systems Internship Interview Experience
|
||||
---
|
||||
|
||||
I applied for **Systems Internship - Summer 2021** back in December 2020
|
||||
at [Hudson River Trading](https://www.hudsonrivertrading.com), New
|
||||
York. The internship description was: -
|
||||
|
||||
> We are looking for highly motivated students who are eager to learn
|
||||
> and excited about systems to join us for our summer internship
|
||||
> program. As a systems intern, you may have the opportunity to work on
|
||||
> projects in the following areas:
|
||||
>
|
||||
> - Programming/scripting (Golang, Python, C++, C)
|
||||
> - FOSS development
|
||||
> - HPC, Cluster computing
|
||||
> - System Administration
|
||||
> - Linux, Debian
|
||||
> - Linux-based computer security
|
||||
> - Data Storage
|
||||
> - Large deployment or config management
|
||||
|
||||
The first step was a coding test on the Codility platform. If you have
|
||||
used any of the online coding platforms, this is similar. It was a
|
||||
`2.5 hrs (90 mins)` test consisting of 3 questions. They let you use
|
||||
`online references (documentation, man pages, etc.)` but **do not copy
|
||||
the code** as it will highly reduce your chances of qualifying for this
|
||||
first stage. You can choose between **C/C++**, **Python** and **Golang**
|
||||
(no Java 😪).
|
||||
|
||||
Questions were clear and of medium level. But they were designed in such
|
||||
a way that you must know the basics before you could attempt. Also, they
|
||||
expected a clear and concise approach. Two of the most important points
|
||||
in their instructions were: -
|
||||
|
||||
> - While correctness and performance are the most important factors
|
||||
> for evaluation, we will take test duration into account as well.
|
||||
> - Please understand that this test is meant to be challenging. A
|
||||
> perfect score is not necessary to move on to future interview
|
||||
> rounds, so do the best you can!
|
||||
|
||||
So, you must be near perfect in your approach as well as on time. I did
|
||||
them kind of quickly. They will show you a summary of your submission
|
||||
but not the results. It will take almost 2 weeks to get back to you for
|
||||
further steps.
|
||||
|
||||
Next, I received a mail invitation for a telephonic interview. **This
|
||||
interview will last about 45 minutes and will be technical but will not
|
||||
require coding. Interview topics may include your background,
|
||||
programming languages, and Unix/Linux concepts**. Once you receive this
|
||||
mail you can then decide a time slot for an interview.
|
||||
|
||||
I was not sure what they will ask if this is not a coding interview. The
|
||||
interviewer was very polite, and he was explaining the questions too.
|
||||
Questions were not so tricky but practical and real-life. Since it was
|
||||
**not for SDE role**, the questions were mostly related to Linux/Unix,
|
||||
C++ (mainly pointers and memory), Python/Bash scripting, automation,
|
||||
knowledge of tools (IDEs, Editors, System Administration Tools) and
|
||||
previous experiences. The interview would often explain why he is asking
|
||||
this question, this was very nice. Then some common interview questions,
|
||||
why do you want to work for this role? What makes you fit for this role?
|
||||
etc.
|
||||
|
||||
One thing that I want to point out is that the interviewer was
|
||||
repeatedly checking my resume, and for the most part he did not ask
|
||||
anything that was not on my resume. So, my tip is to create a nice
|
||||
resume with genuine work/tool experiences. And when you are applying for
|
||||
such a role, it would be helpful if you mention mathematics or other
|
||||
courses that you have taken. *Do not lie on your resume*. They will
|
||||
easily catch that.
|
||||
|
||||
The other thing is to keep your words short and clear; I was not great
|
||||
at communication, but you can be. If the interviewer allows then use
|
||||
examples for the things you cannot explain. I used nice examples. At
|
||||
last, he gave me short feedback on how well I performed.
|
||||
|
||||
At last, I want to point out things I should not have done. The first
|
||||
is, I did not ask much about the role, you must do this at least once.
|
||||
Second, I am talkative, I do not know if the interviewer was not faking
|
||||
his expressions (because he would often discuss in-depth), but not all
|
||||
interviewers will be the same. So, do not talk too much, nor too less.
|
||||
At last work on your communication skill, mostly how you to present
|
||||
things and how to answer technical as well as behavioral questions. I
|
||||
was not fluent, but my way of presentation might have saved me.
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Setup Remark42 from scratch on Oracle Cloud
|
||||
draft: true
|
||||
---
|
||||
@@ -0,0 +1,312 @@
|
||||
---
|
||||
category: development
|
||||
date: 2021-05-24T23:56:00
|
||||
description: CMake stands for Cross-platform Make. Normally, a build tool like Make
|
||||
will parse a configuration file (Makefile) that contains all the commands required
|
||||
to build an artifact based on the source files and other resources inside the project.
|
||||
image: /images/cmake-office.webp
|
||||
slug: cmake-basics
|
||||
tags:
|
||||
- cmake
|
||||
- gsoc
|
||||
- fossology
|
||||
- gsoc21
|
||||
title: Hello CMake
|
||||
---
|
||||
|
||||
CMake stands for Cross-platform Make. Normally, a build tool like Make
|
||||
will parse a configuration file (Makefile) that contains all the
|
||||
commands required to build an artifact based on the source files and
|
||||
other resources inside the project.
|
||||
|
||||
I proposed a new architecture for FOSSology that uses CMake instead of
|
||||
bare-metal Make as a Google Summer of Code 2021 project. Although these
|
||||
tutorials will be useful for anyone interested in learning CMake they
|
||||
are specifically tailored to the FOSSology project. This is the first
|
||||
blog on CMake in this series. In this blog, I will discuss CMake syntax
|
||||
and various features.
|
||||
|
||||
## What is CMake?
|
||||
|
||||
|
||||
|
||||
CMake stands for Cross-platform Make. Normally, a build tool like Make
|
||||
will parse a configuration file (Makefile) that contains all the
|
||||
commands required to build an artifact based on the source files and
|
||||
other resources inside the project. On the other hand, CMake will also
|
||||
parse a configuration file (CMakeLists.txt), but instead of directly
|
||||
build the artifact, it’ll generate another configuration file that will
|
||||
build the artifact.
|
||||
|
||||
This approach is very common in Computer Science and is called *adding
|
||||
another level of indirection*. In short, you may say that:
|
||||
|
||||
With just one configuration file you’ll be able to generate different configuration files to build your project for different platforms (Make, Visual Studio, etc).
|
||||
|
||||
Another nice CMake feature is the so-called out-of-source build. Any
|
||||
file required for the final build, executables included, will be stored
|
||||
in a separated build directory (usually called build/). This prevents
|
||||
cluttering up the source directory and makes it easy to start over
|
||||
again: just remove the build directory and you are done.
|
||||
|
||||
## CMake Syntax
|
||||
|
||||
|
||||
|
||||
CMake unlike Make is a configuration language itself. CMake supplies a
|
||||
rich library of inherent functions as well as common programming
|
||||
language features like conditions, looping, macros, and functions. In
|
||||
addition to that CMake is highly modular and you can always write a
|
||||
CMake module yourself independent of any project. Specifically for C/C++
|
||||
programming, it supplies commands to find and link libraries
|
||||
automatically and lot many features.
|
||||
|
||||
### Language Rules
|
||||
|
||||
As mentioned above CMake is a language itself hence there are some
|
||||
language rules related to syntax, comments, variables, etc.
|
||||
|
||||
- There are two types of comment in CMake, both start with `#`
|
||||
character. The first one is line comments, as clear by name it is
|
||||
delimited by a newline. The other one is bracket comment and can
|
||||
span until the matching brackets are found.
|
||||
|
||||
```cmake
|
||||
# This is a line comment and it ends with the line.
|
||||
|
||||
#[[This is a bracket comment and it can span up to multiple lines.
|
||||
But it is only supported in CMake 3.0 or later.]]
|
||||
```
|
||||
|
||||
- Variables in CMake are like any other programming language. They are
|
||||
case-sensitive and have any alphanumeric characters. In general, it
|
||||
is recommended using upper case names as variables. They can be
|
||||
assigned and unassigned using `set` and `unset` commands. A variable
|
||||
can be referenced using `${VARIABLE_NAME}`.
|
||||
|
||||
> CMake reserves some types of identifers:
|
||||
>
|
||||
> - begin with **CMAKE_**(upper-, lower-, or mixed-case)
|
||||
> - begin with ***CMAKE***(upper-, lower-, or mixed-case)
|
||||
> - begin with **_** followed by the name of any CMake Command
|
||||
|
||||
- The CMake commands are case insensitive in the latest version (3.0)
|
||||
of CMake. That means `message()`, `Message()` or `MESSAGE()` are all
|
||||
same.
|
||||
|
||||
### Basic CMake Commands
|
||||
|
||||
- The `project()` command is used to set the name of the CMake project
|
||||
and optionally a language that is used by the project. Every
|
||||
top-level CMake configuration must have this option set. The syntax
|
||||
is as below:
|
||||
|
||||
```cmake
|
||||
project (projectname [CXX] [C] [Java] [NONE])
|
||||
```
|
||||
|
||||
If no language is specified then CMake defaults to supporting C/C++.
|
||||
If `NONE` is specified then no language support is enabled.
|
||||
|
||||
- The `set()` command is used to set a variable to a value or lists of
|
||||
values. It is one of the most used CMake commands. The accompanying
|
||||
command is `unset()`. The `unset()` command is used to unset a
|
||||
variable or remove a variable from the current scope. The syntax for
|
||||
the three commands are:
|
||||
|
||||
```cmake
|
||||
set (BLOG_TITLE "CMake Introduction") # assign single value
|
||||
set (BLOG_TAGS "gsoc" "cmake" "fossology" "gsoc21") # assign a list of values
|
||||
|
||||
unset (BLOG_TITLE) # unset BLOG_TITLE
|
||||
```
|
||||
|
||||
- The `message()` command can be used to display formatted messages
|
||||
with different alert modes. There are many
|
||||
[modes](https://cmake.org/cmake/help/v3.20/command/message.html#general-messages)
|
||||
of displaying messages. The syntax is :
|
||||
|
||||
```cmake
|
||||
message ([<mode>] "message text" ...)
|
||||
|
||||
message(NOTICE "Hey this is ${BLOG_TITLE}") # Example message with variable
|
||||
```
|
||||
|
||||
- The `cmake_minimum_required()` is used to set the minimum CMake
|
||||
version to use to generate the build files. If any older version is
|
||||
used than specified then the user gets an error message. It must be
|
||||
specified at the top of the *CMakeLists.txt* file.
|
||||
|
||||
```cmake
|
||||
cmake_minimum_required (VERSION 3.0)
|
||||
```
|
||||
|
||||
- The commands `add_executable()` and `add_library()` specifies what
|
||||
executables and libraries to build and what source files must be
|
||||
used to build them. One of the two commands must be used for any
|
||||
binary generation.
|
||||
|
||||
```cmake
|
||||
add_executable(<name> [WIN32] [MACOSX_BUNDLE]
|
||||
[EXCLUDE_FROM_ALL]
|
||||
[source1] [source2 ...])
|
||||
|
||||
add_library(<name> [STATIC | SHARED | MODULE]
|
||||
[EXCLUDE_FROM_ALL]
|
||||
[<source>...])
|
||||
```
|
||||
|
||||
### Flow Control
|
||||
|
||||
CMake provides three flow control structures. They are conditional
|
||||
statements (`if`), looping constructs (`foreach` and `while`) and
|
||||
procedure definitions (`function` and `macro`). I will explain each of
|
||||
them one by one.
|
||||
|
||||
- **Conditional Statements** The `if` command in CMake is just like
|
||||
the `if` command in any other language. It evaluates its expression
|
||||
and based on that either executes the code in its body or optionally
|
||||
the code in the `else` clause.
|
||||
|
||||
```cmake
|
||||
if (FOO)
|
||||
# do something here
|
||||
elseif (BAR)
|
||||
if (NESTED_BAR)
|
||||
# do something nested here
|
||||
endif(NESTED_BAR)
|
||||
# do something else
|
||||
else ()
|
||||
# do something here
|
||||
endif (FOO)
|
||||
```
|
||||
|
||||
You can use many operators to form complex conditions. Available
|
||||
options are **NOT**, **AND**, **OR**, **COMMAND**, **DEFINED**,
|
||||
**EXISTS**, **IS_DIRECTORY**, **IS_ABSOLUTE**, **MATCHES**,
|
||||
**IS_NEWER_THAN**, and operators for numerical comparisons
|
||||
**EQUAL**, **LESS**, **GREATER**, **STRLESS**, **STREQUAL**,
|
||||
**STRGREATER**.
|
||||
|
||||
- **Looping Constructs** The `foreach` command enables you to execute
|
||||
a group of CMake commands repeatedly on the members of a list.The
|
||||
first argument of the foreach command is the name of the variable
|
||||
that will take on a different value with each iteration of the loop.
|
||||
The remaining arguments are the list of values over which to loop.
|
||||
|
||||
```cmake
|
||||
foreach(<loop_var> <items>)
|
||||
<commands>
|
||||
endforeach()
|
||||
```
|
||||
|
||||
The `while` command provides for looping based on a test condition.
|
||||
The format for the test expression in the `while` command is the
|
||||
same as that for the `if` command described earlier.
|
||||
|
||||
```cmake
|
||||
while(<condition>)
|
||||
<commands>
|
||||
endwhile()
|
||||
```
|
||||
|
||||
It is worth mentioning that foreach loops can be nested and that the
|
||||
loop variable is replaced prior to any other variable expansion.
|
||||
This means that in the body of a foreach loop you can construct
|
||||
variable names using the loop variable.
|
||||
|
||||
- **Procedure Definitions** A function in CMake is very much like a
|
||||
function in C or C++. You can pass arguments into it, and the
|
||||
arguments passed in become variables within the function. The first
|
||||
argument is the name of the function to define. All additional
|
||||
arguments are formal parameters to the function.
|
||||
|
||||
```cmake
|
||||
function(<name> [<arg1> ...])
|
||||
# write the function body here
|
||||
<commands>
|
||||
endfunction()
|
||||
```
|
||||
|
||||
Macros are defined and called in the same manner as functions. The
|
||||
main differences are that a macro does not push and pop a new
|
||||
variable scope, and the arguments to a macro are not treated as
|
||||
variables but are string replaced prior to execution. This is very
|
||||
much like the differences between a macro and a function in C or
|
||||
C++. The first argument is the name of the macro to create. All
|
||||
additional arguments are formal parameters to the macro.
|
||||
|
||||
```cmake
|
||||
macro(<name> [<arg1> ...])
|
||||
# write macro definition here
|
||||
<commands>
|
||||
endmacro()
|
||||
```
|
||||
|
||||
## A Hello CMake example
|
||||
|
||||
This example compiles a simple *hello_cmake* program. This example and
|
||||
the terminal commands are used in Linux context, however there is very
|
||||
little difference in different platforms. Make sure to [install
|
||||
CMake](https://cmake.org/install/) for your platform.
|
||||
|
||||
- Create a folder and create a file named `hello_cmake.cpp` in that.
|
||||
You may add your own code. Here is my example code.
|
||||
|
||||
```cpp
|
||||
#include<iostream>
|
||||
|
||||
int main() {
|
||||
std::cout << "Hello CMake\n";
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
- Create another file named `CMakeLists.txt` and add the following
|
||||
script in that file.
|
||||
|
||||
```cmake
|
||||
cmake_minimum_required(VERSION 3.0)
|
||||
|
||||
# set project name
|
||||
project(hello_cmake)
|
||||
|
||||
# print compiler info
|
||||
message("The compiler is ${CMAKE_CXX_COMPILER}")
|
||||
|
||||
# add executable
|
||||
add_executable(Hello_cmake hello_cmake.cpp)
|
||||
```
|
||||
|
||||
- Create another directory `build` and run the following commands.
|
||||
|
||||
```bash
|
||||
# create folder and change directory
|
||||
mkdir build && cd build
|
||||
|
||||
# run cmake config
|
||||
cmake ..
|
||||
|
||||
# build project
|
||||
cmake --build .
|
||||
```
|
||||
|
||||
You will be able to see a `Hello_cmake` binary in the *build* folder.
|
||||
Hooray you have successfully built a project using CMake. For more [read
|
||||
here](https://cmake.org/cmake/help/v3.20/guide/tutorial/index.html). In
|
||||
the next blog I will explain how to create CMake configuration for a
|
||||
more complex project.
|
||||
|
||||
Thanks!
|
||||
|
||||
## References and Credits
|
||||
|
||||
- [CMake Website](https://cmake.org)
|
||||
- [CMake
|
||||
Documentation](https://cmake.org/cmake/help/latest/index.html)
|
||||
- [Mastering CMake Book](https://www.kitware.com/what-we-offer/#books)
|
||||
- [CMake
|
||||
Tutorial](https://cmake.org/cmake/help/v3.20/guide/tutorial/index.html)
|
||||
- [You (C)Make Me
|
||||
Happy](https://prateekvjoshi.com/2014/02/01/cmake-vs-make/)
|
||||
- [Compiling xkcd.com](https://xkcd.com/303/)
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
category: development
|
||||
date: 2022-02-25T20:47:00
|
||||
description: I made it to the Red Hat as a DevTools intern. This post is about onboarding
|
||||
and how I prepared myself for working on the actual project.
|
||||
image: /images/fedora-wall.webp
|
||||
tags:
|
||||
- kubernetes
|
||||
- redhat
|
||||
- docker
|
||||
- golang
|
||||
- tekton
|
||||
- openshift
|
||||
- intern
|
||||
title: My internship at Red Hat
|
||||
---
|
||||
|
||||
I have been contributing to open source for the last 3 years and Red Hat
|
||||
was one of the companies that I was very fond of. I must say all my
|
||||
contributions and consistency paid off, and I made it to the Red Hat as
|
||||
a DevTools intern. This post is about onboarding and how I prepared
|
||||
myself for working on the actual project.
|
||||
|
||||
On the first day of my internship, I met two amazing teammates
|
||||
[Saytam](https://github.com/) and [Utkarsh](https://github.com/). We
|
||||
were also introduced to a Senior Software Engineer [Piyush
|
||||
Garg](https://github.com) who later mentored us. The initial few
|
||||
meetings were more on the introduction and what to learn topics. Before
|
||||
I jump into more details let me explain first what does a **DevTools
|
||||
Developer/Engineer** do?
|
||||
|
||||
## What does a DevTools Developer/Engineer do?
|
||||
|
||||
From [MDN Web
|
||||
Docs](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools)
|
||||
**Developer tools (or "development tools" or short "DevTools") are
|
||||
programs that allow a developer to create, test, and debug software.**
|
||||
At RedHat, a lot of open source developer tools of industry standards
|
||||
are developed. There are many, OpenShift, Tekton, CodeReady containers,
|
||||
and many more.
|
||||
|
||||
## Learning on the Go
|
||||
|
||||
There was a lot of learning and still a lot to learn. In a meeting with
|
||||
my manager [^1] Pradeepto Bhattacharya, I was told that I will be working on
|
||||
TektonCD or OpenShift Pipelines, and both of them require a sound
|
||||
knowledge of Golang, CI/CD, Containers, Docker, and Kubernetes. I was
|
||||
familiar with CI/CD, containers, and Docker but never used Golang and
|
||||
Kubernetes. We were provided plenty of good resources and my teammates
|
||||
also helped with many awesome resources. I am listing all the resources
|
||||
with their category.
|
||||
|
||||
### Go Programming Language
|
||||
|
||||
One of Golang's biggest advantages is that it offers the clarity and
|
||||
ease of use that other languages lack. Golang's advantages make it easy
|
||||
for new programmers to quickly understand the language and for seasoned
|
||||
veterans to easily read each other's code.
|
||||
|
||||
- [Official Go Documentation](https://go.dev/doc/) - *Start from here*
|
||||
- [Go by Example](https://gobyexample.com/) - *bite-size examples for
|
||||
most of the golang features*
|
||||
- [Golang tutorial series -
|
||||
GOLANGBOT.COM](https://golangbot.com/learn-golang-series/) - *in-depth
|
||||
tutorial of golang*
|
||||
- [Effective Go](https://go.dev/doc/effective_go) - *writing good golang
|
||||
programs*
|
||||
- [The Go Playground](https://go.dev/play/) - *official online golang
|
||||
ide*
|
||||
- [The Go Programming Language - Book](https://www.gopl.io/) *for
|
||||
learning advanced level golang*
|
||||
- [Golang Tutorial for Beginners | Full Go Course - TechWorld with
|
||||
Nana](https://youtu.be/yyUHQIec83I) *if you prefer video tutorials, I
|
||||
don't :)*
|
||||
|
||||
### Docker
|
||||
|
||||
Docker takes away repetitive, mundane configuration tasks and is used
|
||||
throughout the development lifecycle for fast, easy, and portable
|
||||
application development - desktop and cloud. Docker's comprehensive
|
||||
end-to-end platform includes UIs, CLIs, APIs, and security that are
|
||||
engineered to work together across the entire application delivery
|
||||
lifecycle.
|
||||
|
||||
|
||||
|
||||
- [Docker and Containers -
|
||||
Katacoda](https://www.katacoda.com/courses/docker) *interactive
|
||||
lessons on docker and containers*
|
||||
- [Docker for beginners](https://docker-curriculum.com/)
|
||||
- [Docker Tutorial for Beginners | TechWorld with
|
||||
Nana](https://youtu.be/3c-iBn73dDE) *video tutorial*
|
||||
|
||||
### Kubernetes
|
||||
|
||||
|
||||
|
||||
**Kubernetes** is the Greek word for a ship's captain. We get the words
|
||||
Cybernetic and Gubernatorial from it. The Kubernetes project focuses on
|
||||
building a robust platform for running thousands of containers in
|
||||
production.
|
||||
|
||||
- [Learn Kubernetes -
|
||||
Katacoda](https://www.katacoda.com/courses/kubernetes) *interactive
|
||||
lessons with kubernetes*
|
||||
- [kube by example](https://kubebyexample.com/) *learn by doing*
|
||||
- [Kubernetes Tutorial for Beginners](https://youtu.be/X48VuDVv0do)
|
||||
*video tutorial*
|
||||
|
||||
## *Not so Minimal* Tekton Server
|
||||
|
||||
In late January, we were asked to implement our learnings and deep dive
|
||||
into Kubernetes and TektonCD through an assignment project. Soon we
|
||||
realized that whatever we were learning so far was not even close to
|
||||
what we were going to implement. We were given a document containing the
|
||||
requirements of the applications we were supposed to create along with
|
||||
all the documentation and architectural diagrams.
|
||||
|
||||
The application was called **Minimal Tekton Server**. It is a set of
|
||||
three different applications, i.e a server, a CLI, and a dashboard. In
|
||||
short, this application is supposed to *listen to custom resources being
|
||||
created and then transfer the request to Tekton API to create the
|
||||
corresponding resource on the OpenShift/Kubernetes cluster.*
|
||||
|
||||
So are you interested in how it went? Please follow up with my [next
|
||||
blog](https://avinal.space/posts/development/lovely-dangerous-things-redhat).
|
||||
|
||||
[^1]: [MDN Web
|
||||
Docs](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools)
|
||||
@@ -0,0 +1,220 @@
|
||||
---
|
||||
category: development
|
||||
date: 2022-02-27T20:47:00
|
||||
description: This blog is a descreptive account of the development of Minimal Tekton
|
||||
Server. This is highly technical in nature, so please make sure that you have sufficient
|
||||
knowledge about Golang, Docker, Kubernetes and TektonCD. You can refer to my [previous
|
||||
blog]("https://avinal.space/posts/development/i-am-loving-it-redhat.html") to know
|
||||
about these topics.
|
||||
image: /images/development.webp
|
||||
modified: 2022-03-07 22:47
|
||||
tags:
|
||||
- tekton
|
||||
- go
|
||||
- kubernetes
|
||||
- openshift
|
||||
- redhat
|
||||
- intern
|
||||
- golang
|
||||
- openshift-pipelines
|
||||
title: Developing Minimal Tekton Server
|
||||
---
|
||||
|
||||
This blog is a descreptive account of the development of Minimal Tekton Server.
|
||||
This is highly technical in nature, so please make sure that you have sufficient
|
||||
knowledge about Golang, Docker, Kubernetes and TektonCD. You can refer to my
|
||||
[previous blog]("https://avinal.space/posts/development/i-am-loving-it-redhat.html")
|
||||
to know about these topics.
|
||||
|
||||
As mentioned in my last blog, we were given to implement an application
|
||||
named **Minimal Tekton Server**. The problem statement reads:
|
||||
|
||||
> We will be designing and implementing an application that will be
|
||||
> talking to Tekton APIs to create resources on a Kubernetes/OpenShift
|
||||
> Cluster. The application will expose some fields of the Tekton
|
||||
> Resources which the user will provide and then this application will
|
||||
> create Tekton resources by talking to Tekton APIs available on the
|
||||
> cluster to create the resources based on the user-provided fields.
|
||||
|
||||
There are three parts in this project for the application and two more
|
||||
parts for the CI/CD using TektonCD and Kubernetes/OpenShift. I will go
|
||||
through each part descriptively and try to explain what we did.
|
||||
|
||||
## The Architecture of MKS
|
||||
|
||||
The first task in the development of the Minimal Tekton Server was
|
||||
creating its architectural diagram. Our first diagram was trash compared
|
||||
to the final diagram. Yeah, we learned. I will be explaining our
|
||||
final(obviously) architectural diagram and try to make some sense out of
|
||||
band-aids and duct tapes.
|
||||
|
||||
|
||||
|
||||
Let me start with explaining **What are MKS Resources?**. I hope you
|
||||
know at least tidbits about Kubernetes and by the definition: *A
|
||||
resource is an endpoint in the Kubernetes API that stores a collection
|
||||
of API objects of a certain kind; for example, the built-in
|
||||
`pods` resource contains a collection of Pod objects.* But
|
||||
developers soon realized that these in-built resources were not enough
|
||||
for the ever-growing applications of Kubernetes. Here [custom
|
||||
resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
comes into the picture. *A custom resource is an extension of the
|
||||
Kubernetes API that is not necessarily available in a default Kubernetes
|
||||
installation.* To define a custom resource we use something called
|
||||
[Custom Resource
|
||||
Definition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
So MKS Resources are such custom resources that correspond to the
|
||||
TektonCD custom resources.
|
||||
|
||||
|
||||
|
||||
Let us now focus on the box containing `Controller` and `API server`.
|
||||
The controller can be said as a stimulus-response mechanism. Take the
|
||||
analogy of a Venus Flytrap plant. The trap is initially open. There are
|
||||
`trigger` hairs on the inside of the trap. Once an insect is detected,
|
||||
there is a change of state and the trap closes in a blick on the eye.
|
||||
The controller works the same way. It listens for the change in the
|
||||
state of the MKS resources and immediately transfers the request to the
|
||||
Tekton API to reflect the change in the corresponding Tekton resources.
|
||||
The changes can be creation, deletion, or updating. The API server
|
||||
ensures that there is a working connection between our controller and
|
||||
the Tekton API.
|
||||
|
||||
MKS Server also exposes APIs to introduce a change of state in the MKS
|
||||
resources. In technical terms these are called `verbs`. There are five
|
||||
such verbs that we have exposed: `create`, `update`, `get`, `delete`,
|
||||
and `list`. They can be utilized by a REST client, or in our case **MKS
|
||||
CLI** to introduce desired change. The MKS command-line interface
|
||||
provides commands and subcommands to do the desired tasks.
|
||||
|
||||
Whenever there is a change in the state, there is a logic running inside
|
||||
the controller to react on that and that also affects our database. We
|
||||
store four datapoints in our database: `created`, `deleted`,
|
||||
`completed`, and `failed`. They tell us about the current statistcs of
|
||||
our MKS resource using a single-page web app called **MKS Dashboard**
|
||||
(or UI).
|
||||
|
||||
This was about the architecture of the Minimal Tekton Server. Let us
|
||||
jump into more technical stuff.
|
||||
|
||||
## How to implement a CRD controller?
|
||||
|
||||
During this assignment, something that took the most time and effort was
|
||||
the implementation of a controller for our custom resources. This isn't
|
||||
very hard if you go by the rules and do the things according to the
|
||||
well-defined documents and blogs since this is a standard step in the
|
||||
implementation of any custom resource controller. But did we follow the
|
||||
rules? Hell no! But this time, let us go step-by-step.
|
||||
|
||||
1. The first step is to define a `CustomResourceDefinition` for our custom
|
||||
resource. Let us define a CRD called `spacetime`. To do this you can write a
|
||||
YAML file like below.
|
||||
|
||||
```yaml
|
||||
# file: spacetime-crd.yaml
|
||||
apiVersion: apiextensions.k8s.io/v1
|
||||
kind: CustomResourceDefinition
|
||||
metadata:
|
||||
# name must match the spec fields below, and be in the form: <plural>.<group>
|
||||
name: spacetimes.example.com
|
||||
spec:
|
||||
# group name to use for REST API: /apis/<group>/<version>
|
||||
group: example.com
|
||||
# list of versions supported by this CustomResourceDefinition
|
||||
versions:
|
||||
- name: v1alpha1
|
||||
# Each version can be enabled/disabled by Served flag.
|
||||
served: true
|
||||
# One and only one version must be marked as the storage version.
|
||||
storage: true
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
type: object
|
||||
properties:
|
||||
spec:
|
||||
type: object
|
||||
properties:
|
||||
message:
|
||||
type: string
|
||||
# either Namespaced or Cluster
|
||||
scope: Namespaced
|
||||
names:
|
||||
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
|
||||
plural: spacetimes
|
||||
# singular name to be used as an alias on the CLI and for display
|
||||
singular: spacetime
|
||||
# kind is normally the CamelCased singular type. Your resource manifests use this.
|
||||
kind: SpaceTime
|
||||
# shortNames allow shorter string to match your resource on the CLI
|
||||
shortNames:
|
||||
- st
|
||||
```
|
||||
|
||||
You can learn more about the fields and options
|
||||
[here](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
The CRD that we defined above corresponds to the `CustomResource` given
|
||||
below. Once you apply the above file you will be able to see the
|
||||
`spacetime` custom resource on your Kubernetes/OpenShift cluster.
|
||||
|
||||
```yaml
|
||||
# file: spacetime-cr.yaml
|
||||
apiVersion: spacetimes.example.com/v1alpha1
|
||||
kind: SpaceTime
|
||||
metadata:
|
||||
name: spacetime-cr
|
||||
spec:
|
||||
message: "Hello from space!"
|
||||
```
|
||||
|
||||
Apply them using the following commands:
|
||||
|
||||
```bash
|
||||
kubectl apply -f spacetime-crd.yaml
|
||||
kubectl apply -f spacetime-cr.yaml
|
||||
```
|
||||
|
||||
1. Once we have defined our custom resources, we need to define the
|
||||
types that will correspond to this custom resource definition. This
|
||||
can be done using `k8s.io/apimachinery/pkg/apis/meta/v1` package
|
||||
written in golang. Did I tell you that this is all in golang? Well,
|
||||
now you know. Create a package structure for a golang project and
|
||||
add the definition of the type as given below.
|
||||
|
||||
```bash
|
||||
mkdir -p pkg/api/spacetime/v1alpha1
|
||||
touch pkg/api/spacetime/v1alpha1/{spacetime_types,register,doc}.go pkg/api/spacetime/register.go
|
||||
```
|
||||
|
||||
Add the following content to the corresponding files.
|
||||
|
||||
```go
|
||||
// file: /pkg/api/spacetime/v1alpha1/spacetime_types.go
|
||||
package v1alpha1
|
||||
|
||||
import (
|
||||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
|
||||
)
|
||||
|
||||
type SpaceTime struct {
|
||||
metav1.TypeMeta `json:",inline"`
|
||||
metav1.ObjectMeta `json:"metadata,omitempty"`
|
||||
|
||||
Spec SpaceTimeSpec `json:"spec"`
|
||||
}
|
||||
|
||||
type SpaceTimeSpec struct {
|
||||
Message string `json:"message"`
|
||||
}
|
||||
|
||||
type SpaceTimeList struct {
|
||||
metav1.TypeMeta `json:",inline"`
|
||||
metav1.ListMeta `json:"metadata"`
|
||||
|
||||
Items []SpaceTime `json:"items"`
|
||||
}
|
||||
```
|
||||
|
||||
### Attribution
|
||||
|
||||
- Photo by [Luca Bravo](https://unsplash.com/@lucabravo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/XJXWbfSo2f0?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).
|
||||
|
||||
@@ -0,0 +1,212 @@
|
||||
---
|
||||
category: development
|
||||
date: 2021-02-02T21:47:00
|
||||
description: If you use WakaTime to track your coding activity. You can add that to
|
||||
your README as a bar graph or embed it in your blog/portfolio. Just add this action
|
||||
to any of your repositories and there you have it.
|
||||
image: /images/waka.webp
|
||||
tags:
|
||||
- wakatime
|
||||
- github-action
|
||||
- coding
|
||||
title: How I implemented WakaTime embeddable Coding Graph GHA?
|
||||
---
|
||||
|
||||
If you use WakaTime to track your coding activity. You can add that to
|
||||
your README as a bar graph or embed it in your blog/portfolio. Just add this
|
||||
action to any of your repositories and there you have it.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
This GitHub Action is divided into three parts. I didn't want to use
|
||||
Docker but it seems it doesn't work well without it. Let dive a little
|
||||
into technical details. Three parts are as below.
|
||||
|
||||
1. [main.py](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py)
|
||||
python script. This script contains many procedures.
|
||||
|
||||
- [Getting JSON data file via WakaTime
|
||||
API](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py#L52)
|
||||
|
||||
```python
|
||||
def get_stats() -> list:
|
||||
...
|
||||
return data_list
|
||||
```
|
||||
|
||||
This function parses the JSON file received and scraps out the useful
|
||||
data as a list of lists. Data scraped are language list, time spent on
|
||||
each language, percentage of the time, start date, and end date. For
|
||||
this action, I have limited the number of languages to 5 however it
|
||||
should be very easy to increase that number.
|
||||
|
||||
- [Setting the
|
||||
Timeline](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py#L13)
|
||||
|
||||
```python
|
||||
def this_week(dates: list) -> str:
|
||||
...
|
||||
return f"Coding Activity During: {week_start.strftime('%d %B, %Y')} to {week_end.strftime('%d %B, %Y')}"
|
||||
```
|
||||
|
||||
The start date and end date scraped in the last function are used here
|
||||
to set the timeline. Because date in JSON is provided in UTC as below
|
||||
:
|
||||
|
||||
```json
|
||||
date: "YYYY-MM-DDTHH:MM:SSZ"
|
||||
```
|
||||
|
||||
I striped it to simple dates only. We can set them manually by taking
|
||||
the current time from the system. But that method is flawed. But this
|
||||
method ensures that JSON was received latest and the request was
|
||||
successful. Any anomaly will point to a failure in request.
|
||||
|
||||
- [Creating a bar
|
||||
graph](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py#L21)
|
||||
|
||||
```python
|
||||
def make_graph(data: list):
|
||||
...
|
||||
savefig(...)
|
||||
```
|
||||
|
||||
Lastly, it is time to generate the graph and save them as an image.
|
||||
This function uses the data scraped in the first step. Creating a bar
|
||||
graph using matplotlib is easy.
|
||||
Decorating was a bit difficult. I wanted this graph to merge with
|
||||
GitHub's look so I chose to color the bar as GitHub colors the
|
||||
languages. That data is stored as colors.json. Many of the languages have
|
||||
slightly different spelling in GitHub as compared to WakaTime. So some
|
||||
languages are shown in default color. That can be improved if we
|
||||
notice that language and change its color manually. Lastly, the graph
|
||||
is saved both as SVG and PNG. SVGs are better to put on a responsive
|
||||
page.
|
||||
|
||||
2. [entrypoint.py](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/entrypoint.sh)
|
||||
shell script. This shell script clones the repository copies the
|
||||
image and pushes changes to the master. There were several problems.
|
||||
First of all authentication. This was solved by using a remote
|
||||
repository address using GitHub Token. And it seems that GitHub
|
||||
doesn't allow to commit without a username and email. So I used
|
||||
**github-actions** bot email.
|
||||
|
||||
```bash
|
||||
remote_repo-"https://${GITHUB_ACTOR}:${INPUT_GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git"
|
||||
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
|
||||
git config user.name "GitHub Actions"
|
||||
```
|
||||
|
||||
`41898282` is the id assigned to the github-actions bot. Don't ask
|
||||
where I found them 🙂.
|
||||
|
||||
Another problem was to separate repository name from combined
|
||||
*username/repository-name* provided by `${GITHUB_REPOSITORY}`. GitHub doesn't
|
||||
provides a direct way to get just the repo name. We used *Internal
|
||||
Field Separator*. It returns an array and works similar to `split()`
|
||||
command in Python and Java.
|
||||
|
||||
```bash
|
||||
# '/' is the seperator
|
||||
IFS-'/' read -ra reponame <<< "${GITHUB_REPOSITORY}"
|
||||
# returned {username, repository}
|
||||
repository-"${reponame[1]}"
|
||||
```
|
||||
|
||||
After that, all other commands are pretty straight. Commit the added
|
||||
files and push them.
|
||||
|
||||
3. [Dockerfile](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/Dockerfile)
|
||||
**IMPORTANT** It took a lot of time to reach this state 🥱. This is
|
||||
where all the magic happens. I am running <span
|
||||
class="title-ref">ubuntu:latest</span> inside the container. I first
|
||||
update the distribution. Then install the required python packages.
|
||||
Lastly, I invoke the python script and shell script.
|
||||
|
||||
There was an almost impossible problem, I searched hundreds of posts
|
||||
that *how can I access the generated files inside Docker container*, but
|
||||
no luck. But at last, I found a workaround(obviously otherwise you
|
||||
wouldn't be reading this by now 🤣) each command is run in a separate
|
||||
virtual sub-container. As the command ends its output is also lost but
|
||||
not when you club multiple commands together. At least not until every
|
||||
command is finished. The generated files are available to the next
|
||||
clubbed process. I did that by combining the python script run and shell
|
||||
script run.
|
||||
|
||||
```dockerfile
|
||||
CMD python3 /main.py && /entrypoint.sh
|
||||
```
|
||||
|
||||
This part is the smallest yet took the most time and tries while
|
||||
developing this action.
|
||||
|
||||
## How to use this GitHub Actions?
|
||||
|
||||
1. First get your WakaTime API Key. You can get it from your
|
||||
[WakaTime](<https://wakatime.com>) account settings.
|
||||
|
||||
2. Save WakaTime API Key to Repository Secret. Find that by clicking
|
||||
the Settings tab. Keep the name of the secret as
|
||||
**WAKATIME_API_KEY**.
|
||||
|
||||
3. Add the following line in your README.md of your repo.
|
||||
|
||||
```html
|
||||
<img src="https://github.com/<username>/<repository-name>/blob/<branch-name>/images/stat.svg" alt="Alternative Text"/>
|
||||
Example: <img src="https://github.com/avinal/avinal/blob/main/images/stat.svg" alt="Avinal WakaTime Activity"/>
|
||||
```
|
||||
|
||||
> You can use this method to embed in web pages too. **Do not use the
|
||||
> markdown method of inserting images. It does not work sometimes.**
|
||||
|
||||
4. Click the **Action** tab and **choose to set up a workflow
|
||||
yourself**.
|
||||
|
||||
5. Copy the following code into the opened file, you can search for
|
||||
**WakaTime Stat** in the marketplace tab for assistance.
|
||||
|
||||
```yaml
|
||||
name: WakaTime status update
|
||||
|
||||
on:
|
||||
schedule:
|
||||
# Runs at 12 am '0 0 * * *' UTC
|
||||
- cron: "1 0 * * *"
|
||||
|
||||
jobs:
|
||||
update-readme:
|
||||
name: Update the WakaTime Stat
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
# Use avinal/Profile-Readme-WakaTime@<latest-release-tag> for latest stable release
|
||||
# Do not change the line below except the word master with tag number maybe
|
||||
# If you have forked this project you can use <username>/Profile-Readme-WakaTime@master instead
|
||||
- uses: avinal/Profile-Readme-WakaTime@master
|
||||
with:
|
||||
# WakaTime API key stored in secrets, do not directly paste it here
|
||||
WAKATIME_API_KEY: ${{ secrets.WAKATIME_API_KEY }}
|
||||
# Automatic github token
|
||||
GITHUB_TOKEN: ${{ github.token }}
|
||||
# Branch - newer GitHub repositories have "main" as default branch, change to main in that case, default is master
|
||||
BRANCH: "master"
|
||||
# Manual Commit messages - write your own messages here
|
||||
COMMIT_MSG: "Automated Coding Activity Update :alien:"
|
||||
```
|
||||
|
||||
6. Please wait till 12 AM UTC to run this workflow automatically. Or
|
||||
you can force run it by going to the Actions tab. Or you can add the
|
||||
following lines under `on:` to run with
|
||||
every push. Search for 12 AM UTC to find the equivalent time in your
|
||||
time zone.
|
||||
|
||||
```yaml
|
||||
on:
|
||||
push:
|
||||
branches: [ master ]
|
||||
schedule:
|
||||
- cron: '1 0 * * *'
|
||||
```
|
||||
|
||||
## My Coding Activity
|
||||
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
category: development
|
||||
date: 2020-12-31T19:07:00
|
||||
description: It is real pain when you have small SSD and Windows Subsystem for Linux
|
||||
(WSL) is growing exponentially in size. There is no easy way to move the WSL installation
|
||||
to another drive. Here in this blog I will discuss how to tackle this problem with
|
||||
bite size steps.
|
||||
image: /images/windows-wsl2.webp
|
||||
tags:
|
||||
- wsl
|
||||
- wsl2
|
||||
title: Move WSL 2 Safely to another Drive
|
||||
---
|
||||
|
||||
It is real pain when you have small SSD and Windows Subsystem for Linux
|
||||
(WSL) is growing exponentially in size. There is no easy way to move the
|
||||
WSL installation to another drive. Here in this blog I will discuss how
|
||||
to tackle this problem with bite size steps.
|
||||
|
||||
1. Open a PowerShell or Command Prompt with *Admin* access. For this you can
|
||||
use WinKey + X shortcut and select **Windows PowerShell(Admin)**.
|
||||
2. Check if the WSL 2 installation you are planning to move is is
|
||||
currently running/stopped.
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> wsl -l -v
|
||||
PS C:\\Users\\Avinal>
|
||||
NAME STATE VERSION
|
||||
* Ubuntu Running 2
|
||||
Kali Stopped 2
|
||||
```
|
||||
|
||||
3. If its running then you must stop the particular WSL distribution.
|
||||
(*Ubuntu* used as example)
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> wsl -t Ubuntu
|
||||
```
|
||||
|
||||
4. Export to some folder. (Here exporting *Ubuntu* as *ubuntu-ex.tar*
|
||||
to *Z:wsl2*)
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> wsl --export Ubuntu "Z:\\export\\ubuntu-ex.tar"
|
||||
```
|
||||
|
||||
5. Unregister previous WSL installation
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> wsl --unregister Ubuntu
|
||||
```
|
||||
|
||||
6. Create a new folder and import your WSL installation to that folder.
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> New-Item -Path "Z:\\wsl2" -ItemType Directory
|
||||
|
||||
Directory: Z:\\
|
||||
|
||||
Mode LastWriteTime Length Name
|
||||
---- ------------- ------ ----
|
||||
d----- 31-12-2020 21:03 wsl2
|
||||
|
||||
PS C:\\Users\\Avinal> wsl --import Ubuntu "Z:\\wsl2" "Z:\\export\\ubuntu-ex.tar"
|
||||
```
|
||||
|
||||
7. Check after import is complete
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> wsl -l -v
|
||||
PS C:\\Users\\Avinal>
|
||||
NAME STATE VERSION
|
||||
* Ubuntu Running 2
|
||||
Kali Stopped 2
|
||||
```
|
||||
|
||||
8. Mark one of your WSL distribution as *(default)*.
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> wsl -s Ubuntu
|
||||
```
|
||||
|
||||
9. After exporting your default user will be set as
|
||||
<i style="color:red">root</i> , to change it to your desired
|
||||
username, run following command
|
||||
|
||||
```powershell
|
||||
PS C:\\Users\\Avinal> ubuntu config --default-user user_name
|
||||
```
|
||||
|
||||
10. Finally run `wsl` and you have successfully moved your WSL 2
|
||||
installation to another drive.
|
||||
|
||||
## Attribution
|
||||
|
||||
- [Image](https://www.atwix.com/magento/magento-2-with-docker-for-windows-and-wsl-2/)
|
||||
@@ -0,0 +1,832 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-08-19T23:07:00
|
||||
description: This is the final report of my Google Summer of Code 2021 at The FOSSology
|
||||
Project.
|
||||
image: /images/gsoc-wall.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: GSoC'21 Final Evaluation Report
|
||||
---
|
||||
|
||||
This is the final report of my Google Summer of Code 2021 at The FOSSology Project.
|
||||
|
||||
<style>
|
||||
.rd {color:red;font-weight:bold}
|
||||
.gr{color:green;font-weight:bold}
|
||||
.or{color:orange;font-weight:medium}
|
||||
ul{margin-bottom:0}
|
||||
</style>
|
||||
|
||||
## The CMake Build system
|
||||
|
||||
FOSSology is quite an old and mature project. The project has been using
|
||||
bare metal **Makefiles**. As the project is growing with new agents and
|
||||
modernization it was required to have a modern build system.
|
||||
|
||||
The FOSSology is a suite of well-integrated and synchronized
|
||||
sub-projects (called agents) written in C, C++, and PHP. Most of the
|
||||
major agents are in C, C++ and that made CMake an obvious choice for a
|
||||
new build system for FOSSology. CMake is a versatile set of build, test,
|
||||
and packaging tools and is the most popular choice of C/C++ developers.
|
||||
CMake can be extended to create a build system for other languages too
|
||||
via custom scripts.
|
||||
|
||||
## GitHub Actions CI/CD
|
||||
|
||||
Since the FOSSology project moved on Github, it has used only the free
|
||||
Travis CI service for OSS projects. At the time of writing Travis CI has
|
||||
reduced its free tier CI services. GitHub Actions provides faster
|
||||
builds. Since GitHub Actions is a fully managed service by GitHub, we
|
||||
don't need to know how to scale and operate the infrastructure to run
|
||||
it.
|
||||
|
||||
|
||||
It is straightforward to use with GitHub because when we fork a
|
||||
repository, the actions automatically get forked. This allows you to
|
||||
test and build projects very efficiently and even run them closer to the
|
||||
developer. Also, you have readily available access to the GitHub API,
|
||||
making it more popular among developers.
|
||||
|
||||
## Improvements over previous build system and CI
|
||||
|
||||
The new build system and CI brings a lot of improvements and features.
|
||||
The list below describes them.
|
||||
|
||||
- CMake enforces out-of-source builds. This was already possible with
|
||||
the previous build system but not a strict requirement. This feature
|
||||
keeps the source code clean and makes cleaning the build artifacts
|
||||
easy. (Just remove the build folder :)
|
||||
- One of the major improvements over the previous build system is faster
|
||||
build times. CMake generates parallel build-enabled configurations for
|
||||
all generators. In our tests, the new build system is at least twice
|
||||
as fast as the previous one. With further improvement in
|
||||
configuration, we will be able to further cut the build times.
|
||||
- Previously FOSSology can only be built using *Unix Makefiles*. With
|
||||
CMake, we can now use many other popular generators such as *Ninja*.
|
||||
- Now it is also very flexible to choose different compilers. This will
|
||||
help support more platforms and architecture in the future. As of now,
|
||||
we are experimenting with Clang compilers.
|
||||
- FOSSology is quite an old project and a lot of agent testing code was
|
||||
written in the last decade. Initially, none of them were compatible
|
||||
with the new build system, but we were able to hack most of the test
|
||||
code using better-improved methods. Test times have also improved.
|
||||
- Migrating from Travis CI to GitHub Actions was another big move and
|
||||
for the most part, it removes the dependency on a third-party CI
|
||||
service. Along with that GitHub Actions provides better build times,
|
||||
tons of new features, and better integration with other GitHub
|
||||
services.
|
||||
|
||||
## Deliverables
|
||||
|
||||
- Final Pull Request [#2075](https://github.com/fossology/fossology/pull/2075)
|
||||
- Pull Request Branch [avinal/feat/buildsystem](https://github.com/avinal/fossology/tree/avinal/feat/buildsystem)
|
||||
- Working Branch (individual commits)
|
||||
- [avinal/feat/cmake-buildsystem](https://github.com/avinal/fossology/tree/avinal/feat/cmake-buildsystem)
|
||||
- [avinal/feat/testing](https://github.com/avinal/fossology/tree/avinal/feat/testing)
|
||||
- Project Issue [#1913](https://github.com/fossology/fossology/issues/1913)
|
||||
- Project Discussion [#1931](https://github.com/fossology/fossology/discussions/1931)
|
||||
- Weekly Reports
|
||||
- [Personal Blog](https://gsoc.avinal.space)
|
||||
- [FOSSology Official Blog](https://fossology.github.io/gsoc/docs/2021/buildsystem/)
|
||||
|
||||
### CMake Build System Tasks
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="width: 7%" />
|
||||
<col style="width: 23%" />
|
||||
<col style="width: 15%" />
|
||||
<col style="width: 15%" />
|
||||
<col style="width: 30%" />
|
||||
<col style="width: 23%" />
|
||||
<col style="width: 38%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th>#</th>
|
||||
<th>Agents</th>
|
||||
<th>Build</th>
|
||||
<th>Install</th>
|
||||
<th>Testing</th>
|
||||
<th>Packaging</th>
|
||||
<th>Remarks</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td>1</td>
|
||||
<td>adj2nest</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>2</td>
|
||||
<td>buckets</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><blockquote>
|
||||
<p><span class="gr">YES</span></p>
|
||||
</blockquote></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>3</td>
|
||||
<td>cli</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="rd">Functional</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>4</td>
|
||||
<td>copyright</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>5</td>
|
||||
<td>debug</td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>6</td>
|
||||
<td>decider</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>7</td>
|
||||
<td>deciderjob</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>8</td>
|
||||
<td>delagent</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="rd">Functional</span></li>
|
||||
<li><span class="rd">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>9</td>
|
||||
<td>demomod</td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="or">Functional</span></li>
|
||||
<li><span class="or">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="or">NO</span></td>
|
||||
<td><em>(Not Used)</em></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>10</td>
|
||||
<td>example_wc_agent</td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="or">Functional</span></li>
|
||||
<li><span class="or">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><blockquote>
|
||||
<p><span class="or">NO</span></p>
|
||||
</blockquote></td>
|
||||
<td><em>(Not Used)</em></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>11</td>
|
||||
<td>clib</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>12</td>
|
||||
<td>cpplib</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>13</td>
|
||||
<td>phplib</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td>1 functional test needs fix</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>14</td>
|
||||
<td>maintagent</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>15</td>
|
||||
<td>mimetype</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>16</td>
|
||||
<td>monk</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>17</td>
|
||||
<td>ninka</td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="or">Functional</span></li>
|
||||
<li><span class="or">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="or">NO</span></td>
|
||||
<td><em>(Deprecated)</em></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>18</td>
|
||||
<td>nomos</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>19</td>
|
||||
<td>ojo</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td>1 functional test needs fix</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>20</td>
|
||||
<td>pkgagent</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>21</td>
|
||||
<td>readmeoss</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>22</td>
|
||||
<td>regexscan</td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td><span class="or">YES</span></td>
|
||||
<td></td>
|
||||
<td><blockquote>
|
||||
<p><span class="or">NO</span></p>
|
||||
</blockquote></td>
|
||||
<td><em>(Deprecated)</em></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>23</td>
|
||||
<td>reportImport</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>24</td>
|
||||
<td>reuser</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>25</td>
|
||||
<td>reso</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>26</td>
|
||||
<td>scheduler</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="rd">Functional</span></li>
|
||||
<li><span class="rd">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td>Tests needs fix</td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>27</td>
|
||||
<td>softwareHeritage</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>28</td>
|
||||
<td>spasht</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>29</td>
|
||||
<td>spdx2</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td>1 Test failing in CI</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>30</td>
|
||||
<td>unifiedreport</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>31</td>
|
||||
<td>ununpack</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="rd">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td>Unit tests needs fix</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>32</td>
|
||||
<td>wget_agent</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="gr">Functional</span></li>
|
||||
<li><span class="gr">Unit</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td>32</td>
|
||||
<td>www</td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td><ul>
|
||||
<li><span class="rd">UI</span></li>
|
||||
</ul></td>
|
||||
<td><span class="gr">YES</span></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### GitHub Actions CI Tasks
|
||||
|
||||
| # | CI Tasks | Status |
|
||||
|-----|-----------------------------------------|----------------------------------------------------------|
|
||||
| 1 | <span class="gr">build</span> | Added Ubuntu 20.04 GCC 8, 9 and Clang, GCC 7 not working |
|
||||
| 2 | <span class="gr">c/cpp unit test</span> | Added, delagent, scheduler and ununpack not working |
|
||||
| 3 | <span class="gr">phpunit tests</span> | Added, delagent and scheduler functional not working |
|
||||
| 4 | <span class="rd">cahching</span> | Not implemented |
|
||||
| 5 | <span class="rd">source install</span> | Not implemented |
|
||||
|
||||
(<span class="gr">GREEN</span>: COMPLETED, <span class="rd">RED</span>:
|
||||
INCOMPLETE, <span class="or">ORANGE</span>: NOT NEEDED/DEPRECATED)
|
||||
|
||||
## How does it work and how to use it?
|
||||
|
||||
The new build system retains the modular and hierarchical structure of
|
||||
the previous build system. On the other hand, the new build system
|
||||
provides several new flags to control the build. The new build system
|
||||
forces out-of-source build instead of the previous in-source builds.
|
||||
This keeps the source clutter-free and reduces the chance of
|
||||
accidentally deleting source files. *Testing still needs some in-source
|
||||
artifacts, this will be solved once all the tests are fixed according to
|
||||
the new build system.*
|
||||
|
||||
Each agent is a complete CMake sub-project with its independent
|
||||
configuration for building, installing, and testing. That means a single
|
||||
agent can be built and installed separately and even removed from the
|
||||
default build without breaking other builds. The directory structure is
|
||||
as below.
|
||||
|
||||
```bash
|
||||
.
|
||||
├── build # temporary directory for build artifacts
|
||||
├── cmake # CMake modules for FOSSology
|
||||
│ ├── FoPackaging.cmake # CMake Packaging configurations
|
||||
│ ├── FoUtilities.cmake # Custom CMake utilities
|
||||
│ ├── FoVersionFile.cmake # VERSION version.php CMake template file
|
||||
│ ├── SetDefaults.cmake # CMake defaults for this project
|
||||
│ ├── TestInstall.make.in # Template makefile for install during tests
|
||||
│ └── VERSION.in # VERSION file template
|
||||
├── src
|
||||
│ ├── agent-1 # Agent sub-project
|
||||
│ │ ├── agent # Agent's source code directory
|
||||
│ │ │ ├── agent-source-code
|
||||
│ │ │ └── CMakeLists.txt
|
||||
│ │ ├── agent_tests # Agent's test directory
|
||||
│ │ │ ├── Unit
|
||||
│ │ │ ├── Functional
|
||||
│ │ │ └── CMakeLists.txt
|
||||
│ │ ├── ui # Agent's UI source code
|
||||
│ │ │ ├── templates
|
||||
│ │ │ └── agent-ui-code
|
||||
│ │ └── CMakeLists.txt # Agent's top-level CMake configuration
|
||||
: :
|
||||
│ ├── other agents
|
||||
: :
|
||||
│ └── CMakeLists.txt # Source intermediate CMake configuration
|
||||
:
|
||||
├── other directories and files
|
||||
:
|
||||
└── CMakeLists.txt # FOSSology Top-level CMake configuration
|
||||
```
|
||||
|
||||
The `cmake` directory contains customized CMake modules and templates
|
||||
for FOSSology. This directory is required for all the operations. The
|
||||
general workflow of the new build system as well as how to use it is
|
||||
described below.
|
||||
|
||||
1. Since the new build system is still in review. You must fork
|
||||
FOSSology and pull the
|
||||
[#2075](https://github.com/fossology/fossology/pull/2075) pull
|
||||
request branch. Once you are in FOSSology root, run these commands.
|
||||
|
||||
```bash
|
||||
git fetch https://github.com/avinal/fossology avinal/feat/buildsystem:buildsystem
|
||||
git checkout buildsystem
|
||||
```
|
||||
|
||||
2. The first step towards building is to create a temporary directory
|
||||
for storing intermediate files and build artifacts. By convention we
|
||||
use a directory named `build`, but you can use any name. (**NOTE:
|
||||
For testing do not use other names**)
|
||||
|
||||
```bash
|
||||
mkdir build
|
||||
cd build
|
||||
```
|
||||
|
||||
3. In the next steps, we will configure the CMake project and generate
|
||||
the required configurations. You can use several flags to control
|
||||
the build. Given below are the flags available for this project.
|
||||
|
||||
<table style="width:99%;">
|
||||
<colgroup>
|
||||
<col style="width: 34%" />
|
||||
<col style="width: 43%" />
|
||||
<col style="width: 20%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th>CMake Flags</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td><strong>-DCMAKE_INSTALL_PREFIX=<path></strong></td>
|
||||
<td>Sets the install prefix.</td>
|
||||
<td><code>/usr/local</code></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td><strong>-DAGENTS="agent1;agent2..."</strong></td>
|
||||
<td>Only configure these agents.</td>
|
||||
<td>ALL AGENTS</td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td><strong>-DOFFLINE=<ON/OFF></strong></td>
|
||||
<td>Controls vendor generation, ON=NO</td>
|
||||
<td><strong>OFF</strong></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td><p><strong>-DCMAKE_BUILD_TYPE=<type></strong></p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>Controls build type aka level optimisation</li>
|
||||
</ul>
|
||||
</blockquote></td>
|
||||
<td><ul>
|
||||
<li><code>Debug</code></li>
|
||||
<li><code>Release</code></li>
|
||||
<li><code>RelWithDebInfo</code></li>
|
||||
<li><code>MinSizeRel</code></li>
|
||||
</ul></td>
|
||||
<td><code>Debug</code></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td><strong>-DTESTING=<ON/OFF></strong></td>
|
||||
<td>Controls testing config generation</td>
|
||||
<td><blockquote>
|
||||
<p><strong>OFF</strong></p>
|
||||
</blockquote></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td><strong>-DMONOPACK=<ON/OFF></strong></td>
|
||||
<td>Package adj2nest and ununpack seperately</td>
|
||||
<td><strong>OFF</strong></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td><strong>-GNinja</strong></td>
|
||||
<td>Use Ninja instead of Unix Makefiles</td>
|
||||
<td><em>Unix MakeFiles</em></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
There are lots of inbuilt CMake command-line options you can see
|
||||
them in the official
|
||||
[documentation](https://cmake.org/cmake/help/v3.10/manual/cmake.1.html).
|
||||
Once you have chosen your flags we can now configure the project
|
||||
using the following commands.
|
||||
|
||||
```bash
|
||||
# From build folder
|
||||
cd <name-of-build-directory>
|
||||
cmake <flags> ..
|
||||
```
|
||||
|
||||
4. The next step is to build the project. You can use parallel jobs to
|
||||
build faster. For more options you can type `cmake --help` or
|
||||
`make --help` or `ninja --help`.
|
||||
|
||||
```bash
|
||||
# Common build command for all generators,
|
||||
# Default number of parallel builds depends on generator used
|
||||
cmake --build . --parallel <no-of-processes>
|
||||
|
||||
# For Unix Makefiles, no parallel build by default
|
||||
make -j <no-of-processes>
|
||||
|
||||
# For Ninja, 8+ parallel build by default (depends on system)
|
||||
ninja -j <no-of-processes>
|
||||
```
|
||||
|
||||
5. Installing is also as easy as building. You can choose to install
|
||||
only certain components even if you have built the whole project. If
|
||||
you directly invoke the install command without building the
|
||||
project, it will automatically build the project first.
|
||||
|
||||
```bash
|
||||
# For Unix Makefiles
|
||||
make install
|
||||
|
||||
# For Ninja
|
||||
ninja install
|
||||
```
|
||||
|
||||
6. While testing has some issues, most of the testing is working fine.
|
||||
For now, you must build and run any test from the FOSSology root
|
||||
directory only. You can choose to configure a single agent if you
|
||||
want to test one agent only. See `ctest --help` for controlling test
|
||||
runs.
|
||||
|
||||
```bash
|
||||
# Common testing command
|
||||
ctest --parallel <no-of-processes>
|
||||
|
||||
# For Unix Makefiles
|
||||
make test
|
||||
|
||||
# For Ninja
|
||||
ninja test
|
||||
```
|
||||
|
||||
7. You can package FOSSology, the packaging currently lacks copyright
|
||||
and conf files. But for testing purposes, you can use the following
|
||||
commands. Similar to installing, if you run the package command
|
||||
without building the project, it will automatically build the
|
||||
project first. See `cpack --help` for more packaging options.
|
||||
|
||||
```bash
|
||||
# Common testing command
|
||||
cpack
|
||||
|
||||
# For Unix Makefiles
|
||||
make package
|
||||
|
||||
# For Ninja
|
||||
ninja package
|
||||
```
|
||||
|
||||
## Known Issues and Drawbacks
|
||||
|
||||
Although the transition from Makefiles to CMake and Travis CI to GitHub
|
||||
Actions is almost complete and working as expected. But it is not free
|
||||
of drawbacks and issues. This section outlines the known issues at the
|
||||
time of writing.
|
||||
|
||||
|
||||
|
||||
- Coverage builds may fail with linking errors.
|
||||
- Packaging prefix is the same as the install prefix. This requires the
|
||||
developer to set the install prefix manually before packaging to
|
||||
produce packages with the correct directory structure.
|
||||
- Testing and packaging must be used from the FOSSology root directory.
|
||||
Not doing so may or may not configure the project as intended.
|
||||
- Previously tests were written hardcoded for the Makefiles. But new
|
||||
build system requires all artifacts to be generated in a separate
|
||||
directory. This required me to add symbolic links wherever a generated
|
||||
script or file is expected. Tests can still leave some artifacts
|
||||
inside source folders.
|
||||
- There is no easy way to install a particular agent from the FOSSology
|
||||
root directory.
|
||||
- Packages don't contain copyright, readme, and license files. CMake
|
||||
doesn't provide a way to include these files. This is being tracked by
|
||||
issue
|
||||
[#21832](https://gitlab.kitware.com/cmake/cmake/-/issues/21832).
|
||||
- While packaging the symbolic links may or may not be dereferenced and
|
||||
hence results in copying the folder too in the target directory.
|
||||
- Running tests locally may require switching to `fossy` user.
|
||||
- While configured for testing, it may give permission errors.
|
||||
- Scheduler, Ununpack, and Delagent unit and functional tests are not
|
||||
working. I have added an issue
|
||||
[#2084](https://github.com/fossology/fossology/issues/2084) to track
|
||||
the progress on fixing these tests.
|
||||
- CMake doesn't generate uninstall targets. The closest thing to
|
||||
uninstall is [this snippet](https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake).
|
||||
This will be later added to the FOSSology.
|
||||
|
||||
## Challenges Faced
|
||||
|
||||
While this whole project was challenging, some aspects of it were
|
||||
unforeseen and more challenging. When I decided to go on with this
|
||||
project I just had enough CMake knowledge to write a configuration for a
|
||||
very small project. I had never used CMake on this big scale. On the
|
||||
other side, the FOSSology community is largely unknown to CMake so for
|
||||
all of us it was learned, practiced, and implement. With support from
|
||||
mentors, I was able to overcome this challenge with flying colors.
|
||||
|
||||
The other challenge was to understand the old build system, how they are
|
||||
all connected and what is the flow. The complexity can be imagined by
|
||||
the fact that the most of code and configurations were written in the
|
||||
decade before the last decade and haven't changed much since then.
|
||||
|
||||
The most challenging task was to make tests work with the new build
|
||||
system. Since tests were mostly hardcoded and the new build system
|
||||
refactored many of the files and directory, the tests were failing
|
||||
initially. The testing part took me the most time. All thanks to my
|
||||
mentor Gaurav, I was able to hack them to suit the
|
||||
new build system.
|
||||
|
||||
## Related Resources and Links
|
||||
|
||||
- Fix FOSSology agent tests issue
|
||||
[#2084](https://github.com/fossology/fossology/issues/2084)
|
||||
- feat(CI): Migrate API docs generation and deployment to GitHub Actions
|
||||
pull request
|
||||
[#1917](https://github.com/fossology/fossology/pull/1917)
|
||||
- feat(CI): Migrate Static Checks and Analysis to GitHub Actions from
|
||||
Travis CI [#1919](https://github.com/fossology/fossology/pull/1919)
|
||||
|
||||
## Future Development Plans
|
||||
|
||||
There is a lot to do with the new build system and CI and it will
|
||||
probably take a year or to reach a maturity point. I was able to meet
|
||||
most of the goals but some of them are remaining.
|
||||
|
||||
- Fix the tests, probably renovate them from the ground up.
|
||||
- Find a hack for packaging problems.
|
||||
- Improve and optimize the build.
|
||||
- Modernise the source code, remove old, bloated code and replace them
|
||||
according to new standards.
|
||||
|
||||
## What did I learn from this project?
|
||||
|
||||
This Google Summer of Code was the busiest time of my life for all good
|
||||
reasons. I learned a lot about license compliance and how it all works
|
||||
in the software industry. The next big thing is CMake. As I mentioned I
|
||||
was just a novice user of CMake. Now I am confident that given any other
|
||||
large project I will be able to migrate it/improve it. I got to learn
|
||||
PHP, of which I did not know a single word before GSoC. And finally, I
|
||||
learned about packing and testing. I had these courses but implementing
|
||||
them myself and fixing them was a wholesome experience.
|
||||
|
||||
Other than that I improved on my communication and presentation skills.
|
||||
Collaborating with fellow participants was one of the great things that
|
||||
happened during GSoC.
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
Google Summer of Code is the best thing that has happened to me this
|
||||
year so far. Although there are numerous people to say thanks to, I want
|
||||
to mention key people who were my motivation and support during this
|
||||
period.
|
||||
|
||||
First of all, I want to thank and appreciate my mentors [Gaurav
|
||||
Mishra](https://github.com/GMishx), [Michael C.
|
||||
Jaeger](https://github.com/mcjaeger), [Anupam
|
||||
Ghosh](https://github.com/ag4ums), and [Shaheem Azmal M
|
||||
MD](https://github.com/shaheemazmalmmd). Without the help and support
|
||||
from them, all this would not have been possible. They are very polite,
|
||||
knowledgeable, and helpful.
|
||||
|
||||
Finally, I want to thank, my family and friends. I got to meet many
|
||||
awesome developers as my fellow participants from around the world, I
|
||||
wish we will do more collaboration in the future.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-07-14T12:29:00
|
||||
description: In the first phase of GSoC 2021 @ The FOSSology Project, I have completed
|
||||
the desired milestone. As of now, FOSSology can be installed completely via CMake
|
||||
and most of the components are working fine in initial testing.
|
||||
image: /images/tech-wallpaper.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: GSoC'21 First Evaluation Report
|
||||
---
|
||||
|
||||
In the first phase of GSoC 2021 @ The FOSSology Project, I have
|
||||
completed the desired milestone. As of now, FOSSology can be installed
|
||||
completely via CMake and most of the components are working fine in
|
||||
initial testing.
|
||||
|
||||
## Updates
|
||||
|
||||
In the first phase of GSoC 2021 @ The FOSSology Project, I have
|
||||
completed the desired milestone. As of now, FOSSology can be installed
|
||||
completely via CMake and most of the components are working fine in
|
||||
initial testing.
|
||||
|
||||
List of tasks completed
|
||||
|
||||
- Added CMake build configurations for all the C/C++ agents for
|
||||
executables, libraries, and coverages
|
||||
- Added CMake install configuration for all C/C++ and PHP agents as well
|
||||
as extra components
|
||||
- Reworked the shell scripts and generated source files to make them
|
||||
more compatible with CMake as well as better in terms of overall
|
||||
compatibility with the latest tools.
|
||||
|
||||
## Improvements
|
||||
|
||||
- The new CMake build architecture is much more flexible to changes as
|
||||
compared to hard-coded Makefiles.
|
||||
- CMake generated configurations support parallel build by default, this
|
||||
has led to significant improvement in build time. CMake generated
|
||||
configuration can now build the whole project within 2 mins or even
|
||||
faster on more powerful CPUs (Both Ninja and Makefiles with the same
|
||||
number of parallel processes) compared to 4-5 minutes previously.
|
||||
*(These results are averaged from initial testing of new build
|
||||
architecture)*
|
||||
- CMake supports out-source builds by default, which means the source
|
||||
folders are not touched/modified while building, all build files and
|
||||
residuals get their separate folder and the source tree can be cleaned
|
||||
easily.
|
||||
- Developers can now opt for a long list of generators to build
|
||||
FOSSology e.g Makefiles, Ninja as per their needs.
|
||||
|
||||
## How to test
|
||||
|
||||
Instructions to test the new Build system is in [this](https://github.com/avinal/fossology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now) wiki.
|
||||
|
||||
## Known Issues
|
||||
|
||||
- There may be a permission issue with some generated sources while
|
||||
building. This can be bypassed for now by running
|
||||
`sudo chmod +x <filename>` command.
|
||||
- Coverage builds may fail.
|
||||
|
||||
## Postponed Tasks
|
||||
|
||||
- configuration for tests are skipped for now
|
||||
|
||||
## Work in Progress
|
||||
|
||||
- Currently, I am working on packaging the FOSSology with CMake.
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-05-28T21:00:00
|
||||
description: This meeting is the first of the recurring weekly GSoC project meetings.
|
||||
In this meeting the current status of progress according to the proposal was discussed
|
||||
and some topics related to current build system based on Make and the new build
|
||||
system based on CMake.
|
||||
image: /images/tech-wallpaper-1.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- fossology
|
||||
title: Community Bonding Meeting 0
|
||||
---
|
||||
|
||||
This meeting is the first of the recurring weekly GSoC project meetings. In this meeting the current status of progress according to the proposal was discussed and some topics related to current build system based on Make and the new build system based on CMake.
|
||||
|
||||
## Discussions
|
||||
|
||||
- **The current progress according to schedule**
|
||||
- The blog on CMake is on the way.
|
||||
- I have gone through the Makefiles to get a rough estimate of the
|
||||
work.
|
||||
- Published the GSoC project blog
|
||||
- **How are agents related to each other in terms of compilation?**
|
||||
- Each agent is independently compiled and generally use the source
|
||||
code in `lib` folder. If any agent needs other agent then it uses
|
||||
the library files instead.
|
||||
- **Does every agent have a executable and library?**
|
||||
- Not necessarily, there are agents written in C, C++ and PHP,
|
||||
depending on what is the use the configuration can be different.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- It would be better if I get started by creating CMake configuration
|
||||
for any of the agent.
|
||||
- Fork and create a branch for development and mention the same in blog
|
||||
or wiki.
|
||||
- Add a timeline section in blog or wiki as provided in the project
|
||||
proposal.
|
||||
- Publish the CMake introductory blog.
|
||||
- Prepare a prototype/plan for next week.
|
||||
- Find out the best alternative for handling the global variables.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Anupam Ghosh](https://github.com/ag4ums)
|
||||
- [Ayush Bhardwaj](https://github.com/hastagAB)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-06-04T22:30:00
|
||||
description: In this second meeting points over default Makefiles were discussed.
|
||||
Ninja can be used as an alternative for Makefiles.
|
||||
image: /images/tech-wallpaper-2.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- fossology
|
||||
title: Community Bonding Meeting 1
|
||||
---
|
||||
|
||||
In this second meeting points over default Makefiles were discussed. Ninja can be used as an alternative for Makefiles.
|
||||
|
||||
## Discussions
|
||||
|
||||
- **What is the use of** `Makefile.deps` **and** `Makefile.process`
|
||||
**files?**
|
||||
- `Makefile.deps` consists of many used and unused snippets. These
|
||||
snippets help setup the build and test environment for fossology.
|
||||
Since there are many directories that are hardcoded, special care is
|
||||
required while replacing this file.
|
||||
- `Makefile.process` generates a master variable from list of
|
||||
variables. It assists the script in `Makefile.conf` file. These
|
||||
files together generate a list of variables that can be used
|
||||
throughout the build process.
|
||||
- The build can be made faster using **Ninja** instead of **Make**.
|
||||
- Ninja supports parallel builds by default.
|
||||
- Print the flags used once the CMake configuration is working. That
|
||||
will help us debug the process.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Write a *CMakeLists.txt* for **lib**.
|
||||
- Push the working branch and update the link either on wiki or blog.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Anupam Ghosh](https://github.com/ag4ums)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-08-06T22:47:00
|
||||
description: This week I worked on CMake testing configuration. Most of the time was
|
||||
spent understanding the previous testing architecture.
|
||||
image: /images/tech-wallpaper-11.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 9 Meeting
|
||||
---
|
||||
|
||||
This week I worked on CMake testing configuration. Most of the time was spent understanding the previous testing architecture.
|
||||
|
||||
## Week 9 Progress
|
||||
|
||||
> Initial CMake testing configuration added.
|
||||
>
|
||||
> - Few tests working, e.g copyright, nomos
|
||||
> - Improved packaging configurations
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **Is this a necessity that tests must be run as the fossy user?
|
||||
Because when I run tests as me they as for permissions. But proceeds
|
||||
as the fossy user.**
|
||||
|
||||
- No this is not required and this should not happen. They run under
|
||||
fossy as they sometimes require writing into /srv/fossology. But if
|
||||
they can run under other users that is an enhancement.
|
||||
|
||||
- **I am getting a lot of install issues in C/C++ agent tests?**
|
||||
|
||||
``` bash
|
||||
Start 3: delagent_unit_test
|
||||
|
||||
3: Test command: /home/avinal/Documents/my_git/fossology/build/src/delagent/agent_tests/test_delagent
|
||||
3: Test timeout computed to be: 10000000
|
||||
3: install: cannot stat '/home/avinal/Documents/my_git/fossology/build/src/delagent/agent_tests/..//../../install/defconf/Db.conf': No such file or directory
|
||||
3: install: cannot stat '/home/avinal/Documents/my_git/fossology/build/src/delagent/agent_tests/..//VERSION': No such file or directory
|
||||
3: sh: 1: ../../../testing/db/createTestDB.php: not found
|
||||
3: Failed to run ../../../testing/db/createTestDB.php -c /home/avinal/Documents/my_git/fossologbuild/src/delagent/agent_tests/testconf -e, exit code is:127 .
|
||||
3/8 Test #3: delagent_unit_test ...............***Failed 0.02 sec
|
||||
```
|
||||
|
||||
- Not sure about the reason. I was suspecting Makefile but since they
|
||||
are gone now, I think PHP files are calling some shell commands
|
||||
causing this.
|
||||
|
||||
- **Suggestions/Changes from Gaurav for fixing tests.**
|
||||
|
||||
- For clib-tests, it needs to be called from PHP file (via PHPUnit) as
|
||||
it requires setting up a dummy repo. Check the
|
||||
`src/lib/c/test/Makefile`
|
||||
- For missing services.xml, the test cases include
|
||||
`src/lib/php/common-container.php` which loads the file. It expects
|
||||
it to be in current dir. Can be solved in two ways
|
||||
- Create another common-container.php just for test cases with
|
||||
correct paths.
|
||||
- Edit the current file and take the help of environment variables.
|
||||
For example, if a test variable is exported in env, find the XML
|
||||
relative to it otherwise continue as normal and this variable can
|
||||
be exported by CMake during the test.
|
||||
- Scheduler tests do need `fossology_testconfig` from Makefile.deps
|
||||
which set up the srv and create test configurations, DB, etc.
|
||||
- Another shell script can be written to do all that and call it
|
||||
from CMake. The PHP file called makes everything required in /tmp
|
||||
so not an issue.
|
||||
- The locations like `LOG_DIR, FOSSDB_CONF`, etc. in CMakeLists.txt
|
||||
can be changed to some other values. I am guessing this is the
|
||||
reason you were asked for the fossy password.
|
||||
- File `src/copyright/agent_tests/Functional/cli_test.sh` needs to be
|
||||
edited to take paths relative to build dir. It can also be made into
|
||||
a .in file which is generated from CMake? So every path can easily
|
||||
be updated.
|
||||
- For PHP agents with missing version.php issue, there is a hack
|
||||
possible
|
||||
- Check
|
||||
<https://www.php.net/manual/en/function.set-include-path.php>
|
||||
- Another hack will be to use soft links for version.php in the
|
||||
source.
|
||||
- Other PHP issues like
|
||||
`PHP Fatal error: Uncaught Error: Class 'Fossology\Lib\Agent\Agent' not found`
|
||||
can only be solved by editing composer.json before doing composer
|
||||
install (look for autoload: psr-4 ).
|
||||
- For delagent, pkgagent, mimetype issues, something can be done here:
|
||||
<https://github.com/avinal/fossology/blob/avinal/feat/testing/src/testing/db/c/libfodbreposysconf.c#L349>
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Raise a pull request for all the progress till now.
|
||||
- Refactor the test source code according to suggestions.
|
||||
- Implement remaining testing configurations.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Anupam Ghosh](https://github.com/ag4ums)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-08-14T22:47:00
|
||||
description: This week I implemented CMake testing configuration and fixed most of
|
||||
the tests. As of now all but 5 tests are working fine.
|
||||
image: /images/tech-wallpaper-12.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 10 Meeting
|
||||
---
|
||||
|
||||
This week I implemented CMake testing configuration and fixed most of the tests. As of now all but 5 tests are working fine.
|
||||
|
||||
## Week 9 Progress
|
||||
|
||||
> Testing configuration for all agents added
|
||||
>
|
||||
> - GitHub Actions Configuration added
|
||||
> - Fixed and refactored most of the tests
|
||||
> - Raised a pull request for all the works till now. [#2075](https://github.com/fossology/fossology/pull/2075)
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **I suspect that the Ojo regression test's expected data file is
|
||||
outdated**
|
||||
- Michael said that on their internal Jenkins CI, these tests are not
|
||||
being run currently, so this might be possible that the file is
|
||||
outdated.
|
||||
- **Since some of the tests need Makefile to install while testing,
|
||||
CMake generated Makefiles and test Makefiles are conflicting, and
|
||||
hence we are forced to use Ninja for testing. What can I do about
|
||||
it?**
|
||||
- Michael suggested using `--file=filename` flag with the make command
|
||||
and change the name of the test Makefile to something else. This
|
||||
will solve the problem.
|
||||
- **Mimetype is detecting executables as shared lib, is that expected or
|
||||
needs to be fixed?**
|
||||
- Mimetype internally depends on the *file* command to get the
|
||||
mime-type. If the output of the *file* command is also the same then
|
||||
it is okay.
|
||||
- **What is** `folderlist` **in
|
||||
<https://github.com/fossology/fossology/blob/master/src/delagent/agent_tests/Functional/ft_cliDelagentTest.php#L126>
|
||||
?**
|
||||
- `folderlist` is a view. Use `createViews()` function.
|
||||
- **Suggestions/Changes from Gaurav for fixing phpunit tests.**
|
||||
- Please note the changes in `setUp()` function in
|
||||
`src/lib/php/tests/test_common_license_file.php`
|
||||
- The test database name is given to the constructor of TestPgDb and
|
||||
can be anything as it gets deleted in `teardown()`
|
||||
- The `dbmanager` is provided by the object, no need to initialize
|
||||
global `PG_CONN` (it will be exposed by the library in case some of
|
||||
the functions need it).
|
||||
- All the tables needs to be explicitly mentioned to
|
||||
`createPlainTables()` and their corresponding `createSequences()`
|
||||
(you can get them using `\d tablename` from existing DB easily. Then
|
||||
call the `alterTables()` to update the sequence. (I am not sure if
|
||||
`createConstraints()` is required at all, try to remove)
|
||||
- `tearDown()` is pretty easy, just need to call `fullDestruct()`. For
|
||||
debugging, you can add `exit(-1);` after any line you as suspecting,
|
||||
connect to DB and checkout the database, select/inspect tables.
|
||||
- There is also `TestInstaller` class in case any of test case needs
|
||||
the whole mods-enabled with fossology.conf, VERSION, etc. Please
|
||||
check `src/cli/tests/test_fo_copyright_list.php` for quick
|
||||
reference.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Fix the remaining tests.
|
||||
- Add week 8, 9 reports.
|
||||
- Add Final Evaluation Report.
|
||||
- Complete Final Evaluation.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Michael C. Jaeger](https://github.com/mcjaeger)
|
||||
- [Anupam Ghosh](https://github.com/ag4ums)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-06-11T23:30:40
|
||||
description: In this third meeting, I demoed the working build system, currently building
|
||||
executables and libraries, a lot of queries were resolved about writing version
|
||||
files and attaching commits and hashes to the build.
|
||||
image: /images/tech-wallpaper-3.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 1 Meeting
|
||||
---
|
||||
|
||||
In this third meeting, I demoed the working build system, currently building executables and libraries, a lot of queries were resolved about writing version files and attaching commits and hashes to the build.
|
||||
|
||||
## Week 1 Progress
|
||||
|
||||
> This week was mainly focused on analyzing the previous build system and framing a skeleton for the new build system.
|
||||
>
|
||||
> - Created the build configuration [analysis table](https://github.com/avinal/FOSSology/wiki/agents-spec#agents-configuration-list).
|
||||
> - Completed the basic skeleton.
|
||||
> - Completed the CMake configuration for libraries
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
> - Test on [GitPod](https://gitpod.io/#https://github.com/avinal/FOSSology/tree/avinal/feat/cmake-buildsystem) right inside your browser.
|
||||
|
||||
## Discussions
|
||||
|
||||
- **What are the flags needed for C and C++?**
|
||||
- The `-g` flag enables debug.
|
||||
- The `-O2` flag is used for optimizing.
|
||||
- In FOSSology these two flags are used together by default for all
|
||||
build purposes because it is desired to have an optimized binary but
|
||||
some level of debugging information is also desired.
|
||||
- **The Makefiles have some compile-time preprocessor macro definitions
|
||||
that need to be passed to each build.** The Makefiles have all the
|
||||
path values passed as `'"..value.."'` format *(double quote inside
|
||||
single quotes)*, however the commands produced by CMake have
|
||||
`\"..value..\"` format *(escaped double quotes)*. Are they the same or
|
||||
it needs to be changed?
|
||||
- Currently, there is nothing to determine if they work the same or
|
||||
not, but if the compiler would not have accepted them then, it would
|
||||
have thrown an error. As long it is working these should be fine,
|
||||
but will need to be checked in the final build.
|
||||
- **Are all libraries in FOSSology static?**
|
||||
- No, by default no library is static. The format
|
||||
`lib<library-name>.a` is confusing but no need to worry about it for
|
||||
now, if this is working fine then no problem.
|
||||
- In general, this format denotes a static library.
|
||||
- **How to add the version and commit information to the builds?**
|
||||
- I have gone through [this
|
||||
thread](https://cmake.org/pipermail/cmake/2018-October/068383.html)
|
||||
on CMake's official mailing list. And they have suggested a lot of
|
||||
options, but unable to decide which option to use. Gaurav said he
|
||||
will see into this thread and for now, I should try writing a shell
|
||||
script and test if that works.
|
||||
- Same can be tested for the version too.
|
||||
- **What is** `_squareVisitor.h.pre` **used for?**
|
||||
- They are used to generate source code at build time.
|
||||
- **Is there any inheritance structure in the build system?**
|
||||
*(Michael)*
|
||||
- For now, I am writing separate modules for the default operations
|
||||
needed in most configurations. The final structure will be decided
|
||||
in the final build.
|
||||
- **Where are all the binaries produced?** *(Gaurav)*
|
||||
- They are located in the build folder with the same directory
|
||||
structure as the original project.
|
||||
- While installing the same will be used and none of the source
|
||||
folders are ever disturbed.
|
||||
- **Are all flags taken from the Makefiles itself?** *(Anupam)*
|
||||
- Yes and No, there are some flags that CMake uses by default, they
|
||||
can be altered by changing the value for `CMAKE_C_FLAGS` and
|
||||
`CMAKE_CXX_FLAGS`. One can also append their flags. Since not all
|
||||
compilation requires all the flags, I have taken the default one
|
||||
into cache variables, and others are appended while configuring for
|
||||
a particular project.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Try the `monkbulk` in monk and `makefile.sa` in nomos.
|
||||
- Try adding the version and commit hash info.
|
||||
- Implement writing version files for each build.
|
||||
- Add proper comments in the `CMakeLists.txt` files.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Michael C. Jaeger](https://github.com/mcjaeger)
|
||||
- [Shaheem Azmal M MD](https://github.com/shaheemazmalmmd)
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Anupam Ghosh](https://github.com/ag4ums)
|
||||
- [Ayush Bhardwaj](https://github.com/hastagAB)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-06-18T23:30:00
|
||||
description: In this fourth meeting, a lot of questions were discussed related to
|
||||
the existing build system and what things we have to drop or modify.
|
||||
image: /images/tech-wallpaper-4.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 2 Meeting
|
||||
---
|
||||
|
||||
In this fourth meeting, a lot of questions were discussed related to the existing build system and what things we have to drop or modify.
|
||||
|
||||
## Week 2 Progress
|
||||
|
||||
> This week was mainly focused on creating CMake configuration for libraries, executables and coverage.
|
||||
>
|
||||
> - Added the configuration for libraries and executables
|
||||
> - Resolved parallel build problems with coverage configs
|
||||
> - Implemented generated source configurations
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **Should I generalize the coverage build for each agent?**
|
||||
- Coverage depends on the agent_tests and may or may not be available
|
||||
for all the agent. So follow the Makefiles and add the configuration
|
||||
as it is in them.
|
||||
- Leave coverage for them who don't have it already in their
|
||||
Makefiles.
|
||||
- **What are :code:\`\$(AGENTLIB) \$(REPO) \$(DB)\` in the Makefiles?**
|
||||
- They seems to be remains of previous build configuration. Until
|
||||
there is a problem, ignore if you can not find the definitions.
|
||||
- **Can I refactor the directory structure of nomos and monk, it will
|
||||
help keep the source code generation out of source directory?**
|
||||
- Yeah, sure. As long as it does not affects the working of the
|
||||
project you may refactor them to suit your needs.
|
||||
- **I am facing problems with due to headers included using angled
|
||||
brackets, can I change them to double quotes instead?**
|
||||
- Yeah that would be okay, anyway the general practice is to add user
|
||||
header files using double quotes.
|
||||
- **Using -Werror flag in regexscan causes build to fail, should I
|
||||
remove it?**
|
||||
- Since `regexscan` is not the part of default build you can ignore
|
||||
it.
|
||||
- **In scheduler source code the preprocessor macro value for
|
||||
FOSSDB_CONF is different from that in lib, is that correct?**
|
||||
- We have made some changes, please change it to the same as in lib.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Try adding the version and commit hash info.
|
||||
- Implement writing version files for each build.
|
||||
- Add proper comments in the `CMakeLists.txt` files.
|
||||
- Complete the coverage build configuration
|
||||
- Start implementing the install configurations
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Michael C. Jaeger](https://github.com/mcjaeger)
|
||||
- [Shaheem Azmal M MD](https://github.com/shaheemazmalmmd)
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-06-22T23:22:00
|
||||
description: In this fifth meeting, question related to versioning and obtaining commit
|
||||
hash were discussed, this was a short meeting.
|
||||
image: /images/tech-wallpaper-5.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 3 Meeting
|
||||
---
|
||||
|
||||
In this fifth meeting, question related to versioning and obtaining commit hash were discussed, this was a short meeting.
|
||||
|
||||
## Week 3 Progress
|
||||
|
||||
> Version file Implementation
|
||||
>
|
||||
> - Initial functions on obtaining commit and branch info
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **What is the regex expression used for obtaining version
|
||||
information?**
|
||||
- The regex has recently been modified to cover recent versions. The
|
||||
latest form is as below:
|
||||
|
||||
``` cpp
|
||||
([[:digit:]]+.[[:digit:]]+.[[:digit:]]+)(-?rc[[:digit:]]+)?-?([[:digit:]]*)-?[[:alnum:]]*
|
||||
```
|
||||
|
||||
- You can also try alternatives to regex if possible for CMake.
|
||||
- **Should I use** `git describe --tags` **or**
|
||||
`git describe --always HEAD` **for obtaining version information?**
|
||||
- In FOSSology we always use `git describe --tags`, no exception
|
||||
whatsoever.
|
||||
- CMake provides a preset configuration for the install path on GNU
|
||||
systems, you can see the description
|
||||
[here](https://cmake.org/cmake/help/v3.10/module/GNUInstallDirs.html)
|
||||
based on the
|
||||
[configuration](https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
|
||||
suggested by the GNU After comparing the variables defined in
|
||||
Makefile.conf with these, it seems directly taken from GNU standards.
|
||||
So I wanted to ask if this would be okay to stick to the presets,
|
||||
instead of manually declaring the same paths? The former step will
|
||||
reduce the number of variables we are currently caching and will make
|
||||
it flexible for different installation scenarios.
|
||||
- Using the GNU standards is the ideal situation but FOSSology uses
|
||||
slightly different locations. For example, all agents end up under
|
||||
`/usr/local/share/fossology/` with their individual folders instead
|
||||
of going to `/usr/local/bin/`.
|
||||
- If the same results can be achieved by using the
|
||||
`CMAKE_INSTALL_<dir>` and `CMAKE_INSTALL_PREFIX` then yeah, it will
|
||||
be preferred.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Try adding the version and commit hash info.
|
||||
- Implement writing version files for each build.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Michael C. Jaeger](https://github.com/mcjaeger)
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-06-29T23:22:00
|
||||
description: In this seventh meeting question related to installing the FOSSology
|
||||
were discussed.
|
||||
image: /images/tech-wallpaper-6.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 4 Meeting-1
|
||||
---
|
||||
|
||||
In this seventh meeting question related to installing the FOSSology were discussed.
|
||||
|
||||
## Week 4 Progress
|
||||
|
||||
> CMake configuration files have been refactored to make each agent as a separate sub-project.
|
||||
>
|
||||
> - Symbolic links are installing.
|
||||
> - VERSION files can be generated now during configure step
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **There are two types of replacements CMake can configure file with.**
|
||||
`@VARIABLE@` **and** `${VARIABLE}` **. Since in PHP** `$variable` **is
|
||||
used, it may create problem for CMake replacements. So may I replace
|
||||
them?**
|
||||
- Yeah sure, go ahead. It will be more robust.
|
||||
- The replacement of `$VARIABLE` can be stopped by using `@ONLY`
|
||||
option in `configure_file(...)` command.
|
||||
- **How to generate vendor directory?**
|
||||
- The code for generating vendor directory is in `src/Makefile`.
|
||||
- Before executing code for the generation, make sure to copy
|
||||
`composer.json` and `composer.lock` to the target directory.
|
||||
- There is also a patch that FOSSology needs to function as intended.
|
||||
Make sure to run that patch to check and apply.
|
||||
- For now, we generate *vendor* while building, but it would be nice
|
||||
if it can be generated in the build step.
|
||||
- **Currently I am generating the VERSION file in configure step itself.
|
||||
Should I move it to the build or install step?**
|
||||
- Yeah, please move it to the build step. As in configure step the
|
||||
data might be outdated.
|
||||
- **Is there any configuration for Release that we can use to install or
|
||||
test?** *(Michael)*
|
||||
- Yeah, there are 4 inbuilt configurations for various levels of
|
||||
optimization and can be applied to tests and installation.
|
||||
- **Is the VERSION file is generated for each agent or whole project at
|
||||
once? Because in the latter case, the VERSION file can be generated as
|
||||
the last step.**
|
||||
- No agent has a VERSION file along with the main VERSION file for
|
||||
FOSSology.
|
||||
- **How I can build and install a single agent or component?**
|
||||
- There are two ways you can build and install a specific agent or
|
||||
component only.
|
||||
|
||||
- The first one is quite simple. Just change your directory to the
|
||||
specific agent's directory and run all the usual commands for
|
||||
building and installing.
|
||||
|
||||
- The second one is a bit for typing work. This can be used directly
|
||||
from the top-level directory. After configuring the CMake, you can
|
||||
run the following command to install the specific component.
|
||||
|
||||
``` bash
|
||||
# for Unix Makefiles
|
||||
make list_install_component # this will list all the available components
|
||||
cmake -DCOMPONENT=<component-name> -P cmake_install.cmake
|
||||
```
|
||||
|
||||
- I am writing a macro that will let us install a component by simply
|
||||
running `make install component`.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Implement generation of vendor directory.
|
||||
- Move VERSION file generation to build step.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Michael C. Jaeger](https://github.com/mcjaeger)
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-07-02T22:22:00
|
||||
description: In this eighth meeting questions related to post install generation were
|
||||
asked. This was a short meeting.
|
||||
image: /images/tech-wallpaper-7.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 4 Meeting-2
|
||||
---
|
||||
|
||||
In this eighth meeting questions related to post install generation were asked. This was a short meeting.
|
||||
|
||||
## Week 4 Progress
|
||||
|
||||
> Version parsing logic implemented.
|
||||
>
|
||||
> - VERSION and COMMIT_HASH added to every executables.
|
||||
> - Installing part is complete except `cli`.
|
||||
> - Symbolic Links are installing and working fine.
|
||||
> - Version, Symbolic Links, `VERSION` file generation, `version.php` generation are now more modular and called via a single function for each agent
|
||||
> - Most dependencies are now moved to single configuration file.
|
||||
> - Vendor directory generation and installing are now working.
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **Why all the symbolic links in cli points to** `fo_wrapper`
|
||||
**script?**
|
||||
- The `fo_wrapper` script calls the PHP script on the symbolic link
|
||||
that called the fo_wrapper. It also initializes any requirement
|
||||
before calling the scripts.
|
||||
- **How to generate all the other configuration in**
|
||||
`/usr/local/etc/fossology` **directory?**
|
||||
- You can find the input files for all these configurations in the
|
||||
`install/defcon` directory.
|
||||
- **What are** `OBSOLETEFILES` **in** `www/ui/Makefile` **?**
|
||||
- They are kept for compatibility purposes. Although they have been
|
||||
removed in the current versions of FOSSology, if a user installs a
|
||||
new version on top of an older instance, then we should explicitly
|
||||
remove those files.
|
||||
- **I have created a separate folder for generating vendor directory. Is
|
||||
that okay?**
|
||||
- Yeah, it should be fine, But it would be better to rename it to
|
||||
something else. Or even better if moved to *www* itself. Since these
|
||||
files are used by www.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Move `vendor` scripts to `www` directory.
|
||||
- Implement installing for FOSSology cli.
|
||||
- Implement installing configuration scripts.
|
||||
- Finish installation for testing
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-07-09T22:22:00
|
||||
description: This week was dedicated to perfecting CMake Installation Configuration.
|
||||
The installation was tested and bugs were discussed.
|
||||
image: /images/tech-wallpaper-8.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 5 Meeting
|
||||
---
|
||||
|
||||
This week was dedicated to perfecting CMake Installation Configuration. The installation was tested and bugs were discussed.
|
||||
|
||||
## Week 5 Progress
|
||||
|
||||
> CMake Installation Configuration is almost complete.
|
||||
>
|
||||
> - FOSSology can be installed completely via CMake
|
||||
> - Post install script generation also added
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- There are permission problems while running bash script of `nomos`,
|
||||
`monk` and `genvendor`.
|
||||
- One possible fix can be to add `bash` before each bash scripts.
|
||||
- The other fix is to modify shebang line in each script from
|
||||
`#!/bin/sh` to `#!/bin/bash`.
|
||||
- In copyright agent same files are being compiled thrice, this is
|
||||
slowing down the build.
|
||||
- I am working on it. The problem is occurring because of three
|
||||
different executables.
|
||||
- I will try to combine the common objects together.
|
||||
- There are some redundant files in the installation. And VERSION file
|
||||
is missing in `/usr/local/share/fossology`.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Fix copyright build.
|
||||
- Remove redundant files and folders.
|
||||
- Fix permission issues.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-07-23T22:22:00
|
||||
description: This week I implemented CMake packaging configuration for FOSSology.
|
||||
There were two meetings in this week and this report covers both of them.
|
||||
image: /images/tech-wallpaper-9.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 7 Meeting
|
||||
---
|
||||
|
||||
This week I implemented CMake packaging configuration for FOSSology. There were two meetings in this week and this report covers both of them.
|
||||
|
||||
## Week 7 Progress
|
||||
|
||||
> Initial CMake packaging configuration implemented.
|
||||
>
|
||||
> - Packages can be built according to the FOSSology previous packaging structure.
|
||||
> - Copyright, ecc and keyword now builds faster.
|
||||
> - To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **Where I can find packaging info for FOSSology?**
|
||||
- All the scripts and companion files are located inside `debian`
|
||||
folder.
|
||||
- The most important files are `control`, which contains the
|
||||
dependency and description of each package, and `rules` file, which
|
||||
contains the make commands for creating the packages.
|
||||
- **What are** `${shlibs:Depends}` **and** `${misc:Depends}` ?
|
||||
- They are dependencies required for creating Debian packages. CMake
|
||||
should be adding them by default so we can safely ignore them.
|
||||
- **Will the new packages have the same structure as the old ones?**
|
||||
*(Michael)*
|
||||
- Yes for compatibility purposes Gaurav has suggested exactly follow
|
||||
the same structure as the old one.
|
||||
- **Copyright build is slow because the same object files are being
|
||||
compiled three times, can you improve that?** *(Gaurav)*
|
||||
- I can try compiling the common object files beforehand and then
|
||||
adding the executables. But how to know the common object files?
|
||||
- Gaurav showed me where in the Makefiles I can find the common object
|
||||
files.
|
||||
- There are problems with copying the symbolic link and packaging them.
|
||||
So I have to find some alternatives to resolve that.
|
||||
- With component installing, package description can no longer be set.
|
||||
- The `fossology-common` package contains file from `fossology-db`
|
||||
package. And the `fossology-db` package is empty.
|
||||
- Gaurav said this was unexpected and should not happen. This seems to
|
||||
be a very old bug with packaging.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Work more on the packaging.
|
||||
- Improve compilation of copyright and monk agents
|
||||
- Try to solve the packaging bug and add a pull request for that.
|
||||
- Move on to implementing testing configurations.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Michael C. Jaeger](https://github.com/mcjaeger)
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Anupam Ghosh](https://github.com/ag4ums)
|
||||
- [Shaheem Azmal M MD](https://github.com/shaheemazmalmmd)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2021-07-30T22:47:00
|
||||
description: This week I implemented CMake packaging configuration for FOSSology.
|
||||
The new configuration fixes issue with previous packaging configurations. It also
|
||||
retains the component wise installation features.
|
||||
image: /images/tech-wallpaper-10.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- FOSSology
|
||||
title: Coding Week 8 Meeting
|
||||
---
|
||||
|
||||
This week I implemented CMake packaging configuration for FOSSology. The new configuration fixes issue with previous packaging configurations. It also retains the component wise installation features.
|
||||
|
||||
## Week 8 Progress
|
||||
|
||||
> CMake Packaging configuration almost completed.
|
||||
|
||||
- Packages can be built according to the FOSSology previous packaging structure.
|
||||
- Initial testing configuration added.
|
||||
- Ninja build has been fixed.
|
||||
- To test the current progress, follow the instructions [here](https://github.com/avinal/FOSSology/wiki#test-the-new-system-only-gcc-with-make-and-ninja-tested-for-now)
|
||||
|
||||
## Discussions
|
||||
|
||||
- **How is the testing implemented in FOSSology?**
|
||||
- Not all agents have testing implemented.
|
||||
- There are two types of tests *Unit* and *Functional*.
|
||||
- At first, the test executable calls multiple PHP scripts to create a
|
||||
test environment. And then tests are executed.
|
||||
- Files related to testing and common for all the agents are in
|
||||
`src/testing`
|
||||
- Other tests depends on `phpunit`. This *PHPUnit* is generated inside
|
||||
`vendor`.
|
||||
- **As of now, the testing configurations are hardcoded, what should I
|
||||
do, because it seems the testing configuration will require changes to
|
||||
a lot of files?**
|
||||
- Decide a deadline for the testing configuration and if until that
|
||||
point there is not very productive implementation then move to the
|
||||
next task that is implementing CI.
|
||||
- As of now building, installation, and packaging via CMake is working
|
||||
and in a stable state. To create an initial Pull Request. This would
|
||||
also be useful in case of the final evaluation and further testing
|
||||
will be based on this PR itself.
|
||||
- Fix any bugs or if there is the scope of improvement in Building,
|
||||
Installation and Packaging do that.
|
||||
|
||||
## Conclusion and Further Plans
|
||||
|
||||
- Prepare for an initial PR.
|
||||
- Fix known bugs and apply Improvements.
|
||||
- Work on testing configurations.
|
||||
|
||||
## Attendees
|
||||
|
||||
- [Gaurav Mishra](https://github.com/GMishx)
|
||||
- [Shaheem Azmal M MD](https://github.com/shaheemazmalmmd)
|
||||
- [Avinal Kumar](https://github.com/avinal)
|
||||
@@ -0,0 +1,365 @@
|
||||
---
|
||||
category: gsoc
|
||||
date: 2023-03-30T21:14:00
|
||||
description: It has been 2 years since I was a Google Summer of Code Student. It was
|
||||
an outstanding opportunity and I really enjoyed working on the project. Not only
|
||||
that, but it added numerous skills to my resume and polished many others. Today
|
||||
I want to make my proposal public, that helped me get selected.
|
||||
image: /images/panda-engineer.webp
|
||||
tags:
|
||||
- gsoc
|
||||
- fossology
|
||||
- proposal
|
||||
title: New Build System and improving CI/CD workflow
|
||||
---
|
||||
|
||||
It has been 2 years since I was a Google Summer of Code Student. It was an outstanding opportunity and I really enjoyed working on the project. Not only that, but it added numerous skills to my resume and polished many others. Today I want to make my proposal public, that helped me get selected.
|
||||
|
||||
## Current Build System and Workflow
|
||||
|
||||
### Build System
|
||||
|
||||
FOSSology’s build system is based on multilevel Makefile that work together to
|
||||
provide a build infrastructure for the project. Although make is a robust build
|
||||
system, but it is too outdated and slow compared to modern build systems. Although
|
||||
build configurations are not supposed to be updated as often as source files,
|
||||
there are few noticeable problems with make.
|
||||
|
||||
* Configuration is mostly hard-coded, i.e., if needed to use different tools or add source files, the Makefile needs to be updated
|
||||
* All the dependencies and libraries have to be added manually by writing configuration for each of them
|
||||
* Although the FOSSology project currently supports Linux only, if in the future it has to be ported to other platforms, make won’t be able to support it. Hence, it is not future safe.
|
||||
|
||||
### Workflow (Continuous Integration)
|
||||
|
||||
FOSSology project has been using open-source tier Travis CI for all its continuous
|
||||
integration and deployment needs. GitHub launched its CI/CD system some years ago,
|
||||
and it has become a standard for CI/CD. Travis CI does the work but provides significantly
|
||||
fewer features when compared to GitHub Actions.
|
||||
|
||||
* It has been observed that Travis CI is noticeably slower than GitHub Action for a similar configuration
|
||||
* Travis CI lacks the tight and seamless integration of GitHub Actions with other GitHub Services, some of them are the ability to integrate and communicate with GitHub apps, auto-manage to pull requests and issues, better support for Dockerized builds.
|
||||
|
||||
## Why a New Build System(CMake)?
|
||||
|
||||
There were many possible candidates for a new build system for the FOSSology project.
|
||||
Each has its pros and cons. After numerous comparisons and the ability of the new
|
||||
build system to integrate well with the existing system, CMake seems to be the best
|
||||
choice. Given below is a quick overview of different build systems and their execution times.
|
||||
|
||||
|
||||
|
||||
Here, CMake (Make & Ninja) performs better than average compared to other tools.
|
||||
The criteria for choosing CMake were not only performance, but many other factors.
|
||||
|
||||
* The build system should be easily available on all supported distros - Cmake supports _UNIX, MS Windows (MSVC, Borland, Cygwin, MinGW) and Mac OS X, and more_
|
||||
* It should be easy to install – CMake is available via all popular package managers and repositories
|
||||
* Should improve build speed – In general, CMake always outperforms bare metal make systems.
|
||||
* The learning curve is not too steep – CMake is not very hard and neither too easy to learn. For common projects, it is easy to learn.
|
||||
|
||||
### CMake Perks
|
||||
|
||||
* No other dependencies apart from the C/C++ compiler
|
||||
* Includes a testing framework (CTest)
|
||||
* Includes a multipurpose packaging solution (CPack)
|
||||
* Migrating from Make to CMake is easier compared to other build systems
|
||||
* Can generate platform-specific build configuration; hence the same script can be used for multiple platforms
|
||||
* All modern C/C++ IDEs have inbuilt support for CMake or via a plugin (Visual Studio, XCode, CLion)
|
||||
* Can load dependencies automatically from the internet or local file system
|
||||
* Source and build folders are separate by default in CMake, this avoids bloating the source folders and accidentally deleting important files.
|
||||
|
||||
### Comparison of CMake and Make syntax
|
||||
|
||||
#### Make Syntax
|
||||
|
||||
```makefile
|
||||
CXXFLAGS = -I../include -I.
|
||||
|
||||
SRC := $(wildcard *.cc)
|
||||
DEP := $(patsubst %.cc,%.d,$(SRC))
|
||||
OBJ := $(patsubst %.cc,%.o,$(SRC))
|
||||
|
||||
all: $(PROGNAME)
|
||||
|
||||
$(PROGNAME): $(OBJ) ../lib/$(LIBNAME)
|
||||
$(CXX) $(CXXFLAGS) $^ -o $@
|
||||
|
||||
%.d: %.cc
|
||||
$(CXX) -MM $(CXXFLAGS) $< | sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@
|
||||
|
||||
ifneq ($(filter clean,$(MAKECMDGOALS)),clean)
|
||||
-include $(DEP)
|
||||
endif
|
||||
|
||||
clean:
|
||||
$(RM) $(DEP) $(OBJ) $(PROGNAME)
|
||||
```
|
||||
|
||||
#### Corresponding CMake File
|
||||
|
||||
```cmake
|
||||
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../include)
|
||||
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
|
||||
|
||||
AUX_SOURCE_DIRECTORY(${CMAKE_CURRENT_SOURCE_DIR} source)
|
||||
add_executable(hellocmake ${source})
|
||||
target_link_libraries(hellocmake LINK_PUBLIC libhellocmake)
|
||||
```
|
||||
|
||||
### How to (c)make the move?
|
||||
|
||||
#### Step 1: Determine the total number and types of Makefiles to migrate
|
||||
|
||||
We will determine the required time for the whole migration and the number of respective
|
||||
CMake scripts to be written. In general, CMake scripts have fewer lines than Make
|
||||
scripts for the same task. However, the top-level CMake configuration can be very
|
||||
complex depending on how many configurations we want to create.
|
||||
|
||||
* There are [168 Makefile](https://github.com/search?q=Makefile+repo%3Afossology%2Ffossology+filename%3A%22Makefile%22&type=Code)configurations as of now in FOSSology Project
|
||||
* Types: Build, Install, Test, Uninstall, Coverage, Clean, Package, and other sister types
|
||||
|
||||
#### Step 2: Start migrating Makefiles one agent/directory at a time
|
||||
|
||||
The FOSSology project’s build system follows a bottom-up approach. That means all
|
||||
the child directories need to be built first to build their parents. Since most
|
||||
of the agents in FOSSology are independent programs, their CMake config can be
|
||||
written separately. I have created a sample project to demonstrate the Make and
|
||||
CMake syntax and build process. It also demonstrates the cross-platform ability
|
||||
of CMake. The project can be accessed here: [https://github.com/avinal/make-cmake](https://github.com/avinal/make-cmake)
|
||||
|
||||
#### Step 3: Create the Top-Level CMakeLists.txt to link all the libraries
|
||||
|
||||
The top-level CMakelIsts.txt will be complex and most of the work, as well as testing,
|
||||
will be done during this phase. In the initial stage, I plan to create just the
|
||||
minimum to at least build the whole project in one go without any bells and whistles.
|
||||
|
||||
#### Step 4: Add required configurations (Install, Package, Test)
|
||||
|
||||
Once the top-level CMakeLists.txt is building the project without any problems.
|
||||
We will now add the required configurations such as install, package, test, uninstall,
|
||||
and other configurations.
|
||||
|
||||
#### Step 5: Test the new Build System
|
||||
|
||||
It is almost done, we may start testing our shiny build system. Checking every
|
||||
single configuration for errors and loopholes. This step will also make use of a
|
||||
new CI/CD system for testing purposes. Thus, simultaneously migrating the CI from
|
||||
Travis CI to GitHub Actions.
|
||||
|
||||
## Improving the CI/CD workflow
|
||||
|
||||
With the new build system, the FOSSology project will get a new CI/CD too. There
|
||||
were several tasks proposed for improving the workflow of FOSSology. I have completed
|
||||
many of them already. Given Below is an overview of the tasks proposed and their status.
|
||||
|
||||
* Syntax Check ([#1919](https://github.com/fossology/fossology/pull/1919))
|
||||
* Static Code Analysis ([#1919](https://github.com/fossology/fossology/pull/1919))
|
||||
* Copy/Paste Detector ([#1919](https://github.com/fossology/fossology/pull/1919))
|
||||
* PHP Codesniffer ([#1919](https://github.com/fossology/fossology/pull/1919))
|
||||
* Docker Tests
|
||||
* C/C++ agent tests
|
||||
* PHPUnit tests
|
||||
* GitHub Page Release ([#1917](https://github.com/fossology/fossology/pull/1917))
|
||||
* Implementing Caching in workflows
|
||||
* Implement source install (reference[#207](https://github.com/fossology/fossology/issues/207))
|
||||
* DOC, Commit, and PR guideline checks
|
||||
|
||||
### How will the workflow improve?
|
||||
|
||||
We are migrating the whole workflow to the GitHub Actions platform, in general,
|
||||
GHA provides better integration and builds time.
|
||||
|
||||
#### Step 6: Migrate the C/C++ agent tests and PHPUnit Tests
|
||||
|
||||
By this time, we have already migrated our build system to CMake and thus the new
|
||||
workflow will be based on CMake configurations. The goal will be to add more platforms
|
||||
(Debian/Ubuntu/Fedora etc.) for tests and upgrade the tools to their latest compatible versions.
|
||||
|
||||
#### Step 7: Implement Source Install test for Ubuntu, Debian, and Fedora
|
||||
|
||||
As of now, source install is not tested for any of the distributions, so this step
|
||||
aims at adding source install testing capability to the new CI.
|
||||
|
||||
#### Step 8: Implement caching in workflows and testing
|
||||
|
||||
GitHub Action can store cache dependencies for a given period and thus reduces the
|
||||
number of times the virtual machine has to fetch packages. This in turn reduces
|
||||
the overall build time as well as reduces the load on servers.
|
||||
|
||||
## Project Deliverables
|
||||
|
||||
* New Build System (CMake) for the project
|
||||
* New Packaging, Install and Test configuration
|
||||
* C/C++ agents tests for multiple versions of GCC
|
||||
* PHPUnit tests
|
||||
* Docker Tests
|
||||
* Cached Workflows
|
||||
* Source installs tests for Debian, Ubuntu, Fedora
|
||||
* Checks for Pull Requests and Commit guidelines
|
||||
|
||||
## Other Deliverables
|
||||
|
||||
* For track my progress as well as a resource for future contributors, I will be writing a weekly/biweekly blog. The same can be used for preparing the final GSoC report.
|
||||
* Since CMake will be new for the FOSSology Community, I will document all the important topics that I will come across while migrating the build system. This will be both a handpicked resource and a reference for future contributors.
|
||||
* I would love to be a part of the community even after GSoC, although the build system and CI/CD doesn’t need to be updated that often, I would like to contribute to other parts of the project.
|
||||
|
||||
## Experience
|
||||
|
||||
I have 3 years of experience in C/C++ programming and one year of experience with
|
||||
CMake and Make. I have used CMake and Make for many of my projects, as well as contributed
|
||||
to other open-source projects. Furthermore, I have created/migrated the CI/CD for
|
||||
many open-source organizations to GitHub Actions, and created many personal projects
|
||||
using GHA as well.
|
||||
|
||||
I have been contributing to many open-source organizations since 2019. I participated
|
||||
as a Technical Writer in the Google Season of Docs 2021 program under the VideoLAN
|
||||
organization. So, I have a nice understanding of open-source project workflow and
|
||||
contribution standards. I am well versed in Git and GitHub.
|
||||
|
||||
## Tech Stack
|
||||
|
||||
* CI/CD: **GitHub Actions, Travis CI**
|
||||
* Build Systems: **CMake, Make**
|
||||
* Languages: **C/C++, PHP, Shell Script**
|
||||
* Version Control: **Git, GitHub**
|
||||
* OS: **Ubuntu, Fedora, Debian**
|
||||
* Compilers: **GCC, Clang**
|
||||
* Containers: **Docker**
|
||||
|
||||
## Proposed Timeline
|
||||
|
||||
### Community Bonding (May 17th - June 6th, 2021)
|
||||
|
||||
* Discussing and collaborating with fellow participants and getting familiar with the FOSSology community and projects.
|
||||
* Since CMake is new for our FOSSology community, I will learn and bring in the resources so that people get comfortable with it before the coding period starts.
|
||||
* Going through the codebase and plan strategies for the migration, his includes identification of various types, segregation of libraries, executables, and dependencies.
|
||||
|
||||
### Coding Week 1 (June 7th - June 13th, 2021)
|
||||
|
||||
* Plan the priority order of migration, and create lists for all different configurations
|
||||
* Create CMake configuration for libraries.
|
||||
* There are approximately 8 libraries, since configuration is not that complex, it should take no longer than 1 week to complete
|
||||
|
||||
### Coding Week 2 & 3 (June 14th - June 27th, 2021)🚩
|
||||
|
||||
* If libraries are complete, migrate the agents one by one, since FOSSOlogy is based on a modular architecture, many agents can be independently migrated
|
||||
* There are some 27 agents, 2 agents per day should take 2 weeks; hence I have merged these weeks.
|
||||
* Time may vary for different agents to be migrated to CMake, but on average, this should take 2 weeks.
|
||||
* Buffer Period
|
||||
|
||||
### Coding Week 4 (June 28th - July 4th, 2021)
|
||||
|
||||
* By now all the agents and libraries are migrated and presently the top-level CMakeLists.txt should be created. Since this file will be complex and will need all the child configuration to work, the testing and completion should approximately take 1 week.
|
||||
* This week will also check the overall gains in terms of performance and stability of the new build system.
|
||||
* This is also the minimum requirement for the build system to be said working and to add more configurations
|
||||
|
||||
### Coding Week 5 (July 5th - July 11th, 2021)🚩
|
||||
|
||||
* This week will continue the development of the Top-level CMake configuration.
|
||||
* More configuration will be added for Install, Test, Uninstall, Package
|
||||
* If completed, testing will start and will continue for the next week
|
||||
* Buffer Period
|
||||
|
||||
### Coding Week 6 (July 12th - July 18th, 2021) First Evaluation
|
||||
|
||||
* The build system is a very crucial element of the project; hence it must be tested thoroughly before final rolling.
|
||||
* This week, I will continue the development of all required configuration and testing of the new Build System.
|
||||
* By the end of this week, the new build system will be able to properly build the project and use the configurations, this also marks the end of the first phase and first evaluation.
|
||||
* Buffer Period
|
||||
|
||||
### Coding Week 7 (July 19th - July 25th, 2021)
|
||||
|
||||
* With all the build system working, this week will be used to migrate the CI from Travis to GitHub Actions starting with the C/C++ agent’s test
|
||||
* Now the C++ agent tests will be executed using the new Build System
|
||||
* If completed, then the PHPUnit test migration will start
|
||||
|
||||
### Coding Week 8 (July 26th - August 1st, 2021)🚩
|
||||
|
||||
* Complete the PHPUnit CI migration
|
||||
* Add Docker tests
|
||||
* Start implementing source install test CI
|
||||
|
||||
### Coding Week 9 (August 2nd - August 8th, 2021)
|
||||
|
||||
* Complete Source Install CI
|
||||
* Start implementing workflow caching
|
||||
* Fixing bugs and clearing backlogs
|
||||
* Buffer Period
|
||||
|
||||
### Coding week 10 (August 9th - August 15th, 2021)🚩
|
||||
|
||||
* Checking the build system
|
||||
* Checking the CI/CD
|
||||
* Completing reports and documentation
|
||||
* Update the existing documentation and readme for the new build system and CI
|
||||
|
||||
### Final Evaluations (August 16th - August 23rd, 2021)
|
||||
|
||||
* Code and report submission
|
||||
|
||||
### Milestones 🚩
|
||||
|
||||
1. All agents and libraries have now a CMake build configuration
|
||||
2. Top-level CMake configuration with a stable build
|
||||
3. Top-level CMake configuration with other configs i.e. install, package, test
|
||||
4. C/C++ agent tests, PHPUnit test implemented in CI
|
||||
5. CI/CD is complete according to the task list
|
||||
|
||||
## **Pre GSoC Involvements**
|
||||
|
||||
### In FOSSology
|
||||
|
||||
* [feat(CI): Migrate API docs generation and deployment to GitHub Actions](https://github.com/fossology/fossology/pull/1917) [MERGED]
|
||||
* [feat(CI): Migrate Static Checks and Analysis to GitHub Actions from Travis CI](https://github.com/fossology/fossology/pull/1919) [MERGED]
|
||||
* [fix(make): Fix warnings in make for Ubuntu 20.04.2 LTS](https://github.com/fossology/fossology/pull/1923) [OPEN]
|
||||
* [Upgrade this project from PHP 7 to PHP 8](https://github.com/fossology/fossology/issues/1920) [ISSUE]
|
||||
* [Improving build system and CI/CD flow](https://github.com/fossology/fossology/discussions/1931) [DISCUSSION]
|
||||
|
||||
### Other Contributions
|
||||
|
||||
* [VideoLAN/VLC for Android User Documentation](https://code.videolan.org/docs/vlc-android-user) [PROJECT]
|
||||
* [boostorg/gil](https://github.com/boostorg/gil/issues?q=author%3Aavinal) [2 PR, 1 ISSUE]
|
||||
* [embox/embox](https://github.com/embox/embox/issues?q=author%3Aavinal) [1 PR]
|
||||
* [JetBrains/swot](https://github.com/JetBrains/swot/pulls?q=author%3Aavinal) [1 PR]
|
||||
* [jupyter-xeus/xeus-sqlite](https://github.com/jupyter-xeus/xeus-sqlite/issues?q=author%3Aavinal) [1 PR, 1 ISSUE]
|
||||
* [github/explore](https://github.com/github/explore/pulls?q=avinal) [2 PR]
|
||||
|
||||
## My Development Environment
|
||||
|
||||
* Operating Systems: Ubuntu 20.04 LTS, Windows 10 20H2
|
||||
* Editors: Visual Studio Code, Vim
|
||||
* IDE: Visual Studio, CLion
|
||||
* Internet Speed: 20 Mbps
|
||||
|
||||
## References and Resources
|
||||
|
||||
1. [A sample Make CMake project structure and comparison](https://github.com/avinal/make-cmake)
|
||||
2. [CMake Reference Documentation — CMake 3.20.0 Documentation](https://cmake.org/cmake/help/latest/)
|
||||
3. [A simple comparison](https://mesonbuild.com/Simple-comparison.html) of different build systems
|
||||
4. [Why the KDE project switched to CMake -- and how (continued)](https://lwn.net/Articles/188693/)
|
||||
5. [bksys / scons (Re: win32 port)](https://mail.kde.org/pipermail/kde-buildsystem/2006-January/000410.html)
|
||||
6. [CMake vs Make](https://prateekvjoshi.com/2014/02/01/cmake-vs-make/)
|
||||
|
||||
## Motivation
|
||||
|
||||
Ever since I came to know about GSoC(that was in my first year), I wanted to be
|
||||
a part of it. This was even before I got the idea of Open Source. Once I started
|
||||
contributing to open source, I started liking it and gradually became a part. I
|
||||
did Google Season of Docs 2020 under the VideoLAN organization and got a nice overview
|
||||
of open-source development, communities, and programs.
|
||||
|
||||
I found that the FOSSology community is very passionate about open-source contributions,
|
||||
and they welcome experts and noobs alike. Other than that, open community meetings
|
||||
are one of the best things I encountered in my open-source journey. I hope by being
|
||||
a part of this community I will exchange skills and experiences and thus help both
|
||||
the community and me.
|
||||
|
||||
## Commitments
|
||||
|
||||
This summer, I don’t have any classes or internships. I found this project very
|
||||
fascinating, and I have already worked out a portion of this project, so this project
|
||||
is my _priority_. Although the program is supposed to be part-time, I will be able
|
||||
to work full time as well on weekends. I will attend all the meetings and prepare
|
||||
reports on time. I am an active member of the community presently, and will continue
|
||||
the streak during GSoC as well as after GSoC.
|
||||
|
||||
**Thanks**
|
||||
@@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: true
|
||||
---
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Everything on my Pi
|
||||
date: 2023-10-01T10:47:00
|
||||
category: raspi
|
||||
tags: [raspi, linux, pi, raspbian, debian, ubuntu, server, docker]
|
||||
image: "/images/big-raspberry-pi.webp"
|
||||
description: "A list of everything I have installed on my Raspberry Pi 4B."
|
||||
---
|
||||
|
||||
I always wanted to have my self-hosted server when I was in college. Never had enough money to do much
|
||||
until recently. So after I got my first job, I have invested moderately (heavily actually ;)) in gadgets and stuff. And one
|
||||
of my most prized possession is my Raspberry Pi 4. I have been using it for a while now, and I have
|
||||
installed many useful things on it. So I thought I would share it with everyone. This is a list of
|
||||
everything I have on my Pi.
|
||||
|
||||
## Hardware and Specifications
|
||||
|
||||
- [Raspberry Pi 4B 8GB Model](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/)
|
||||
- [Samsung 64GB EVO Plus microSDXC U1 Class 10](https://www.samsung.com/us/computing/memory-storage/memory-cards/evo-plus---adapter-microsdxc-64gb-mb-mc64ka-am/)
|
||||
- [Raspberry Pi 15W USB-C Power Supply](https://www.raspberrypi.com/products/type-c-power-supply/)
|
||||
- [Rpi shop Raspberry pi 4 case Model B Acrylic case with Fan + heatsink Included](https://amzn.eu/d/8vvwkfg)
|
||||
|
||||
I already had a good quality ethernet cable, so I didn't have to buy one.
|
||||
@@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: true
|
||||
---
|
||||
@@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: true
|
||||
---
|
||||
@@ -0,0 +1,45 @@
|
||||
baseURL: 'https://avinal.space/'
|
||||
languageCode: en-us
|
||||
title: Fedoraemon
|
||||
menus:
|
||||
main:
|
||||
- name: Home
|
||||
pageRef: /
|
||||
weight: 10
|
||||
- name: Posts
|
||||
pageRef: /posts
|
||||
weight: 20
|
||||
- name: Tags
|
||||
pageRef: /tags
|
||||
weight: 30
|
||||
module:
|
||||
hugoVersion:
|
||||
extended: false
|
||||
min: 0.116.0
|
||||
|
||||
params:
|
||||
showWordCount: true
|
||||
showReadingTime: true
|
||||
toc: true
|
||||
numberedSubtitles: true
|
||||
navs:
|
||||
- name: Home
|
||||
link: https://avinal.space
|
||||
- name: About
|
||||
link: https://avinal.space/pages/about-me
|
||||
- name: Blog
|
||||
link: https://avinal.space/posts
|
||||
- name: Projects
|
||||
link: https://avinal.space/pages/projects
|
||||
- name: GitHub
|
||||
link: https://github.com/avinal
|
||||
|
||||
disableKinds: ["home", "taxonomy"]
|
||||
|
||||
taxonomies:
|
||||
category: category
|
||||
tag: tags
|
||||
|
||||
permalinks:
|
||||
tags: "/posts/tags/:slug"
|
||||
category: "/posts/category/:slug"
|
||||
@@ -0,0 +1,3 @@
|
||||
<h{{ .Level }} id="{{ .Anchor | safeURL }}">{{ .Text | safeHTML }}
|
||||
<a href="#{{ .Anchor | safeURL }}">#</a>
|
||||
</h{{ .Level }}>
|
||||
@@ -0,0 +1,18 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="{{ or site.Language.LanguageCode site.Language.Lang }}"
|
||||
dir="{{ or site.Language.LanguageDirection `ltr` }}">
|
||||
|
||||
<head>
|
||||
{{ partial "head.html" . }}
|
||||
</head>
|
||||
|
||||
<body class="bg-neutral-800">
|
||||
<main class="container mx-auto">
|
||||
{{ block "main" . }}{{ end }}
|
||||
<footer>
|
||||
{{ partial "footer.html" . }}
|
||||
</footer>
|
||||
</main>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,7 @@
|
||||
{{ define "main" }}
|
||||
{{ .Content }}
|
||||
{{ range site.RegularPages }}
|
||||
<h2><a href="{{ .RelPermalink }}">{{ .LinkTitle }}</a></h2>
|
||||
{{ .Summary }}
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
@@ -0,0 +1,82 @@
|
||||
{{ define "main" }}
|
||||
<div
|
||||
class="prose prose-invert mx-auto lg:prose-lg prose-a:decoration-cyan-500 hover:prose-a:decoration-pink-500 text-white">
|
||||
<div class="md:-mx-8 lg:-mx-16 px-8 py-1">
|
||||
<h1 class="text-5xl font-bold mb-6 mt-12 text-center">{{ .Title }}</h1>
|
||||
|
||||
{{ .Content }}
|
||||
</div>
|
||||
</div>
|
||||
<section class="text-gray-100">
|
||||
<div class="max-w-6xl p-6 mx-auto space-y-6 sm:space-y-12 mb-16">
|
||||
{{ range first 1 .Pages }}
|
||||
<div
|
||||
class="block max-x-sm gap-3 mx-auto sm:max-w-full group hover:no-underline focus:no-underline lg:grid lg:grid-cols-12 bg-neutral-900">
|
||||
<a class="lg:col-span-7" href="{{ .RelPermalink }}">
|
||||
<img class="object-cover w-full h-64 rounded sm:h-96 lg:col-span-7" src="{{ .Params.Image | absURL }}"
|
||||
alt="{{ .LinkTitle }}">
|
||||
</a>
|
||||
<div class="p-6 space-y-2 lg:col-span-5">
|
||||
<a href="{{ .RelPermalink }}">
|
||||
<h3 class="text-2xl font-semibold sm:text-4xl group-hover:underline group-focus:underline">{{ .LinkTitle }}
|
||||
</h3>
|
||||
{{ $dateMachine := .Date | time.Format "2006-01-02T15:04:05-07:00" }}
|
||||
{{ $dateHuman := .Date | time.Format ":date_long" }}
|
||||
<time datetime="{{ $dateMachine }}" class="text-gray-400">{{ $dateHuman }}</time>
|
||||
{{ if gt .ReadingTime 1 }}
|
||||
{{ .Scratch.Set "timeUnit" "mins" }}
|
||||
{{ else }}
|
||||
{{ .Scratch.Set "timeUnit" "min" }}
|
||||
{{ end }}
|
||||
|
||||
{{ if .Site.Params.showReadingTime }}
|
||||
<span class="text-gray-400"> | ~{{.ReadingTime}} {{ .Scratch.Get "timeUnit" }}</span>
|
||||
{{ end }}
|
||||
<p> {{ .Summary | truncate 250 }}</p>
|
||||
</a>
|
||||
<a href="" target="_blank">
|
||||
<span class="flex flex-wrap py-6 space-x-2">
|
||||
<a class="px-3 py-1 m-1 rounded-sm hover:underline bg-pink-400 text-gray-900 font-bold" href="/posts/category/{{ .Params.Category }}">
|
||||
{{ .Params.Category }}</a>
|
||||
</span>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
{{ end }}
|
||||
<div class="grid justify-center grid-cols-1 gap-6 sm:grid-cols-2 lg:grid-cols-3">
|
||||
{{ range after 1 .Pages }}
|
||||
<div class="max-w-sm mx-auto group hover:no-underline focus:no-underline bg-neutral-900">
|
||||
<a href="{{ .RelPermalink }}">
|
||||
<img class="object-cover w-full h-44 rounded" src="{{ .Params.Image | absURL }}" alt="{{ .LinkTitle }}">
|
||||
</a>
|
||||
<div class="p-6 space-y-2">
|
||||
<a href="{{ .RelPermalink }}">
|
||||
<h3 class="text-2xl font-semibold group-hover:underline group-focus:underline">{{ .LinkTitle }}</h3>
|
||||
{{ $dateMachine := .Date | time.Format "2006-01-02T15:04:05-07:00" }}
|
||||
{{ $dateHuman := .Date | time.Format ":date_long" }}
|
||||
<time datetime="{{ $dateMachine }}" class="text-gray-400">{{ $dateHuman }}</time>
|
||||
{{ if gt .ReadingTime 1 }}
|
||||
{{ .Scratch.Set "timeUnit" "mins" }}
|
||||
{{ else }}
|
||||
{{ .Scratch.Set "timeUnit" "min" }}
|
||||
{{ end }}
|
||||
|
||||
{{ if .Site.Params.showReadingTime }}
|
||||
<span class="text-gray-400"> | ~{{.ReadingTime}} {{ .Scratch.Get "timeUnit" }}</span>
|
||||
{{ end }}
|
||||
<p> {{ .Summary | truncate 150 }}</p>
|
||||
|
||||
</a>
|
||||
<a href="" target="_blank">
|
||||
<span class="flex flex-wrap py-6 space-x-2">
|
||||
<a class="px-3 py-1 m-1 rounded-sm hover:underline bg-pink-400 text-gray-900 font-bold" href="/posts/category/{{ .Params.Category }}">
|
||||
{{ .Params.Category }}</a>
|
||||
</span>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
{{ end }}
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
{{ end }}
|
||||
@@ -0,0 +1,32 @@
|
||||
{{ define "main" }}
|
||||
<div class="min-h-screen flex flex-col justify-center relative overflow-hidden">
|
||||
<div class="relative w-full bg-neutral md:max-w-3xl md:mx-auto lg:max-w-4xl lg:pb-28">
|
||||
|
||||
<div class="prose prose-invert mx-auto lg:prose-lg prose-a:decoration-cyan-500 hover:prose-a:decoration-pink-500">
|
||||
<div class="bg-neutral-900 md:-mx-8 lg:-mx-16 px-8 py-1">
|
||||
|
||||
{{ partial "header.html" . }}
|
||||
|
||||
<article>
|
||||
{{ if cond (ne .Params.toc nil) .Params.toc .Site.Params.toc }}
|
||||
{{ if ne .TableOfContents "<nav id=\"TableOfContents\"></nav>" }}
|
||||
<details class="open:bg-neutral-800 open:border open:rounded open:border-cyan-700 ">
|
||||
<summary>
|
||||
<b>In this post, we'll take a look at:</b>
|
||||
</summary>
|
||||
<div class="toc {{ if .Site.Params.numberedSubtitles }}numbered-subtitles{{ end }} ">{{ .TableOfContents }}
|
||||
</div>
|
||||
</details>
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
|
||||
{{ .Content }}
|
||||
</article>
|
||||
|
||||
{{ partial "terms.html" (dict "taxonomy" "tags" "page" .) }}
|
||||
</div>
|
||||
</div>
|
||||
{{ partial "comments.html" . (dict "taxonomy" "tags" "page" .) }}
|
||||
</div>
|
||||
</div>
|
||||
{{ end }}
|
||||
@@ -0,0 +1 @@
|
||||
<div id="remark42" class="md:p-4 mb-16"></div>
|
||||
@@ -0,0 +1,8 @@
|
||||
<div class="fixed bottom-0 left-0 bg-neutral-900 p-3 w-full border-t border-cyan-500">
|
||||
<div class="mx-auto flex justify-center space-x-6 text-gray-400">
|
||||
{{ range .Site.Params.navs }}
|
||||
<a class="underline decoration-cyan-500 hover:decoration-pink-500 text-xl" href="{{ .link | safeURL }}">{{ .name
|
||||
}}</a>
|
||||
{{ end }}
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,28 @@
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title itemprop="name">{{ if .IsHome }}{{ site.Title }}{{ else }}{{ printf "%s | %s" .Title site.Title }}{{ end }}
|
||||
</title>
|
||||
{{ if eq .Section "posts" }}
|
||||
<meta property="og:title" content="{{ .Title }} | {{ .Site.Title }}" />
|
||||
<meta name="twitter:title" content="{{ .Title }} | {{ .Site.Title }}" />
|
||||
<meta itemprop="name" content="{{ .Title }} | {{ .Site.Title }}" />
|
||||
<meta name="application-name" content="{{ .Title }} | {{ .Site.Title }}" />
|
||||
<meta property="og:site_name" content="{{ .Site.Params.sitename }}" />
|
||||
<meta name="description" content="{{ .Params.description }}" />
|
||||
<meta itemprop="description" content="{{ .Params.description }}" />
|
||||
<meta property="og:description" content="{{ .Params.description }}" />
|
||||
<meta name="twitter:description" content="{{ .Params.description }}" />
|
||||
{{ with .Params.image }}
|
||||
<meta itemprop="image" content="{{ . | absURL }}" />
|
||||
<meta property="og:image" content="{{ . | absURL }}" />
|
||||
<meta name="twitter:image" content="{{ . | absURL }}" />
|
||||
<meta name="twitter:image:src" content="{{ . | absURL }}" />
|
||||
{{ else }}
|
||||
<meta itemprop="image" content="{{ .Site.Params.ogimage | absURL }}" />
|
||||
<meta property="og:image" content="{{ .Site.Params.ogimage | absURL }}" />
|
||||
<meta name="twitter:image" content="{{ .Site.Params.ogimage | absURL }}" />
|
||||
<meta name="twitter:image:src" content="{{ .Site.Params.ogimage | absURL }}" />
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
{{ partialCached "head/css.html" . }}
|
||||
{{ partialCached "head/js.html" . }}
|
||||
@@ -0,0 +1,9 @@
|
||||
{{- with resources.Get "css/main.css" }}
|
||||
{{- if eq hugo.Environment "development" }}
|
||||
<link rel="stylesheet" href="{{ .RelPermalink }}">
|
||||
{{- else }}
|
||||
{{- with . | minify | fingerprint }}
|
||||
<link rel="stylesheet" href="{{ .RelPermalink }}" integrity="{{ .Data.Integrity }}" crossorigin="anonymous">
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
@@ -0,0 +1,12 @@
|
||||
{{- with resources.Get "js/main.js" }}
|
||||
{{- if eq hugo.Environment "development" }}
|
||||
{{- with . | js.Build }}
|
||||
<script src="{{ .RelPermalink }}"></script>
|
||||
{{- end }}
|
||||
{{- else }}
|
||||
{{- $opts := dict "minify" true }}
|
||||
{{- with . | js.Build $opts | fingerprint }}
|
||||
<script src="{{ .RelPermalink }}" integrity="{{- .Data.Integrity }}" crossorigin="anonymous"></script>
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
@@ -0,0 +1,25 @@
|
||||
<header class="relative">
|
||||
<img class="object-cover w-full h-60 sm:h-96 brightness-50" src="{{ .Params.Image | absURL }}" alt="{{ .Title }}">
|
||||
<h1 class="absolute top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2 text-center w-full text-white">{{ .Title }}</h1>
|
||||
|
||||
<span class="absolute bottom-1/4 left-1/2 -translate-x-1/2 text-base font-sans oldstyle-nums text-center w-full">
|
||||
<a class="font-bold no-underline hover:text-pink-500" href="/">Avinal Kumar</a>
|
||||
|
|
||||
{{ $dateMachine := .Date | time.Format "2006-01-02T15:04:05-07:00" }}
|
||||
{{ $dateHuman := .Date | time.Format ":date_long" }}
|
||||
<time datetime="{{ $dateMachine }}">{{ $dateHuman }}</time>
|
||||
{{ if .Site.Params.showWordCount }}
|
||||
<span>| {{ .WordCount }} words</span>
|
||||
{{ end }}
|
||||
|
||||
{{ if gt .ReadingTime 1 }}
|
||||
{{ .Scratch.Set "timeUnit" "mins" }}
|
||||
{{ else }}
|
||||
{{ .Scratch.Set "timeUnit" "min" }}
|
||||
{{ end }}
|
||||
|
||||
{{ if .Site.Params.showReadingTime }}
|
||||
<span>| ~{{.ReadingTime}} {{ .Scratch.Get "timeUnit" }}</span>
|
||||
{{ end }}
|
||||
</span>
|
||||
</header>
|
||||
@@ -0,0 +1,51 @@
|
||||
{{- /*
|
||||
Renders a menu for the given menu ID.
|
||||
|
||||
@context {page} page The current page.
|
||||
@context {string} menuID The menu ID.
|
||||
|
||||
@example: {{ partial "menu.html" (dict "menuID" "main" "page" .) }}
|
||||
*/}}
|
||||
|
||||
{{- $page := .page }}
|
||||
{{- $menuID := .menuID }}
|
||||
|
||||
{{- with index site.Menus $menuID }}
|
||||
<nav>
|
||||
<ul>
|
||||
{{- partial "inline/menu/walk.html" (dict "page" $page "menuEntries" .) }}
|
||||
</ul>
|
||||
</nav>
|
||||
{{- end }}
|
||||
|
||||
{{- define "partials/inline/menu/walk.html" }}
|
||||
{{- $page := .page }}
|
||||
{{- range .menuEntries }}
|
||||
{{- $attrs := dict "href" .URL }}
|
||||
{{- if $page.IsMenuCurrent .Menu . }}
|
||||
{{- $attrs = merge $attrs (dict "class" "active" "aria-current" "page") }}
|
||||
{{- else if $page.HasMenuCurrent .Menu .}}
|
||||
{{- $attrs = merge $attrs (dict "class" "ancestor" "aria-current" "true") }}
|
||||
{{- end }}
|
||||
{{- $name := .Name }}
|
||||
{{- with .Identifier }}
|
||||
{{- with T . }}
|
||||
{{- $name = . }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
<li>
|
||||
<a
|
||||
{{- range $k, $v := $attrs }}
|
||||
{{- with $v }}
|
||||
{{- printf " %s=%q" $k $v | safeHTMLAttr }}
|
||||
{{- end }}
|
||||
{{- end -}}
|
||||
>{{ $name }}</a>
|
||||
{{- with .Children }}
|
||||
<ul>
|
||||
{{- partial "inline/menu/walk.html" (dict "page" $page "menuEntries" .) }}
|
||||
</ul>
|
||||
{{- end }}
|
||||
</li>
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
@@ -0,0 +1,22 @@
|
||||
{{- /*
|
||||
For a given taxonomy, renders a list of terms assigned to the page.
|
||||
|
||||
@context {page} page The current page.
|
||||
@context {string} taxonomy The taxonony.
|
||||
|
||||
@example: {{ partial "terms.html" (dict "taxonomy" "tags" "page" .) }}
|
||||
*/}}
|
||||
|
||||
{{- $page := .page }}
|
||||
{{- $taxonomy := .taxonomy }}
|
||||
|
||||
{{- with $page.GetTerms $taxonomy }}
|
||||
{{- $label := (index . 0).Parent.LinkTitle }}
|
||||
<span class="flex flex-wrap py-6 space-x-2 border-t border-gray-500">
|
||||
<!-- <a class="px-3 py-1 m-1 rounded-sm hover:underline bg-pink-400 text-gray-900 font-bold" href="/category/"></a> -->
|
||||
{{- range . }}
|
||||
<a class="px-3 py-1 m-1 rounded-sm bg-cyan-500 text-gray-900" href="{{ .RelativeLink }}">#{{ .LinkTitle }}</a>
|
||||
{{- end }}
|
||||
</span>
|
||||
{{- end }}
|
||||
|
||||
Vendored
+545
@@ -0,0 +1,545 @@
|
||||
/*
|
||||
! tailwindcss v3.3.6 | MIT License | https://tailwindcss.com
|
||||
*/
|
||||
|
||||
/*
|
||||
1. Prevent padding and border from affecting element width. (https://github.com/mozdevs/cssremedy/issues/4)
|
||||
2. Allow adding a border to an element by just adding a border-width. (https://github.com/tailwindcss/tailwindcss/pull/116)
|
||||
*/
|
||||
|
||||
*,
|
||||
::before,
|
||||
::after {
|
||||
box-sizing: border-box;
|
||||
/* 1 */
|
||||
border-width: 0;
|
||||
/* 2 */
|
||||
border-style: solid;
|
||||
/* 2 */
|
||||
border-color: #e5e7eb;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
::before,
|
||||
::after {
|
||||
--tw-content: '';
|
||||
}
|
||||
|
||||
/*
|
||||
1. Use a consistent sensible line-height in all browsers.
|
||||
2. Prevent adjustments of font size after orientation changes in iOS.
|
||||
3. Use a more readable tab size.
|
||||
4. Use the user's configured `sans` font-family by default.
|
||||
5. Use the user's configured `sans` font-feature-settings by default.
|
||||
6. Use the user's configured `sans` font-variation-settings by default.
|
||||
*/
|
||||
|
||||
html {
|
||||
line-height: 1.5;
|
||||
/* 1 */
|
||||
-webkit-text-size-adjust: 100%;
|
||||
/* 2 */
|
||||
-moz-tab-size: 4;
|
||||
/* 3 */
|
||||
-o-tab-size: 4;
|
||||
tab-size: 4;
|
||||
/* 3 */
|
||||
font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
|
||||
/* 4 */
|
||||
font-feature-settings: normal;
|
||||
/* 5 */
|
||||
font-variation-settings: normal;
|
||||
/* 6 */
|
||||
}
|
||||
|
||||
/*
|
||||
1. Remove the margin in all browsers.
|
||||
2. Inherit line-height from `html` so users can set them as a class directly on the `html` element.
|
||||
*/
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
/* 1 */
|
||||
line-height: inherit;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
1. Add the correct height in Firefox.
|
||||
2. Correct the inheritance of border color in Firefox. (https://bugzilla.mozilla.org/show_bug.cgi?id=190655)
|
||||
3. Ensure horizontal rules are visible by default.
|
||||
*/
|
||||
|
||||
hr {
|
||||
height: 0;
|
||||
/* 1 */
|
||||
color: inherit;
|
||||
/* 2 */
|
||||
border-top-width: 1px;
|
||||
/* 3 */
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct text decoration in Chrome, Edge, and Safari.
|
||||
*/
|
||||
|
||||
abbr:where([title]) {
|
||||
-webkit-text-decoration: underline dotted;
|
||||
text-decoration: underline dotted;
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the default font size and weight for headings.
|
||||
*/
|
||||
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6 {
|
||||
font-size: inherit;
|
||||
font-weight: inherit;
|
||||
}
|
||||
|
||||
/*
|
||||
Reset links to optimize for opt-in styling instead of opt-out.
|
||||
*/
|
||||
|
||||
a {
|
||||
color: inherit;
|
||||
text-decoration: inherit;
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct font weight in Edge and Safari.
|
||||
*/
|
||||
|
||||
b,
|
||||
strong {
|
||||
font-weight: bolder;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Use the user's configured `mono` font-family by default.
|
||||
2. Use the user's configured `mono` font-feature-settings by default.
|
||||
3. Use the user's configured `mono` font-variation-settings by default.
|
||||
4. Correct the odd `em` font sizing in all browsers.
|
||||
*/
|
||||
|
||||
code,
|
||||
kbd,
|
||||
samp,
|
||||
pre {
|
||||
font-family: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace;
|
||||
/* 1 */
|
||||
font-feature-settings: normal;
|
||||
/* 2 */
|
||||
font-variation-settings: normal;
|
||||
/* 3 */
|
||||
font-size: 1em;
|
||||
/* 4 */
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct font size in all browsers.
|
||||
*/
|
||||
|
||||
small {
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
/*
|
||||
Prevent `sub` and `sup` elements from affecting the line height in all browsers.
|
||||
*/
|
||||
|
||||
sub,
|
||||
sup {
|
||||
font-size: 75%;
|
||||
line-height: 0;
|
||||
position: relative;
|
||||
vertical-align: baseline;
|
||||
}
|
||||
|
||||
sub {
|
||||
bottom: -0.25em;
|
||||
}
|
||||
|
||||
sup {
|
||||
top: -0.5em;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Remove text indentation from table contents in Chrome and Safari. (https://bugs.chromium.org/p/chromium/issues/detail?id=999088, https://bugs.webkit.org/show_bug.cgi?id=201297)
|
||||
2. Correct table border color inheritance in all Chrome and Safari. (https://bugs.chromium.org/p/chromium/issues/detail?id=935729, https://bugs.webkit.org/show_bug.cgi?id=195016)
|
||||
3. Remove gaps between table borders by default.
|
||||
*/
|
||||
|
||||
table {
|
||||
text-indent: 0;
|
||||
/* 1 */
|
||||
border-color: inherit;
|
||||
/* 2 */
|
||||
border-collapse: collapse;
|
||||
/* 3 */
|
||||
}
|
||||
|
||||
/*
|
||||
1. Change the font styles in all browsers.
|
||||
2. Remove the margin in Firefox and Safari.
|
||||
3. Remove default padding in all browsers.
|
||||
*/
|
||||
|
||||
button,
|
||||
input,
|
||||
optgroup,
|
||||
select,
|
||||
textarea {
|
||||
font-family: inherit;
|
||||
/* 1 */
|
||||
font-feature-settings: inherit;
|
||||
/* 1 */
|
||||
font-variation-settings: inherit;
|
||||
/* 1 */
|
||||
font-size: 100%;
|
||||
/* 1 */
|
||||
font-weight: inherit;
|
||||
/* 1 */
|
||||
line-height: inherit;
|
||||
/* 1 */
|
||||
color: inherit;
|
||||
/* 1 */
|
||||
margin: 0;
|
||||
/* 2 */
|
||||
padding: 0;
|
||||
/* 3 */
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the inheritance of text transform in Edge and Firefox.
|
||||
*/
|
||||
|
||||
button,
|
||||
select {
|
||||
text-transform: none;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Correct the inability to style clickable types in iOS and Safari.
|
||||
2. Remove default button styles.
|
||||
*/
|
||||
|
||||
button,
|
||||
[type='button'],
|
||||
[type='reset'],
|
||||
[type='submit'] {
|
||||
-webkit-appearance: button;
|
||||
/* 1 */
|
||||
background-color: transparent;
|
||||
/* 2 */
|
||||
background-image: none;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Use the modern Firefox focus style for all focusable elements.
|
||||
*/
|
||||
|
||||
:-moz-focusring {
|
||||
outline: auto;
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the additional `:invalid` styles in Firefox. (https://github.com/mozilla/gecko-dev/blob/2f9eacd9d3d995c937b4251a5557d95d494c9be1/layout/style/res/forms.css#L728-L737)
|
||||
*/
|
||||
|
||||
:-moz-ui-invalid {
|
||||
box-shadow: none;
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct vertical alignment in Chrome and Firefox.
|
||||
*/
|
||||
|
||||
progress {
|
||||
vertical-align: baseline;
|
||||
}
|
||||
|
||||
/*
|
||||
Correct the cursor style of increment and decrement buttons in Safari.
|
||||
*/
|
||||
|
||||
::-webkit-inner-spin-button,
|
||||
::-webkit-outer-spin-button {
|
||||
height: auto;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Correct the odd appearance in Chrome and Safari.
|
||||
2. Correct the outline style in Safari.
|
||||
*/
|
||||
|
||||
[type='search'] {
|
||||
-webkit-appearance: textfield;
|
||||
/* 1 */
|
||||
outline-offset: -2px;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Remove the inner padding in Chrome and Safari on macOS.
|
||||
*/
|
||||
|
||||
::-webkit-search-decoration {
|
||||
-webkit-appearance: none;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Correct the inability to style clickable types in iOS and Safari.
|
||||
2. Change font properties to `inherit` in Safari.
|
||||
*/
|
||||
|
||||
::-webkit-file-upload-button {
|
||||
-webkit-appearance: button;
|
||||
/* 1 */
|
||||
font: inherit;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Add the correct display in Chrome and Safari.
|
||||
*/
|
||||
|
||||
summary {
|
||||
display: list-item;
|
||||
}
|
||||
|
||||
/*
|
||||
Removes the default spacing and border for appropriate elements.
|
||||
*/
|
||||
|
||||
blockquote,
|
||||
dl,
|
||||
dd,
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
hr,
|
||||
figure,
|
||||
p,
|
||||
pre {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
fieldset {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
legend {
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
ol,
|
||||
ul,
|
||||
menu {
|
||||
list-style: none;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
/*
|
||||
Reset default styling for dialogs.
|
||||
*/
|
||||
|
||||
dialog {
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
/*
|
||||
Prevent resizing textareas horizontally by default.
|
||||
*/
|
||||
|
||||
textarea {
|
||||
resize: vertical;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Reset the default placeholder opacity in Firefox. (https://github.com/tailwindlabs/tailwindcss/issues/3300)
|
||||
2. Set the default placeholder color to the user's configured gray 400 color.
|
||||
*/
|
||||
|
||||
input::-moz-placeholder, textarea::-moz-placeholder {
|
||||
opacity: 1;
|
||||
/* 1 */
|
||||
color: #9ca3af;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
input::placeholder,
|
||||
textarea::placeholder {
|
||||
opacity: 1;
|
||||
/* 1 */
|
||||
color: #9ca3af;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Set the default cursor for buttons.
|
||||
*/
|
||||
|
||||
button,
|
||||
[role="button"] {
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
/*
|
||||
Make sure disabled buttons don't get the pointer cursor.
|
||||
*/
|
||||
|
||||
:disabled {
|
||||
cursor: default;
|
||||
}
|
||||
|
||||
/*
|
||||
1. Make replaced elements `display: block` by default. (https://github.com/mozdevs/cssremedy/issues/14)
|
||||
2. Add `vertical-align: middle` to align replaced elements more sensibly by default. (https://github.com/jensimmons/cssremedy/issues/14#issuecomment-634934210)
|
||||
This can trigger a poorly considered lint error in some tools but is included by design.
|
||||
*/
|
||||
|
||||
img,
|
||||
svg,
|
||||
video,
|
||||
canvas,
|
||||
audio,
|
||||
iframe,
|
||||
embed,
|
||||
object {
|
||||
display: block;
|
||||
/* 1 */
|
||||
vertical-align: middle;
|
||||
/* 2 */
|
||||
}
|
||||
|
||||
/*
|
||||
Constrain images and videos to the parent width and preserve their intrinsic aspect ratio. (https://github.com/mozdevs/cssremedy/issues/14)
|
||||
*/
|
||||
|
||||
img,
|
||||
video {
|
||||
max-width: 100%;
|
||||
height: auto;
|
||||
}
|
||||
|
||||
/* Make elements with the HTML hidden attribute stay hidden by default */
|
||||
|
||||
[hidden] {
|
||||
display: none;
|
||||
}
|
||||
|
||||
*, ::before, ::after {
|
||||
--tw-border-spacing-x: 0;
|
||||
--tw-border-spacing-y: 0;
|
||||
--tw-translate-x: 0;
|
||||
--tw-translate-y: 0;
|
||||
--tw-rotate: 0;
|
||||
--tw-skew-x: 0;
|
||||
--tw-skew-y: 0;
|
||||
--tw-scale-x: 1;
|
||||
--tw-scale-y: 1;
|
||||
--tw-pan-x: ;
|
||||
--tw-pan-y: ;
|
||||
--tw-pinch-zoom: ;
|
||||
--tw-scroll-snap-strictness: proximity;
|
||||
--tw-gradient-from-position: ;
|
||||
--tw-gradient-via-position: ;
|
||||
--tw-gradient-to-position: ;
|
||||
--tw-ordinal: ;
|
||||
--tw-slashed-zero: ;
|
||||
--tw-numeric-figure: ;
|
||||
--tw-numeric-spacing: ;
|
||||
--tw-numeric-fraction: ;
|
||||
--tw-ring-inset: ;
|
||||
--tw-ring-offset-width: 0px;
|
||||
--tw-ring-offset-color: #fff;
|
||||
--tw-ring-color: rgb(59 130 246 / 0.5);
|
||||
--tw-ring-offset-shadow: 0 0 #0000;
|
||||
--tw-ring-shadow: 0 0 #0000;
|
||||
--tw-shadow: 0 0 #0000;
|
||||
--tw-shadow-colored: 0 0 #0000;
|
||||
--tw-blur: ;
|
||||
--tw-brightness: ;
|
||||
--tw-contrast: ;
|
||||
--tw-grayscale: ;
|
||||
--tw-hue-rotate: ;
|
||||
--tw-invert: ;
|
||||
--tw-saturate: ;
|
||||
--tw-sepia: ;
|
||||
--tw-drop-shadow: ;
|
||||
--tw-backdrop-blur: ;
|
||||
--tw-backdrop-brightness: ;
|
||||
--tw-backdrop-contrast: ;
|
||||
--tw-backdrop-grayscale: ;
|
||||
--tw-backdrop-hue-rotate: ;
|
||||
--tw-backdrop-invert: ;
|
||||
--tw-backdrop-opacity: ;
|
||||
--tw-backdrop-saturate: ;
|
||||
--tw-backdrop-sepia: ;
|
||||
}
|
||||
|
||||
::backdrop {
|
||||
--tw-border-spacing-x: 0;
|
||||
--tw-border-spacing-y: 0;
|
||||
--tw-translate-x: 0;
|
||||
--tw-translate-y: 0;
|
||||
--tw-rotate: 0;
|
||||
--tw-skew-x: 0;
|
||||
--tw-skew-y: 0;
|
||||
--tw-scale-x: 1;
|
||||
--tw-scale-y: 1;
|
||||
--tw-pan-x: ;
|
||||
--tw-pan-y: ;
|
||||
--tw-pinch-zoom: ;
|
||||
--tw-scroll-snap-strictness: proximity;
|
||||
--tw-gradient-from-position: ;
|
||||
--tw-gradient-via-position: ;
|
||||
--tw-gradient-to-position: ;
|
||||
--tw-ordinal: ;
|
||||
--tw-slashed-zero: ;
|
||||
--tw-numeric-figure: ;
|
||||
--tw-numeric-spacing: ;
|
||||
--tw-numeric-fraction: ;
|
||||
--tw-ring-inset: ;
|
||||
--tw-ring-offset-width: 0px;
|
||||
--tw-ring-offset-color: #fff;
|
||||
--tw-ring-color: rgb(59 130 246 / 0.5);
|
||||
--tw-ring-offset-shadow: 0 0 #0000;
|
||||
--tw-ring-shadow: 0 0 #0000;
|
||||
--tw-shadow: 0 0 #0000;
|
||||
--tw-shadow-colored: 0 0 #0000;
|
||||
--tw-blur: ;
|
||||
--tw-brightness: ;
|
||||
--tw-contrast: ;
|
||||
--tw-grayscale: ;
|
||||
--tw-hue-rotate: ;
|
||||
--tw-invert: ;
|
||||
--tw-saturate: ;
|
||||
--tw-sepia: ;
|
||||
--tw-drop-shadow: ;
|
||||
--tw-backdrop-blur: ;
|
||||
--tw-backdrop-brightness: ;
|
||||
--tw-backdrop-contrast: ;
|
||||
--tw-backdrop-grayscale: ;
|
||||
--tw-backdrop-hue-rotate: ;
|
||||
--tw-backdrop-invert: ;
|
||||
--tw-backdrop-opacity: ;
|
||||
--tw-backdrop-saturate: ;
|
||||
--tw-backdrop-sepia: ;
|
||||
}
|
||||
|
||||
.block {
|
||||
display: block;
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 952 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.6 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 721 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 521 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 242 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 210 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 117 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.0 KiB |
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 257 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 617 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 395 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 847 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 657 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 645 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1001 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 613 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 193 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 166 KiB |
@@ -0,0 +1,3 @@
|
||||
@tailwind base;
|
||||
@tailwind components;
|
||||
@tailwind utilities;
|
||||
@@ -0,0 +1,10 @@
|
||||
/** @type {import('tailwindcss').Config} */
|
||||
module.exports = {
|
||||
content: ["../content/**/*.md", "../layouts/**/*.html"],
|
||||
theme: {
|
||||
extend: {},
|
||||
},
|
||||
// darkMode: 'class',
|
||||
plugins: [require("@tailwindcss/typography")],
|
||||
}
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
name: Space Bar
|
||||
license: MIT
|
||||
licenselink: 'https://github.com/owner/repo/LICENSE'
|
||||
description: Theme description
|
||||
homepage: 'https://github.com/owner/repo'
|
||||
demosite: 'https://owner.github.io/repo'
|
||||
tags:
|
||||
- blog
|
||||
- company
|
||||
features:
|
||||
- some
|
||||
- awesome
|
||||
- features
|
||||
author:
|
||||
name: Avinal Kumar
|
||||
homepage: 'https://avinal.space'
|
||||
original:
|
||||
author: Name of original author
|
||||
homepage: Website of original author
|
||||
repo: 'https://github.com/owner/repo'
|
||||
Reference in New Issue
Block a user