<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 _2_9  
00:44 <TemptorSent> skarnet: Any thoughts on a posixish fast means of running fnmatch globs against a field in a file more quickly than a looped case statement checking per line of input?
00:46 <skarnet> premature optimization detected
00:47 <TemptorSent> Okay...
00:47 <skarnet> if you want real speed: convert your fnmatches to regexes and use grep -f :)
00:48 <TemptorSent> Yeah, that's what I've done everywhere else, but I need to work with existing globs.
00:49 <TemptorSent> grep using fnmatch globbing would be ideal, but while I recall such an animal being around many years ago, I haven't turned it up again with a casual search.
00:49 <skarnet> yeah, I'm not aware of anything doing that
00:49 <skarnet> but unless you benchmark and it really proves to be a bottleneck, don't worry about it and shellscript away
00:50 <TemptorSent> Considering how BRE swallows patterns vs globbing, I can't think of a quick, easy sed script to fix it.
00:51 <TemptorSent> Yesh, it's one of the bigger issues I'm hitting. I've already cut total run time in half by using grep -F -f wherever possible and using intermediate files rather than pipes.
00:51 <skarnet> I've never wondered about that before, but how hard is it to convert fnmatches to regexes
00:51 <skarnet> shouldn't be that hard in this direction
00:52 <TemptorSent> It seems like it should be easy, but then you run into greediness differences.
00:52 <skarnet> anything you can't fix by using EREs ?
00:53 <TemptorSent> Probably not, but then the speed benefit is gone.
00:53 <TemptorSent> 3900+- lines to scan for somewhere between a dozen and a couple hundred globs.
00:56 <skarnet> lolwut
00:56 <TemptorSent> Fast enough if it can be scanned using a simple table and DAG, not fast if it has to start doing lookbehind regexes to emulate globbing.
00:56 <skarnet> but it shouldn't
00:56 <TemptorSent> The list of modules and firmware in a manifest file vs. the set of globs for the initfs features.
00:58 <skarnet> why would regexec() be slow where fnmatch() is fast
00:59 <skarnet> ah, foo/*/*
00:59 <skarnet> meh, just write a specific C program if you need to avoid the shell's overhead.
01:14 <jirutka> skarnet: "(and that sql should die, but that's a personal opinion)" … are you kidding?!
01:16 <skarnet> nope, not kidding. But I hope I'm allowed to have personal opinions without every single one being questioned and debated.
01:18 <jirutka> okay…
01:18 <jirutka> i’d rather go sleep :)
01:19 s33se_ joined
01:35 <TemptorSent> skarnet: Not to start a debate (because I somewhat agree), but what would you use in place of SQL?
01:37 <skarnet> I wouldn't use a programming language. I'd design a C API to perform reldb requests, and binding in other languages.
01:38 <skarnet> If a protocol was needed, I'd design a protocol that's easily parsable and writable programmatically.
01:38 <skarnet> With proper quoting, no injection.
01:39 <skarnet> SQL mixes 3 different purposes in one bastard tool, that's why it sucks.
01:39 <skarnet> And I also need to go to sleep. :)
02:29 gromero joined
03:08 <Shiz> C APIs tend to translate shittily to other languages
03:31 minimalism joined
05:05 fabled_ joined
07:01 royger joined
07:49 consus joined
08:47 ncopa_ joined
08:47 ncopa_ joined
09:05 tmh1999 joined
09:30 ncopa_ joined
09:30 ncopa_ joined
09:32 cyteen joined
09:45 rnalrd joined
10:29 blueness joined
11:55 <jirutka> skarnet: it seems for me that you don’t understand the purpose of SQL…
11:56 <skarnet> it seems to me that I had clearly expressed my lack of interest in discussing this
11:57 <jirutka> okay, sry :)
12:11 gromero joined
12:13 rdutra joined
12:16 leitao joined
12:18 rnalrd joined
12:19 gromero joined
12:47 farosas joined
13:01 gromero joined
13:15 skarnet joined
13:23 rnalrd joined
13:28 gromero joined
13:30 Marc_M left
13:40 rnalrd joined
13:50 fabled joined
13:58 leo-unglaub joined
14:14 rnalrd joined
15:03 blueness joined
15:12 <Shiz> heyo
15:12 <jirutka> Shiz: hi!
15:15 <Shiz> hows life
15:17 <^7heo> does anyone here know how the kernel decides how many CHS/tracks there are on a given drive?
15:17 <^7heo> and how to ensure it is consistent and doesn't cause problems during use?
15:18 <jirutka> quite good, but don’t feeling well know
15:18 <^7heo> I'm struggling because I have a 16GB drive that is seen with 32 sectors/track
15:18 <jirutka> ^7heo: isn’t this number total irrelevant these days?
15:18 <^7heo> I have NO clue.
15:18 <^7heo> I see fdisk warning me about various stuff
15:18 <^7heo> so I'm asking.
15:19 <^7heo> also if you know where to ask, I'd be very glad.
15:19 <jirutka> me neither, just remember settings this like 15 years ago in BIOS and even when I set some absurd values here, it somehow worked
15:19 <^7heo> yeah
15:19 <^7heo> but really
15:19 <^7heo> I do NOT understand any of this.
15:20 <^7heo> LBA would be great, but fdisk is always using CHS for some reason.
15:20 <jirutka> me neither tbh
15:20 <jirutka> wait… what?
15:21 <^7heo> well it's at least DIPLAYING the CHS
15:21 <Shiz> jirutka: be well
15:21 <Shiz> dont overexert yourself
15:21 <^7heo> I have some mail from Theodore Tso in my mail somewhere explaining something about CHS if I recall correctly
15:21 <^7heo> I wrote him directly and he was nice enough to answer.
15:22 <^7heo> maybe I should start by checking that, at least I know where to search
15:22 <Shiz> i think fdisk's CHS values are just inferred/made up
15:22 <^7heo> Shiz: but why is there a warning about the partition not ending on a cylinder then?
15:22 <^7heo> and why is there an automatic "rounding up to the next cylinder end"?
15:22 <^7heo> when creating a partition.
15:22 <^7heo> that is just bs.
15:22 <Shiz> legacy
15:23 <^7heo> yeah but it creates totally arbitrary partitions
15:23 <^7heo> with a size nowhere near the one asked.
15:23 <^7heo> I mean really.
15:23 <^7heo> "Blocks" are units of 1k right?
15:23 <jirutka> do I understand correctly that I can #include basically anything in C?
15:23 <jirutka> not just header files
15:23 <^7heo> yeah you can
15:23 <^7heo> but it's terrible.
15:24 <^7heo> (to do so)
15:24 <^7heo> nothing prevents you from doing bs.
15:24 <^7heo> that's the whole idea of C.
15:24 <^7heo> so people *can* know better than the toolchain.
15:24 <^7heo> but usually they don't.
15:24 <^7heo> really not.
15:27 <jirutka> and preprocessor do just a substitution, i.e. place content of foo in place of #include "foo"?
15:27 <^7heo> yeah.
15:27 <^7heo> hence the ifdef-hell
15:28 <^7heo> especially since you sometimes have stuff including stuff including stuff including...
15:28 <^7heo> you got it.
15:28 <jirutka> this is insane
15:29 <^7heo> that is how stuff works in any case.
15:29 <Shiz> well
15:29 <Shiz> #pragma once
15:29 <Shiz> etc
15:30 <^7heo> jirutka: I mean, whatever you use, it's either implemented in asm or C, in the end.
15:30 <^7heo> so...
15:30 <Shiz> or go
15:30 <Shiz> or rust
15:30 <Shiz> :P
15:31 <^7heo> rust compiles itself?
15:32 <Shiz> yes
15:34 <^7heo> Shiz: oh nice.
15:34 <^7heo> Shiz: I didn't know that.
15:34 <^7heo> Shiz: so yeah or go, or rust.
15:34 <Shiz> not so nice for bootstrapping
15:34 <Shiz> :P
15:38 <^7heo> right
16:00 <^7heo> so how does one generate an APKINDEX for use in a repo?
16:00 <^7heo> oh, `apk index`
16:00 <^7heo> interesting.
16:04 <Shiz> :P
16:05 <Shiz> and then abuild-sign to sign it
16:19 <TemptorSent> ncopa - Are you around by chance?
16:26 <TemptorSent> I'd like to propose a packaging change for the kernel, modules, and initfs components that would eliminate the need to run mkinitfs for kernel upgrades and make supporting various initfs features much cleaner in general.
16:29 <TemptorSent> Simply put, use the fact that the initramfs is a set of cpio.gz archives appended together to split the various components into standard apk packages with normal dep resolution, each of which supplies a .cpio.gz.
16:34 <TemptorSent> A kernel update then resolveds to a normal apk installation, with version numbered files being installed. mkinitfs becomes 'cat initfs-feature-*-*.cpio.gz initfs-modules-*-$krel.cpio.gz > /boot/initramfs-$krel'
16:39 <TemptorSent> Additionally, each package would supply a manifest of arch, package, and version tagged checksummed files, and a checksum deptree file.
16:44 <TemptorSent> I have most of the functionality on the kernel component side implemented and tested lightly (verifying output files contain whats expected, depmod run with warnings gives expected output)
16:44 rk324 joined
16:45 <TemptorSent> The problem is it entails a lot of useless recomputation that we could and should do once on the build host when we generate each versioned/flavored set of kernel and modules.
17:09 tmh1999_ joined
17:40 al3hex joined
17:55 fekepp joined
17:56 consus joined
17:56 <consus> Hi guys
17:57 <Shiz> hi
17:57 <consus> Is leading '/' omitted on purpose in `apk info -L <package'? It breaks the ability to apk info -L | xargs grep <foo> without cd'ing to / first
17:58 <consus> Which I really like to do sometimes
17:59 <Shiz> yes, because it's about the package contents
17:59 <Shiz> you can trivially add it back with something like
17:59 <consus> Well
18:00 <consus> Almost every other package manager gives me the whole path
18:00 <Shiz> sed -e 's.^./.g'
18:00 <consus> dpkg, qlist, rpm, even pkg_info
18:00 <consus> And it's kinda handy
18:01 <Shiz> but the root is not necessarily /
18:01 <consus> apk supports different root?
18:01 <Shiz> yes
18:01 <Shiz> apk --root ...
18:01 <consus> Oh
18:01 <consus> Nice
18:02 <consus> But it's only for installing? Or I can run queries against it too?
18:02 <Shiz> all operations are supported as usual
18:03 <consus> So `apk --root /tmp/foo/bar info -L <baz>' can output something like /tmp/foo/bar/etc/baz.cfg?
18:03 <consus> But I got your point
18:04 <consus> It definitely depends on the usage pattern
18:06 <Shiz> i guess it could
18:06 <Shiz> yeah
18:17 al3hex joined
18:19 <TemptorSent> consus: I typically just wrap my command in a subshell and cd, such as 'apk info -L | (cd / && xargs grep <foo>)' for your example
18:20 <consus> TemptorSent: I know
18:20 <consus> TemptorSent: I can do that
18:37 <^7heo> so guys
18:38 <^7heo> imagine a user downloads an installation disk
18:38 <^7heo> and wants to add 3 packages to it
18:38 <^7heo> (or simply wants to add the missing dependencies needed for some of the packages there)
18:38 <^7heo> how can that be made?
18:40 <^7heo> I didn't find a single configuration file; it looks like it's all compiled in the binaries.
18:41 <^7heo> there's the APKINDEX, but if you change that with a key that isn't an official key, the install media won't boot anymore.
18:41 <TemptorSent> Which binaries?
18:41 <^7heo> well, the stuff in boot
18:41 <^7heo> initramfs and shit
18:41 <TemptorSent> Take a look at my branch for that.
18:42 <^7heo> your branch won't get merged anytime soon
18:42 <^7heo> this is an important problem affecting the current distribution
18:42 <TemptorSent> I'm trying to make modules not suck right at the moment, because running modinfo 3900*n times blows.
18:42 <^7heo> i.e. people HAVE to download huge images if they need only 3 packages more.
18:42 <TemptorSent> It's looking like 3.6 unless somethign goes wrong.
18:42 <TemptorSent> Testing would very much help that.
18:43 <^7heo> yeah but I have no time to test your stuff, I need to test MY stuff first ;)
18:43 <^7heo> sorry D:
18:43 <^7heo> s/D:/:D/
18:43 czart_ joined
18:43 <^7heo> long story short, it sucks that there's no way to specify an ADDITIONAL line in the repo list in the install medias.
18:43 <TemptorSent> Well, as it sits there's a drop-in replacement for mkinitfs that actually works for the most part.
18:43 <^7heo> because yeah, it would be needed to be loaded manually; but at least it COULD work.
18:44 <_ikke_> ^7heo: Not sure if htat's what you mean, but isn't it a matter of adding packages to something like https://git.alpinelinux.org/cgit/alpine-iso/tree/alpine-virt.packages and create a new iso?
18:44 <^7heo> _ikke_: it's a little overkill for adding 3 packages to an existing iso, isn't it?
18:44 <TemptorSent> *lol* alpine-iso is so depreciated it's not funny.
18:44 <^7heo> isn't it deprecated?
18:44 <_ikke_> ^7heo: Isn't the installation medium read-only?
18:44 <^7heo> (as opposed to depreciated)
18:44 <TemptorSent> I found that out hte hard way AFTER I made it work.
18:45 <_ikke_> iso9660
18:45 <^7heo> _ikke_: nah it's not.
18:45 <TemptorSent> Yeah, I can't type :P
18:45 <^7heo> _ikke_: not after your flash it to a usb drive with setup-bootable.
18:45 <TemptorSent> Anyway, what you probably want is an overlay TBH for a quick fix.
18:46 <^7heo> what do you mean an overlay?
18:46 <_ikke_> ^7heo: right, which is basically just extracting the files from the iso
18:46 <^7heo> _ikke_: yes, and making it read/write
18:46 <TemptorSent> A tarball that gets extracted by the initfs init at boot.
18:46 <^7heo> TemptorSent: does that happen automatically?
18:46 <TemptorSent> Yep.
18:46 <^7heo> TemptorSent: is that documented anywhere?
18:47 <TemptorSent> apkovl.tar.gz IIRC
18:47 <^7heo> ah that
18:47 <TemptorSent> It will load it ONLY if its the only overlay file in the root apparently? I'm confused on what the intent was there.
18:47 <^7heo> so the real way to add packages to the repo isn't to add them to the repo; but rather to make a secondary "virtual repo" in a tarball
18:48 <^7heo> the intent was to allow alpine to boot in RAM
18:48 <^7heo> every time
18:48 <^7heo> while saving the packages and content of /etc in a file.
18:48 <TemptorSent> ^7heo: At least without remastering an image, that's probably the best bet.
18:48 <^7heo> you're right.
18:48 <^7heo> and remastering an image is completely overkill for my use case.
18:48 <^7heo> so I'll opt for that.
18:48 <^7heo> Thanks a bunch TemptorSent ;)
18:48 <_ikke_> alpine is still used a lot in a run-from-ram way
18:48 <TemptorSent> No worries.
18:48 <^7heo> _ikke_: yeah I guess.
18:49 <^7heo> _ikke_: one of my machines does it that way
18:49 <^7heo> _ikke_: it's a little cumbersome tho.
18:49 <TemptorSent> Remastering an image is getting close to just give it a profile and it gives you your image.
18:49 <^7heo> TemptorSent: the problem with that is the keys.
18:49 <^7heo> TemptorSent: if there was a directory with the keys
18:49 <^7heo> TemptorSent: I'd have dropped my key in there
18:49 <TemptorSent> Not a problem, it includes the keys of your choice too.
18:49 <_ikke_> /etc/apk/keys?
18:49 <^7heo> TemptorSent: and all good
18:50 <^7heo> _ikke_: not existing in the iso.
18:50 <_ikke_> it's part of the overlay
18:50 <^7heo> _ikke_: the iso only has apks and boot
18:50 <^7heo> I guessed.
18:50 <^7heo> but to change that you need to remaster an image.
18:50 <^7heo> obviously.
18:50 <^7heo> which is the whole thing I'm trying to avoid - because I'm writing a guide.
18:50 <^7heo> Guide to install alpine linux: do it yourself.
18:50 <^7heo> yay.
18:50 <TemptorSent> Gotcha.
18:51 <^7heo> so the simplest the method, the better.
18:51 <^7heo> the apkovl thing is simple enough; I'll use that.
18:51 <^7heo> anything else that could be done very simply (adding a public key, etc) isn't actually implemented
18:51 <TemptorSent> You might at least want to take a look at the kerneltool I added then, it will make a modloop/cpio.gz file given a list of modules.
18:51 <^7heo> and therefore isn't doable without being officially implemented.
18:51 <TemptorSent> It'll be implemented in a week or so ;)
18:51 <^7heo> TemptorSent: that's cool, but I need my guide to work with 3.5
18:52 <^7heo> TemptorSent: I'll update it for 3.6
18:52 al3hex joined
18:52 <TemptorSent> Right, just letting you know there are tools out there now that take a lot of pain out.
18:53 <^7heo> I guess
18:53 <^7heo> I'll check them out when I'm done
18:53 <^7heo> that apkovl thing that I totally forgot is my ticket out for today.
18:53 <^7heo> later, diff story
18:53 <TemptorSent> Not perfect yet, but generally useful regardless of the rest of the system if you need to make custom modloops and such.
18:54 <^7heo> yeah
18:54 <^7heo> well
18:54 <^7heo> I'll tell you in a week or so
18:54 <TemptorSent> Yeah, the other is that you can append cpio.gz archives directly to the existing initfs if you need to add modules or userspace in there.
18:54 <^7heo> bbl
18:55 <TemptorSent> Between that and the overlay, you can do pretty much anything you need.
18:56 <TemptorSent> (such as extracting /lib/modules from zfs-$flavor and the userspace from zfs and adding them a cpio.gz)
18:59 <TemptorSent> ^7heo: Unclustering the whole initfs mess should eliminate a whole slew of pain points.
19:12 eleksir joined
19:33 eleksir joined
19:46 blueness joined
20:18 <clandmeter> xsteadfastx, this snapcast works nicely with librespot :)
20:19 <xsteadfastx> Never heard about librespot
20:20 <xsteadfastx> Ah, Spotify :)
20:21 <clandmeter> running it on my nas and output to rpi3 and my android device
20:30 <ashb> It appears that the deps for thw Twisted package are missing.
20:31 <ashb> Could it be cos it's trying to parse setup.py and not detecting it as twisted does it in a (valid python but) non-standard way?
20:31 <ashb> https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_setup.py#L233-L235
20:32 eleksir joined
20:33 <ashb> Nope, looks like it just doesn't have half the depends it should
20:36 <clandmeter> ashb, maintainer should take care of the deps
20:37 <clandmeter> and looks like they are also pyver depended
20:37 <ashb> pyver?
20:37 <ashb> oh 2 vs 3?
20:37 <clandmeter> https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_setup.py#L227
20:38 <clandmeter> please submit a pr if you can.
20:38 <ashb> Step 1: fix the deps on twisted's dep - py-crypto is also missing things
20:39 <ashb> https://github.com/pyca/cryptography/blob/master/setup.py#L36-L42 vs https://git.alpinelinux.org/cgit/aports/tree/main/py-crypto/APKBUILD#n11
20:41 <ashb> How do we want to handle dual-life modules. i.e. one's that use six to support py2 and py3
20:43 <clandmeter> ?
20:45 <ashb> should there be a py2-twisted and a py3-twisted?
20:47 <Shiz> yes
20:50 <ashb> And I guess that's what the _py2 and _py3 functions in APK build do? What invokes those?
20:53 <clandmeter> ashb, the pyver depended deps are a mess.
20:53 <clandmeter> it means we need to support both in aports which we kind of not want.
20:55 nszceta joined
20:55 <ashb> Is there some auto dep parsing going on? Or is it cos the same APKBUILD file (with the same deps) is used to make py2-$x and py3-$x?
21:43 nszceta joined
21:47 al3hex joined
21:58 al3hex joined
22:19 leitao joined
22:33 rdutra joined
23:09 nszceta joined
23:25 LouisA joined
23:56 gromero joined