chozorho | I'm no LUKS expert, but, it sounds perfectly reasonable that your results would vary a bit from one person's machine to another | 00:09 |
---|---|---|
chozorho | how many "slots" are enabled on your machine? | 00:09 |
chozorho | ahh wait, it seems like the output format has changed since then, hasn't it... | 00:11 |
chozorho | when I run luksDump, it doesn't print out "slots", it just gives the uhh | 00:11 |
chozorho | yea, try running the same command but don't pipe it through grep | 00:12 |
chozorho | you can see a section about "Keyslots" among other things | 00:12 |
hyrc | Wayback machine / archive.org has bent the knee to the ... and have announced that they will begin going back through the archives to 'fact check' data that is 'bad' | 01:04 |
error144 | golinux your idea, of using refracsnapshot FAILED!!! | 07:57 |
error144 | :( | 07:57 |
error144 | rrq good morning! remember me? I am the same guy that tried to use the installer-iso for 5 days already. | 07:58 |
error144 | I have been playing around with the script, changing parameters here and there, but I never managed to make it use install certain packages, infact it seems like there is no way to do it, its either all or none, if you use the commend "make ISO=$ISO" that is found in the git README, it will ask for udeb files, I want to give that a try, but I didn't found where to put these udeb files? any suggestions? | 08:02 |
rrq | do you want the iso to carry certain more packages in its pool? or that it uses some certain udebs into the installer itself? | 08:23 |
error144 | rrq if you mean the netinstall then I want more, if you mean the desktop iso, then I want less, | 08:26 |
error144 | in other words, I want to have full control over what gets in and what not!! | 08:27 |
rrq | ok, you are talking about the pool of packages included on the iso | 08:27 |
error144 | OK, before I answer that, could you explain more about what do you mean by 'pool of packages', the only time I heard about 'pool' is from the README file | 08:28 |
rrq | the iso is a file structure that contains the installer (program) as a small kernel+initrd, and a package repository layed out with a "pool" doirectory tree of packages and a "dists" directory tree with "index files" | 08:31 |
error144 | so the pool directory will have packages for the installer to use during installation? | 08:32 |
error144 | also are the "index files" the files that appears on root directory '/'? | 08:33 |
error144 | rrq tag | 08:34 |
rrq | yes+no, the pool is a package repository. The installer will pull in packages from it for itself as part of the installation run, and it will also pull packages from there to install into the target | 08:34 |
rrq | the iso contains a dists/ directory tree; all the same as any debian repository | 08:35 |
rrq | the packages it installs into the target are firstly determined by the initial debootstrap, which uses the --minbase parameter | 08:36 |
error144 | okeeeeeey, but where does it know what 'packages' to pull in or out? | 08:37 |
error144 | for example, I did 'grep -rwn '.' -e 'gnome'' in order to disable downloading gnome during desktop ISO | 08:37 |
error144 | and I didn't found any gnome word in the whole script, so how does it know that "we want gnome"? | 08:38 |
rrq | right; firstly the --minbase option to debootstrap, secondly it's du to itself installing the pkgsel udeb, which causes tasksel to be installed into the target | 08:39 |
rrq | I fon't think gnome is on any iso except possibly the additional pool-only isos | 08:42 |
rrq | don't | 08:42 |
error144 | the minbase file has packages that every distro must have, so what's inside it is fine for me, but where are the 1000s of packages that get downloaded druning the second phase of the building? | 08:42 |
error144 | speaking of phases, during my testing for the script I noticed that it works like this: first it install key packages for chroot to work, then it download many packages that I don't need nor use, then it starts building. | 08:43 |
error144 | and everytime I run the script it does that again, and it slows me down, I managed however to speed it up a little by masking "Clean up prior building" in the build-sudo.sh | 08:44 |
error144 | however this only stops the first phase, the second phase of downloading packages is still there, and until now I didn't found how to stop it from getting deleted so it doesn't reddownload it everytime I edit the script! | 08:45 |
rrq | the first phase builds a file system that constitutes a full ISO build system, and it needs packages for itself that are not in the installer | 08:46 |
error144 | yah, and how can I stop the packages of the second phase from being deleted? | 08:47 |
error144 | or 'cleaned'? | 08:47 |
rrq | that second phase is used for preparing the installer initramfs | 08:48 |
error144 | and how to edit that? | 08:49 |
rrq | the easiest is way of dealing with the "downloading again" issue to set up a package cacher | 08:50 |
rrq | then run with: "http_proxy=http://localhost:3142 ./build-sudo.sh" (or similar) | 08:51 |
error144 | @_@ its 'easier' to said then done, I am hearing some new words here, each one can take weeks to learn. | 08:52 |
rrq | I'm using "apt-cacher-ng" | 08:53 |
error144 | then what? simply run it? | 08:55 |
rrq | yes, it's a daemon. it then sits on the transport line when packages are downloaded to cache them locally and serve that instead of downloading anew | 08:55 |
error144 | ok, lets give it a try | 08:56 |
rrq | then, the list of udebs that constitute the installer initrd is enumerated in "udeb-sets.mk.tmpl" | 08:58 |
rrq | that gets expanded with its dependencies, and all that gets unpacked to form the initrd file system | 08:59 |
rrq | the iso's package pool is prepared by the setup in the "installer-iso/pool" directory | 09:00 |
rrq | that setup prepares the list of which packages the ISO pool should contain | 09:02 |
error144 | rrq I have checked almost everything in the pool folder, it is so unclear where all of these happens! | 09:03 |
rrq | well, it merely prepares the list of packages. when you go into that directory and command: make ISO=NETINSTALL, it will prepare the list for NETINSTALL | 09:04 |
rrq | that includes a) grab all current Packages file and split them up into the individual package description files for each package that the builder knows about, b) | 09:05 |
error144 | it indeed created a file titled NETINSTALL_LIST_amd64 and it is full of commented packages names with word 'unknown' | 09:06 |
rrq | process the seeding lists that enumerates the packages the iso should contain by expanding with all their dependencies and recommends | 09:06 |
rrq | when you check the NETINSTALL_LIST_amd64 target you'll see which the seeding lists are | 09:07 |
error144 | you mean everything in this file is going to be in the iso? | 09:08 |
rrq | the resulting list file has comments and then uncommented package names, all of which are going into the iso pool | 09:09 |
error144 | ok that's make it clear now | 09:09 |
error144 | rrq how about editing the chroot folder? | 09:09 |
error144 | lets say I want to have a file in /usr/share titled "devuan_killed_systemD.txt" how am I going to add this? | 09:10 |
error144 | as far as my tries, the chroot folder get cleard as soon as you run the script again | 09:10 |
rrq | I would add to build-sudo.sh, before the "# Build all" comment; a command to copy in that into the now prepared chroot file system | 09:14 |
error144 | fair, I can handle that. | 09:15 |
error144 | so how about adding a premade user? | 09:15 |
error144 | during devuan installation, it asks you to make a user that is not root, and IT FORCES YOU TO DO IT, and also forces you to chose what password the root has, any suggestion about avoiding that? | 09:16 |
rrq | the list file pool/installer-menu is set up to illustrate the installation process by vertue of ordering the udebs according to their Installer-Menu ordinal | 09:18 |
rrq | according to that I'm guessing you might want to patch user-setup-udeb | 09:19 |
error144 | by commenting it ;) | 09:21 |
rrq | I'm not fully clear about which of the forced udebs mentioned in udeb-sets.mk.tmpl that causes the installer to later (want to) install user-setup-udeb | 09:23 |
rrq | mentioning it in installer-menu is rather a matter of tell the pool formation to have it available | 09:23 |
rrq | telling | 09:23 |
error144 | rrq sorry but, may I ask: are you the one who created this script? | 09:24 |
error144 | yesterday I said that you seem to be the only one in this earth who knows how to make this script work. | 09:25 |
rrq | the building as a whole uses debconf in the same way as debian-installer but with less flexibility in varying the set up for different architectures | 09:27 |
error144 | I found debian-installer document, comparing it with this script I almost found 0 similarity. | 09:28 |
error144 | however this tool seem simpler | 09:29 |
error144 | could be because I have been using it for 5 days! | 09:29 |
rrq | if you want to know everything about every thing involves in the iso building than you might be looking at a couple of days more | 09:31 |
error144 | the problem is not about me giving more days learning this tool, it is about if you are online and wanting to help or not. | 09:32 |
error144 | otherwise this tool is unknowable | 09:32 |
error144 | I have tried http_proxy=http://localhost:3142 ./build-sudo.sh chimaera netinstall 4.0 | 09:35 |
error144 | didn't work | 09:35 |
error144 | could it be because of the port? | 09:35 |
rrq | which port is your cacher serving on? | 09:35 |
error144 | how to tell? | 09:36 |
rrq | eithr look into its configuration or check with netstat or ss | 09:36 |
rrq | eg netstat -anp | grep cacher | 09:37 |
error144 | seem ok, tcp port is 3142 as yours | 09:39 |
rrq | try with an "export http_proxy" beforehand | 09:40 |
error144 | same result | 09:43 |
error144 | in fact that was expected | 09:43 |
rrq | ok. what's the error message? | 09:44 |
* rrq short break. biab | 09:44 | |
error144 | no address associated with hostname | 09:46 |
error144_ | I were disconnected? rrq did you sent any message? | 09:58 |
rrq | no, just back | 10:03 |
rrq | you may need to either declare an entry in /etc/hosts or use the IP 127.0.0.1 instead of localhost | 10:04 |
rrq | that's for making http_proxy to work | 10:06 |
error144_ | lets give that a try | 10:12 |
rrq | ther has come a recollection from the depth of the fog, that the installer-menu looks for all packages with an Installer-Menu tag, to know which ones to install, so commenting out user-setup-udeb would work insofar as to not use that udeb during the installation. | 10:17 |
rrq | that particular step is slightly different during an expert install as it then lets you skip setting up root and/or user. | 10:18 |
rrq | I don't know if the udeb includes other things that possibly are more essential, e.g. setting up passwd and groups more generally | 10:19 |
rrq | any such baby goes with the bath water if you comment out the udeb | 10:20 |
error144_ | rrq It is not the first time I destroy a distro because of a package, as long as I know what I am doing, it is fine, its about testing and checking | 10:26 |
error144_ | rrq your apt-cache idea worked!! | 10:28 |
error144_ | it is now 50x faster then before!! | 10:29 |
error144_ | this will help debugging changes | 10:29 |
rrq | great. then it's a matter of messing with the list seeding lists I guess | 10:30 |
rrq | unless you want to add your very own iso type | 10:30 |
error144_ | !!! | 10:30 |
error144_ | can I add my own iso type? | 10:30 |
rrq | sure.. not too hard | 10:31 |
error144_ | show me !!! | 10:31 |
rrq | invent a name to being with | 10:31 |
error144_ | ok nightinst | 10:31 |
error144_ | next | 10:31 |
rrq | then you'll preapre a "nightinst.mk" makefile include similar to, say, netinstall.mk | 10:32 |
rrq | prepare | 10:32 |
* critr wants to being with sheila | 10:32 | |
error144_ | nano nightinst.mk, so what should I put in? | 10:33 |
rrq | copy netinstall.mk | 10:33 |
rrq | change the POOL line to identify your pool name; could be the uppercase version of you want to follow the style | 10:34 |
error144_ | should I copy netinstall and change the POOL? | 10:34 |
rrq | yes .. you're ahead of me :) | 10:34 |
error144_ | rrq nah, got disconnected xD | 10:34 |
error144_ | done | 10:34 |
error144_ | what next? | 10:34 |
rrq | the edit pool/Makefile to add the making of the list similar to NETINSTALL_LIST... | 10:35 |
rrq | 5 lines including the comment above and the blank line below | 10:35 |
rrq | and replace the all-* seeding lists with one of your own | 10:36 |
rrq | I mean, change that line mentioning them | 10:37 |
error144_ | like all-nightinst ? | 10:37 |
rrq | yes that should be fine; any filenmae not in use I suppose | 10:39 |
error144_ | done | 10:40 |
error144_ | next | 10:40 |
rrq | a thought: note that the other all-* seeding lists are generated, so maybe cleaning will delete your all-nightinst | 10:40 |
rrq | perhaps just nightinst is better | 10:41 |
error144_ | fine, done | 10:41 |
error144_ | next | 10:41 |
rrq | if that file exists, then it's just a matter of building that rather than netinstall | 10:41 |
error144_ | it doesn't, lets create one | 10:42 |
rrq | that file would be a list of packages mixed with comment lines | 10:42 |
error144_ | so how to do it? | 10:42 |
error144_ | yes yes, where to create it? this is start to get clearer! | 10:42 |
rrq | in pool/ | 10:43 |
error144_ | I don't see netinstall to use it as a reference? | 10:43 |
rrq | check the POOL line of netinstall.mk | 10:44 |
rrq | sorry | 10:44 |
error144_ | it says POOL += NETINSTALL | 10:44 |
error144_ | so? | 10:44 |
rrq | sorry, mine was a good answer to a different question | 10:44 |
error144_ | no problem. | 10:45 |
error144_ | what's next? | 10:45 |
rrq | NETINSTALL_LIST_amd64 is built using the seed files named in ${INSTALLER} and all-require and all-mportant, where those latter two are generated | 10:46 |
rrq | the ${INSTALLER} files are defied on line 14 in the Makefile | 10:47 |
rrq | and each of those files is a seeding file | 10:47 |
rrq | your nightinst file would be a series of package names and comments | 10:48 |
error144_ | rrq like simply create a file titled nightinst, and fill it with package names in order for them to get added in the iso? | 10:49 |
rrq | yes | 10:49 |
error144_ | hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm | 10:49 |
rrq | the iso building will follow up all dependencies and recommends and include those as well | 10:50 |
error144_ | can I disable 'recommends'? | 10:50 |
error144_ | remember my target is to make a minimal distro, no need for these recommends packages | 10:50 |
rrq | mmm in that case you might need the package list file to be in two parts: the first part that includes recommends, for the installer itself and the second part for the no-recommends of additional packages, .. or | 10:53 |
rrq | you can work out which recommends the installer relies on and then totally disable following up recommends in the dependecy traversal | 10:53 |
error144_ | rrq that can take ages! | 10:54 |
rrq | yes. a fair few days I'd think | 10:56 |
rrq | a two step list building is not very hard though | 10:57 |
error144_ | ok do you have an example on this two step listing idea? | 10:57 |
rrq | you know how makefiles work? | 10:58 |
error144_ | not an expert but yes | 10:58 |
rrq | .. I think now we are turning towards programming consulting :) | 10:59 |
rrq | a first, slightly hacky, way would be as follows: | 11:00 |
rrq | firstly do not mention your nightlinst on the dependency line | 11:01 |
rrq | secondly add a second step to the proparation of: cat nightly >> $@ | 11:01 |
rrq | preparation | 11:01 |
rrq | i.e. after the "plain installer list" is prepared, then tuck on your list appended to the end of it | 11:02 |
rrq | with that approach no dependency traversal is done at all | 11:03 |
error144_ | does this mean I will have to put the dependency packages manually? | 11:04 |
error144_ | or it is just no recommend? | 11:04 |
rrq | the alternative is to use the command: yes | ./review nightly >> $@ | 11:04 |
rrq | which whill foolow up dependencies from your list without including recommmends | 11:04 |
error144_ | oh | 11:05 |
error144_ | yah, it is clear now | 11:05 |
rrq | I'm not sure if it alls needs a clean up of any duplicates... | 11:05 |
error144_ | speaking of adding packages manually, say I want to add a package that doesn't exist in the repository (of devuan), to add it as a file, (.deb or .udeb) is that possible? | 11:06 |
rrq | a couple of ways depending on how wyou want that to be in the installed system | 11:09 |
error144_ | I want them to be installed the same way key packages (like apt) are installed | 11:10 |
rrq | mmm a) needs to be in hte iso as deb file, and b) needs the installer to take a special action to install it | 11:12 |
rrq | both doable | 11:12 |
rrq | the easiest for a) is to include it into the installer's initramfs, and then b) also have a finish-install script added that installs the deb at the end of the "normal" process | 11:14 |
error144_ | so how? it doesn't work to simply put the .deb in an iso file? | 11:14 |
rrq | the "normal" part of installation uses apt and requires the package description to be added plus the deb being downloadable by apt | 11:16 |
rrq | but the installer also runs through a collection of "finish-install" scripts that can do stuff before first reboot | 11:17 |
rrq | for the latter, you need to have such a finish-install script as well as the deb, and the make sure the iso builder includes that on the iso | 11:18 |
error144_ | ok I am getting mad, I will go and RECREATE THE WHOLE SCRIPT. | 11:18 |
error144_ | rrq thank you for your time, and knowledge, but I will have to get deeper in order to make this work as I want it. | 11:20 |
error144_ | as this script seem to be built for devuan use only | 11:20 |
rrq | no worries | 11:21 |
error144_ | I will go and never come back now, rrq I am sorry for any disturbance. | 11:21 |
error144_ | cya | 11:21 |
UsL | how can he "cya" if he's to never come back.. | 11:23 |
UsL | btw, impressive knowledge you sit on rrq. And I don't just mean about iso building. | 11:24 |
rrq | cheers | 11:25 |
UsL | ja, skål. | 11:27 |
uvok | Hi. I dist-upgraded to chimaera yesterday. XFCE as Desktop environment. I noticed that the account name completion doesn't work anymore in GnuCash with the Clearlooks-Phenix-Deepsea theme. Now I wonder whether that's GnuCash-, GTK- or Devuan related. | 16:16 |
uvok | I downloaded a "Win11" theme from xfce-looks, and with that theme, the account name completion works again. | 16:16 |
uvok | Can anyone reproduce the issue in the first place? (or is it one of those "I misconfigured my system some time in the past" problems?) | 16:17 |
brocashelm | it's most likely a gtk issue. beowulf's xfce was on gtk2, whereas chimaera's xfce (4.16) is on gtk3, so a lot of pre-gtk3 themes could look messy | 16:23 |
uvok | At least I can reproduce it when I install Devuan fresh in a VM... | 16:44 |
uvok | It's funny, though, the problem also occurs in the LXDE desktop environment, so it's not XFCE - specific | 16:45 |
uvok | But afaik, GnuCash itself has been using GTK3 under Beowulf, too? | 16:45 |
hyrc | kill the jews | 17:16 |
joerg | thanks! | 17:26 |
joerg | I wonder if it suffices to send above two lines to our police, to warrant a few months in jail for this idiot | 17:28 |
joerg | if anybody (in Germany, or elsewhere) feels like taking aktion and "anzeige erstatten", feel free to refer to http://reisenweber.net/irclogs/libera/_devuan/_devuan.2021-10-30.log.html#t2021-10-30T17:16:05 | 17:35 |
joerg | hurry, IP-adressess are dynamic and metadata ist sored only for weeks | 17:36 |
joerg | stored* | 17:36 |
joerg | add this, for completeness http://reisenweber.net/irclogs/libera/_devuan-arm/_devuan-arm.2021-10-30.log.html#t2021-10-30T16:18:30 | 17:39 |
joerg | for chanlog: | 17:40 |
joerg | [30 Oct 2021 17:16:05] <hyrc> kill the jews | 17:40 |
joerg | [30 Oct 2021 17:26:34] <-- hyrc (~hyrc@p57bbe3cc.dip0.t-ipconnect.de) has left this server (K-Lined). | 17:40 |
joerg | [30 Oct 2021 17:26:53] <joerg> thanks! | 17:40 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!