IRC Logs for #crux-devel Thursday, 2014-02-27

teK_remaining is iii) testing of /dev/ stuff after swtching from the initrd00:00
teK_wrong window, (that's my LUKS PW)00:00
jaegererror: password not strong enough... in fact really terrible00:00
jaegerperhaps you could use the ISO's busybox for this?00:01
teK_but I provided a port for creating the initrd anyway00:02
jaegeralternatively is the 'official' mkinitrd or whatever able to handle cryptsetup/luks/dmcrypt/whatever?00:02
teK_that's the case atm00:02
jaegerWould it be better to add that to opt and use it instead of a custom one?00:02
teK_define custom one, please00:03
jaegeryour port for creating the initrd00:03
jaegeror did you use upstream mkinitrd for it?00:03
teK_currently you have to specify the root device passed to cryptsetup luksOpen $DEV root00:03
teK_nah, it's gen_cpio* kernel sources + gzip00:04
teK_it's like:  /usr/src/linux/usr/gen_init_cpio initramfs.lst | gzip -c > /boot/initrd.gz00:05
jaegeryeah, familiar with that sort of invocation... I guess I'm not understanding the problem00:05
teK_we can wrap this in a nice script any time.. the real question is if jue is willing to put my changes in our 3.1 ISO or not.. it's basically tiny adjustments to the Makefile and a new port for the initrd00:06
jaegerwhat does the initrd port look like? That was where my question about mkinitrd came in00:06
teK_no problem.. the only issue wrt coding is the grade of comfort/abstraction that's presented to the user00:06
jaegerI was suggesting that instead of a custom port just for crux we investigate using upstream mkinitrd if it can handle this scenario00:07
teK_it's really simple:
teK_I did not look into that .. I, again, borrowed from our ISO00:07
jaegerand the busybox you have in the port is a static busybox binary? same with cryptsetup?00:08
teK_the remaining issues boild down to a matter of taste I guess00:08
teK_it's a no-brainer to a) provide them in the port or compile them from separate ports00:08
teK_I included the blobs for convenience only00:08
jaegerin my aborted mkinitramfs project I think I kept a trimmed busybox config in the port and built busybox when the port itself was built00:09
teK_it's just keeping dependencies down to some degree which should not be an issue for two ports00:09
teK_yeah that should be fine, too00:09
teK_I have no strong opinion wrt this issue00:10
jaegerNor do I, particularly, just trying to understand the use cases :)00:10
jaegerand process00:10
teK_my main target would be to get this integrated in 3.1 if jue agrees as he seemed to be rather reserved/reluctant towards this feature and or me00:10
teK_yeah, don't mind asking.. it's late and I've had some cups of juicy "leomande" too :P00:11
jaegerI'm guessing that he was worried about how much time it would take to test/develop but I suppose he can make his own concerns known :)00:11
teK_well the whole world -CRUX uses initrds00:11
teK_so this is probably not that much a concern00:11
jaegerThat's why I was thinking mkinitrd might be a useful addition. Could offer some more options00:11
jaegeror initramfs-tools if that's not a debian-specific thing00:12
teK_I have no idea as I never have been a fan of kernel modules00:12
jaeger <-- looks like it's a debian thing, links to debian git00:13
teK_my suggestion is: let's meet with jue "today" in some 17 hours or so and see what he thinks about this00:13
jaegertrying to find a homepage for mkinitrd as well00:13
teK_The requested URL /git/kernel/initramfs-tools.git was not found on this server.00:14
jaegerok, sounds fine to me. I don't really feel rushed to get 3.1 ready, would rather it be good quality. :)00:14
jaegerdoh, heh00:14
teK_I feeld urged to get this feature in. Last time I tried was pre CRUX-2.5 times00:15
jaegerIt might be that there's no official upstream mkinitrd/mkinitramfs and we could just make a crux type one00:15
teK_yeah I don't see much issues with that00:15
teK_in the end it's copying /dev/* to /newroot/dev/* and than handing over to /etc/rc & friends00:15
jaeger <-- uploaded the one that I started to make00:16
jaegerthink it might be useful?00:16
teK_could be00:16
jaegerlooks like it was august 2012 that I last worked on that, heh00:17
teK_mine assumes that $USER just knows what he's doing, i.e. important things are compiled in statically00:17
jaeger <-- also a sample run output00:17
jaegerIt generates pretty simple inits00:18
teK_the thing is.. at present we require the user to have storage and other boot-time deps to be compiled in00:18
jaegerregardless of which one we might use, though, it seems like we'd need to have a few things:00:19
teK_this is good and bad at the same time..00:19
jaegerat install time we'd need the ability to create the encrypted device00:19
jaegerat boot time later we'd need to be about to mount it00:19
teK_which is a nobrainer :)00:19
jaegerwhat else is needed?00:19
teK_nothing more, provided drivers are already there00:19
jaegerSeems fairly simple, then00:19
teK_my init really is a slightly adjusted copy of our ISO's00:20
teK_yes, cruxy :))00:20
jaegerI'm about to leave work but for what it's worth I have no objections to getting this in 3.1 if it works properly. I just don't have much experience with it. I've only used cryptsetup to encrypt a file in which I stored some passwords00:30
teK_let's see what jue and the gang has to say about this tomorrow00:31
teK_jue frinnst Romster sepen and *: speek up, please00:31
teK_I feel obliged to give proof, too: ;)00:32
teK_oh and we always can mark that part of 3.1 experimental..00:35
teK_it does not touch any of the other ports00:35
teK_I gotta go to bed, I'll just start uploading a test ISO without dependcy checking and xorg for testing, maybe anybody is brave enough..00:42
jaegertake care01:21
*** __mavrick61 has quit IRC03:26
*** _mavrick61 has joined #crux-devel03:27
jaegerwonder how long my compose key has been broken, didn't even notice it until today03:34
jaegerirclogger__ doesn't handle special chars, looks like03:42
prologicit does03:47
prologicbut irclog2html doesn't support unicode03:47
prologici.e: it gets stored, but not displayed03:47
prologicneed a better log viewer/renderer03:47
*** irclogger_ has joined #crux-devel03:53
prologicI'm an f'n idiot03:54
prologicit works now03:54
prologicI didn't write unicode support in the f'n logger itself03:55
prologicgawd how stupid of me03:55
prologicunicode characters should get logged now03:55
jaegerheh, smooth03:56
prologicand displayed03:56
prologicheh smooth I'm so harsh on myself? :)03:56
prologicI have no idea why I didn't see that before03:56
jaegerno, the not writing unicode support03:56
prologicthere were errors in the daemon's log file03:57
prologicyeah :(03:57
jaegeron that note, going to bed. night03:58
prologicsuch a simple fix too :(04:02
prologicI feel embarrassed04:02
*** _mavrick61 has joined #crux-devel07:07
Romsternice one prologic08:29
Romsterprologic, i hope that code keeps the logger auto reconnecting.08:29
jueteK_: I'm not against new features, but I'm strongly against adding really new stuff in the last part of a release cycle.09:53
teK_hello there09:54
jueteK_: IMO it's too late, we should try to finish 3.1 soon, because the work to maintain 2 releases isn't that nice09:54
teK_I understand that adding new features may pose critical09:55
teK_still my changes do not touch any of the other ports09:55
teK_so, as I suggested yesterday, support for fully encrypted / could be marked experimental09:55
teK_there's no harm to any other part of CRUX09:56
teK_the ISO's Makefile 'd need only include the new port I called cryptsetup-initrd09:57
teK_as far as the kernel is concerned we only have to enable some ciphers and hash algorithms.. that's a safe bet, too ;)09:58
jueteK_: ok09:59
juedo you have the port somewhere?10:00
teK_I have a proposal: let me roll a _current_ (my checkout is two weeks old) diff to the makefile and a test ISO for you and the others to inspect tonight10:00
teK_it uses prebuilt busybox and cryptsetup but we always can ship these individually10:01
teK_the initrd generation is straight forward and largely based on the ISO's so it should be safe, too10:02
Romsteri have yet to do the lvm part...10:02
teK_ shows the initrd in action ;)10:02
teK_Romster: what exactly? :)10:02
Romstereudev rules10:03
Romstermove it out of rc10:03
jue.oO bash 4.3 is out10:08
Romsterdo we really need bash? it's sush a bloated ting.10:09
Romsterand i'm still using it -_-10:09
prologicRomster, that was a fix for unicode support10:11
prologicRomster, I have another patch to both my bots that should fix reconnection issues which I forgot to code in too :)10:11
*** Romster has joined #crux-devel11:05
juejaeger, frinnst: new readline/bash is a bit problematic, run into a 'undefined symbol' error with awk after readline update, we should probably do it for 3.1 only11:20
juewill look into this deeper tomorrow11:20
*** Romster has quit IRC11:42
*** Romster has joined #crux-devel11:45
LukcYes, do we really need bash? What about GNU tar, GNU cpio (which are duplicates of libarchive), wget (which is a duplicate of curl), glibc (which is a bloated libc), and every other bloat in CRUX? (no troll intended :|)11:54
LukcActually, Romster, some of the code of pkgmk and the prt-utils and other things depend on bash.11:58
Romsterthink we should run profilers over that stuff. but in the end i bet autotools requires bash.12:00
Romsterand i know we can all set our own shell for home...12:01
*** Romster has quit IRC12:02
LukcAutotools don’t require bash AFAIK. They probably require at least ksh or something, though. :|12:02
*** Romster has joined #crux-devel12:02
LukcAutotools don’t require bash AFAIK. They probably require at least ksh or something, though. :|12:04
LukcI used them on *BSDs in the past and they didn’t complain much about that.12:04
LukcMost of the time.12:05
Romsteryour forgetting the gnu tools stuff.12:24
Romsterthat BSD doesn't use.12:24
mike_kprologic: that virtualenv issue was not reported by me, nor I have any issues with it at all. just wanted you to take over that ticket.12:50
prologicoh sure12:51
prologicI fixed it anyway12:51
prologicmissing seutptools on the user's system12:51
prologicI updated and fixed the port too anyway12:52
prologicit was depending on python - should depend on setuptools ihmo12:52
prologicmakes more sense12:52
prologicnot that it strictly needs it, but without you have to do:12:52
prologicpython -m virtualenv12:52
prologicwhich is very suckful :)12:52
mike_kprologic: thanks, I saw the ticket12:57
mike_kprologic: don't you want to look after pip too? =)12:59
prologicsure why not :013:02
LukcYeah, that too. But I tend to use those a lot, unlike the other things I mentioned. :(13:02
prologicme too :)13:03
prologicvirtualenv, setuptools and pip13:03
prologicand mercurial13:03
prologicuse them everywehre :)13:03
mike_kprologic: feel free to change the "Maintainer" header13:06
jaegerteK_: one easy way to update your cryptsetup-initrd busybox would be to take the one the current ISO uses13:56
teK_question is: do we need/want updates between ISO releases? ;)14:01
teK_or how do you define 'take the one from the iso'?14:02
jaegerI just mean use the one from the current ISO until you do your next update. In other words build the newer version and put it in the port just to have a more recent one than you were using14:03
jaegerif you've already built a new one then don't bother :)14:03
teK_yeah that should work just fine14:08
teK_I did (with the ISO) :)14:08
teK_I will come back to you later today14:09
teK_maybe frinnst has an opinion to utter, too14:09
jaegeror a slap :)14:09
teK_not again :((14:09
jaegerThese days I just assume that for you and him a slap is like saying "hi" or shaking hands14:10
jaegerJust the way it's done. (tm)14:10
teK_yeah, actually he likes me a lot. I like to tell myself, at least.14:11
jaegerDo you have your iso diff posted anywhere yet? I'm curious about it14:11
teK_I have to merge it with your most recents pushes14:11
teK_I checkd it out two weeks ago14:11
teK_I will post the diff tonight14:11

Generated by 2.11.0 by Marius Gedminas - find it at!