| Centurion_Dan | I have finally got debian-installer to build for all currently supported archs \o/ | 02:43 |
|---|---|---|
| golinux | Whew! That's great news! | 02:44 |
| Xenguy | Contrats Centurion_Dan | 02:45 |
| fsmithred | congrats | 02:48 |
| g4570n | ＼(◎o◎)／ | 02:48 |
| Centurion_Dan | almost... armel failed.... looks like it's time to drop qnap TS-[124]09 due to flash mem restrictions.... | 06:51 |
| Centurion_Dan | in experimental I'm trying to boost the support for arm64 boards for tftp and hd/sdcard installers. | 06:53 |
| palinuro | centurion_dan: why don't the arm platforms offer standard installation methods like all the other grown boys out there? | 14:53 |
| gnarface | kindof a hardware limitation as much as a software limitation | 14:54 |
| gnarface | there's also the practical issues | 14:57 |
| r3boot | plus, x86 has a looooong history of installations, which (for better or worse) have standardized the process pretty much | 14:57 |
| palinuro | i believe it's all about having shitty bootloaders made without a true engineering process | 14:58 |
| gnarface | well, that's the hardware limitation part though. but for something like a raspberry pi, unless you're expecting the user to also furnish their own usb hub and cdrom drive just to get your distro installed, an "installer" basically just means copying all the same data to the drive twice | 15:00 |
| gnarface | sdcard* | 15:00 |
| gnarface | so there starts to become less and less sense in doing that in a generic fashion when each piece of hardware has it's own completely different boot up behavior, and the u-boot and kernel binaries all have to be custom-compiled per-device anyway | 15:01 |
| gnarface | you run into basic physical limitations with some hardware just getting enough code in there to be able to boot linux on it custom, let alone in a fashion that would work on every arm device | 15:02 |
| gnarface | i've railed about it too | 15:03 |
| gnarface | but trust me... that's a pipe dream | 15:03 |
| gnarface | the ARM hardware scene just isn't that mature yet | 15:04 |
| gnarface | there isn't anything like BIOS or even approaching it | 15:04 |
| gnarface | you should be able to alter the existing image provided though | 15:08 |
| gnarface | to do whatever | 15:08 |
| gnarface | alot easier than it would be to alter the installer | 15:08 |
| fsmithred | do the different arm devices use different bootloaders? Is anything else different? | 15:09 |
| gnarface | well u-boot is an attempt to be the same boot loader as far as i understand it | 15:10 |
| gnarface | but in it's existing state, pretty much every device requires a custom fork of it | 15:10 |
| gnarface | ... or at least a heavily patched version of one of the main forks | 15:10 |
| gnarface | there's also this thing called a dtb file | 15:11 |
| fsmithred | I'm wondering if it's possible to have one image that could do all | 15:11 |
| gnarface | which is some database of hardware variables i guess | 15:11 |
| gnarface | needed for turning stuff on and off | 15:11 |
| fsmithred | but I guess what I'm thinking about would be an installer | 15:11 |
| gnarface | so the installer would just need to be carrying a compiled u-boot binary for every device it supports... | 15:12 |
| fsmithred | yeah, that's what I'm thinking. And then it would add whatever parts are unique. | 15:13 |
| fsmithred | oh, you said that | 15:13 |
| fsmithred | if the main OS image is mostly the same, then it might work. | 15:13 |
| fsmithred | image the common piece and add the unique parts | 15:14 |
| gnarface | some of the boot process relies on hardware-specific boot code being at a hardwired location on disk though, so i don't know for sure if this would be possible actually universally | 15:14 |
| fsmithred | but having never played with arm, I'm talking out my butt | 15:14 |
| gnarface | well maybe that's what u-boot will do when it's finished | 15:15 |
| gnarface | otherwise i'm not sure how you'd get it to work without at least at some point choosing an image by at least hardware family | 15:15 |
| gnarface | like, manually | 15:16 |
| gnarface | but yea i dunno either | 15:16 |
| gnarface | the issue of trying to share an OS with other devices didn't seem to come along with the ARM hardware design | 15:16 |
| jaromil | anyone interested in having an overview of EU projects which are being funded by a venture program we run at Dyne.org | 15:57 |
| jaromil | please be welcome at this event on 5th July in Amsterdam https://taz.dyne.org/venture-builder-eu.html | 15:57 |
| jaromil | many projects are also going to adopt Devuan as a base OS | 15:57 |
| jaromil | and... you can apply too :^) there is a new call opening in October, 200k equity free | 15:58 |
| HumanG33k | jaromil, do you think an other google alternative build on top of devuan and free software can apply ? | 16:15 |
| r3boot | jaromil: interesting, thnx! I hope I can make it, just starting a new job coming week :) | 16:18 |
| jaromil | HumanG33k: we have ample literature by now on what we mean by "human-centric solutions"... a search engine could be a good subject to apply these principles | 17:41 |
| HumanG33k | jaromil, ok i maybee should take time to read that | 17:44 |
| jaromil | is the work-plan on ledgerproject.eu | 17:44 |
| jaromil | also there are webinars. coming to this event i guess is also a good and quick way to refine ideas, watch the winners of this year presenting etc. | 17:44 |
| _abc_ | fsmithred: here? | 18:24 |
| fsmithred | hey _abc_ | 18:31 |
| _abc_ | hi | 20:18 |
| _abc_ | I'm in and out. So fsmithred are you making a new release of refracta2usb? | 20:19 |
| jordila | Is it possible to get PHP7.3 on a Ascii machine ? How to ? I'm wondering... maybe it is via Beoulf backports ? | 21:17 |
| fsmithred | _abc_, I hesitate to do anything with refracta2usb except minor changes to keep it working. It's fragile. | 21:21 |
| fsmithred | but yeah, I will probably add that piece | 21:25 |
| fsmithred | eventually | 21:25 |
| stiltr | jordila: Looks like there's no php7.3 in ascii-backports, but it's in beowulf. | 21:50 |
| _abc_ | fsmithred: okay I will try to mash it into a more usable package form and get the versioning sorted out, it's just tacked on for now. | 22:10 |
| fsmithred | _abc_, ok, I just can't spend any time on it right now. | 22:13 |
| fsmithred | Without giving it a lot of thought, I'm thinking maybe it should be a live-config script. | 22:15 |
| fsmithred | that way if it's installed in a non-live system, it won't do anything | 22:15 |
| fsmithred | but it will get into any snapshots that are made | 22:15 |
| fsmithred | where it will do something | 22:15 |
| fsmithred | here's an example: http://distro.ibiblio.org/refracta/files/extra_packages/live-config-refracta_0.0.6.deb | 22:16 |
| _abc_ | fsmithred: I agree but I need to think more about it. Since it fixes a systemd inserted bug, maybe the bug will be fixed in the kernel/binaries some day instead? | 22:16 |
| fsmithred | oh, I didn't realize it was a systemd bug | 22:17 |
| fsmithred | If it gets fixed later on, we don't continue to provide the package. I can assure you that it won't be fixed for beowulf. (I'll bet 1 euro on that) | 22:19 |
| onefang | They fix systemd bugs? When did that revolution happen? | 22:21 |
| fsmithred | I think they fix a few so they can say that they do. | 22:22 |
| onefang | lol | 22:22 |
| fsmithred | but I thought this was an old wontfix | 22:22 |
| MinceR | the trick is that the fix introduces more new bugs | 22:23 |
| fsmithred | I hate when I do that. | 22:25 |
| MinceR | they never notice | 22:26 |
| _abc_ | systemd bugs are fixed by updating the systemd and introducing new ones of course. | 22:30 |
| _abc_ | Any programmer will tell you that any software consists of bugs assembled such that none are exposed. Touch one of them with good intentions and the ones it had been hiding will be free to get out. | 22:30 |
| onefang | lol | 22:31 |
| _abc_ | That, and the wonderful "agile" programming model systemd seems to follow means this game will be going on strongly for a long time. | 22:31 |
| _abc_ | onefang: that saying is only amusing to non programmers. Real programmers know it's the truth... | 22:32 |
| r3boot | computing is actually pretty hard the more layers you peel off | 22:32 |
| onefang | Um, I'm a real programmer, have been since the '70s. :-P | 22:32 |
| r3boot | respect :) | 22:33 |
| * _abc_ is an electronics guy who became a programmer when needed. | 22:33 | |
| onefang | But we better shush before golinux yells OT at us. | 22:33 |
| r3boot | I was not trying to diss or anything, just acknowledging that bugs are indeed a thing to be accepted | 22:33 |
| r3boot | Or maybe I am mis-interpreting you | 22:34 |
| golinux | Discussion of systemd bugs belongs on #debianfork not here. | 22:34 |
| MinceR | https://twitter.com/schestowitz/status/1142476354086232064 | 22:34 |
| fsmithred | Part of that was on-topic | 22:35 |
| fsmithred | then we drifted | 22:35 |
| golinux | That's how it always goes . . . | 22:40 |
| MinceR | then later there's running and screaming | 22:40 |
| golinux | If onefang hadn't pinged me I would have been blissfully unaware | 22:41 |
| fsmithred | that wasn't a ping, that was the group self-regulating | 22:41 |
| golinux | Self-regulatling without a suggestion for a solution other than me "yelling". | 22:46 |
| onefang | The suggestion I made was that we better shush. | 22:47 |
| golinux | Then no need to get me involved in any way. ;) | 22:48 |
| fsmithred | onefang, you shoulda said "the nameless one' | 22:49 |
| fsmithred | anyway, _abc_ the only thing I can find is that the bug was fixed in 2012 (in wheezy) | 22:49 |
| golinux | Let's please stop | 22:49 |
| fsmithred | that's on debian-live ml | 22:49 |
| fsmithred | we're talking about a problem that we've been working on (and off) for a year | 22:51 |
| fsmithred | clean shutdown of live persistent volumes | 22:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!