<    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 29  
00:07 minimalism joined
00:08 minimalism joined
00:23 <arch3y> I keep wanting to type in apkg not apk
00:23 <arch3y> gonna have to get used to that
00:28 LouisA joined
00:28 <arch3y> Im guessing /etc/apk/world is updated eachtime a pkg is installed
00:33 leitao joined
00:39 <Shiz> yes
00:39 <Shiz> it's the list of packages you explicitly requested for install
00:39 <arch3y> k thought so thats nice for a backup of files
00:40 <arch3y> err backup of pkgs installed
00:58 <arch3y> got everything up but sound, I had to fiddle with the lxdm setup because the instr arent clear enough on insatlling xfce
00:59 <arch3y> I assume I can drop on alsa or pulse which ever I choose
01:03 <Shiz> the wiki docs can be outdated in places, yes
01:03 <Shiz> and the passing recommendation here seems to be to use alsa :p
01:05 <arch3y> yeah I pretty much always use alsa
01:06 <arch3y> yeah wikis do get outdated things are ever changing I just used AL docs to solve it
01:12 s33se_ joined
01:38 <arch3y> got myself oriented with an xfce install for now Ill mess with it more later
02:47 minimalism joined
05:52 lucybun joined
06:44 czart_ joined
07:49 xfix joined
08:05 hl joined
08:47 nightmared joined
09:02 fabled_ joined
10:12 LouisA joined
10:13 grzes_ joined
10:13 <grzes_> hi there
10:14 <grzes_> my docker image stopped building lately: ERROR: unsatisfiable constraints: so:libcrypto.so.41 (missing): php7-openssl-7.1.3-r1[so:libcrypto.so.41]
10:14 <grzes_> any ideas? :(
10:23 <jirutka> grzes_: php is currently totally messed in alpine, so no wonder… we will fix it until v3.6
10:50 <grzes_> jirutka: when 3.6 release is planned?
10:50 <jirutka> grzes_: next month
11:28 scadu joined
12:19 t0mmy joined
14:25 TemptorSent joined
14:57 <clandmeter> i put build-3-6-armhf builder to stop on fail. this is the list that currently is not able to build. http://tpaste.us/xWKl
14:59 <clandmeter> buildlogs are here http://build.alpinelinux.org/buildlogs/build-3-6-armhf/
15:08 blueness joined
15:10 BitL0G1c joined
15:12 minimalism joined
15:20 Emperor_Earth joined
15:43 <Shiz> >>> docker: Checking sha512sums...
15:43 <Shiz> docker-17.04.0.tar.gz: FAILED
15:43 <Shiz> huh...
15:47 blueness joined
15:51 <nmeum> the mmh build error is also very strange
15:51 <nmeum> > /usr/bin/install -c -g buildoze -m 2755 inc /home/buildozer/aports/community/mmh/pkg/mmh/usr/bin/$cmd;
15:51 <nmeum> > install: unknown group buildoze
15:51 <nmeum> the group is actually called buildozer of cause
15:52 <nmeum> but mmh's configure script figures out this particular group by looking at the group who owns the directories /var/mail, /var/spool/mail, …
16:44 <TemptorSent> Question regarding keymaps -- is it desired that the initfs be built with the same keymap as the host system?
16:45 <Shiz> the initfs doesnt need a keymap
16:46 <TemptorSent> There is currently an initfs feature 'keymap' that include files '/etc/keymap/*'
16:49 <TemptorSent> Should the new version detect the host keymap and install that file from bkeymaps to etc/keymap, or should it instead include all keymaps in /usr/share/bkeymaps and allow a kernel cmdline option to select which one is used?
16:51 <TemptorSent> The problem is that the old mkinitfs drew files from the running system rather than from packages, so we have no way of knowing what we're getting.
16:52 <TemptorSent> If a package wasn't installed, it would silently create a bad initfs, so we're now building the initfs directly from packaging + a small handful of external files.
16:52 <TemptorSent> Leaving things such as the desired behavior of keymaps somewhat ambiguous.
16:58 <TemptorSent> So, better question: How do we want to deal with host-specific configurations that were previously reflected in the initfs as a side-effect?
17:05 <Shiz> they should be
17:05 <Shiz> like mdadm.conf
17:14 <TemptorSent> Okay, so something like checking the glob against files in etc. and adding any that match.
17:14 <TemptorSent> I think we're going to need to tag the globs with a source to keep from turning that into a mess.
17:15 <TemptorSent> The user config should be kept seperate from the package contents.
17:17 <TemptorSent> Can you thing of any files outside the /etc structure that we would even want to consider the host versions of over what we get from fresh packages?
17:17 <TemptorSent> s/thing/think/
17:20 <TemptorSent> This is the only remaining mess to clean up for the new mkinitfs/update-kernel to be merged that I'm aware of, the rest is plumbing and bug-smacking.
17:26 <TemptorSent> Currently, the only globs including /etc are '/etc/mdadm.conf' '/etc/modprobe.d/*.conf' '/etc/mdev.conf' and '/etc/keymaps/*'
17:28 <TemptorSent> Of those, only mdadm.conf appears to have actual user configuration in normal cases, with the configuration of keymaps by simple inclusion.
18:15 <Shiz> mdev.conf can have user config perfectly fine
18:15 <Shiz> as does modprobe
18:18 <TemptorSent> Shiz: The question is do we want the user-configured mdev.conf in the initfs, or should it use the packaged version for consistency?
18:28 <TemptorSent> The existing initramfs-init doesn't seem to actually use mdev for anything but nlplug-findfs, so I guess the requirements of nlplug-findfs should determine the handling of mdev.conf.
18:29 <xentec> initfs is host system bound. it should reflect some changes from /sysroot. keymap for example should be the same the user set it to. one thing you don't want is beeing logged in initfs as root after an emergency without a fitting keymap.
18:30 <TemptorSent> And rather than including every file in modprobe.d, each feature should probably include its own module config file globs, and the base include only system configs.
18:31 <TemptorSent> xentec: Understood -- currently, it only installs the host keymap and no others, so if you have to recover on system with a different keymap, you're SOL.
18:34 <TemptorSent> xentec: My thought is that either all bkeymaps should be installed in /usr/share/bkeymaps and the current host keymap linked, with a kernel cmdline option to override, or splitting the features out so the keymap is specified by the feature name (keymaps_all or keymap_<keymap>, respectively.)
19:04 minimalism joined
19:05 LouisA joined
19:41 <TemptorSent> One other issue is what do we do about the "module=" kernel command line options? Add a new config file?
19:48 BitL0G1c joined
19:54 <TemptorSent> Why exactly do armhf/aarch64 have a '/etc/modprobe.d/i386.conf' in alpine-baselayout?
19:58 <TemptorSent> Also, is there any reason not to use the passwd/group that comes with baselayout by default for the initramfs instead of the rather screwball version currently included in /usr/share/mkinitfs?
20:07 <skarnet> I don't know any default passwd/group in *any* distro that doesn't qualify as screwball
20:07 <TemptorSent> *lol* fair enough, but we could at least not be using one that obviously is setup for gentoo with portage and distcc users :)
20:08 <skarnet> I can agree with that
20:09 <TemptorSent> What I would personally like to see is a 'master' system set of passwd/group files that defines all the known system users/groups used by any alpine packages, then extract the minimal subset of that needed for the initfs.
20:09 <skarnet> that's bad design: it requires centralization of information
20:10 <TemptorSent> Or at least a master list of system user/group accounts that could be used to generate skeleton group/passwd/shadow files as needed.
20:10 <skarnet> currently a package that wants to create its own users/groups can do so
20:10 <TemptorSent> It's required to avoid conflicts with UIDs
20:10 <skarnet> not with dynamic useradd
20:11 <TemptorSent> For instance, 'shadow' has a group id of '42' which is hardcoded into alpine-baselayout.
20:11 <skarnet> it's normal to have a static base.
20:12 <TemptorSent> Not static, it's added by 'addgroup -S -g 42 shadow 2>/dev/null' in the .pre-upgrade script.
20:12 <skarnet> static as in static numbers.
20:13 <skarnet> alpine-baselayout can do that.
20:13 <skarnet> app packages should not.
20:13 <skarnet> That seems pretty obvious, doesn't it?
20:17 <TemptorSent> Let's see.. 'nut' uses UID=84, ceph:UID=167, dovecot:UID=90, dovenull:UID=91, seafile:UID=800
20:19 <TemptorSent> Oh, and we have GID=82 assigned for www-data in several packages.
20:20 <skarnet> that should either be documented and centralized, or fixed to use dynamic uids.
20:20 <TemptorSent> netdev:GID=28, avahi:GID=86
20:20 <TemptorSent> Yeah, I'd go with the documented and centralized for the system accouts below 100 at the very least, if not below 500
20:21 <TemptorSent> The other big problem is the IIRC the tarballs are stored with numeric UID/GID in several places.
20:22 <skarnet> what tarballs?
20:23 <TemptorSent> The tarballs of the apks themselves.. I recall seeing a '--numeric-owner' somewhere in the build system.
20:24 <TemptorSent> Also, obviously having system accounts with different UIDS is a mess in shared environment.
20:24 <skarnet> well tarballs should always be created with --owner=0 --group=0 --numeric-owner
20:24 <TemptorSent> So, how do you store user info when you have files that must be owned by someone other than root?
20:25 <skarnet> it's rare, but sure, in that case you omit those options
20:25 <TemptorSent> Or, more pressingly, by a GID other than 0, which is reqired in MANY places.
20:26 <skarnet> it really shouldn't, the habit of using non-root gids everywhere is a dumb redhat idea that everyone copied
20:27 <TemptorSent> (devices, man, chron, etc.)
20:27 <skarnet> that's utterly idiotic 95% of the time
20:27 <TemptorSent> No, it's been a standard administrative practices since before I started using unix in the 1980s.
20:28 <TemptorSent> wheel, tty, mem, etc.
20:28 <skarnet> still useless
20:28 <TemptorSent> ??
20:29 <TemptorSent> You lost me, how is it useless to distinguish groups from the root group for devices/services which may be used by non-root users?
20:29 <skarnet> anyway if you need to include uid/gid info in a tarball, either don't use the --owner/--group option, or have extraction scripts that do the right thing
20:29 <TemptorSent> And how would setgid ever work?
20:30 <skarnet> I'll gladly teach a Unix design course another day
20:31 <TemptorSent> Anyway, all that aside, it seems that a minimal consistent passwd/group file should be establish which contains at least all known static assignments for UID/GID.
20:31 <TemptorSent> skarnet: Teach K&R :)
20:32 <skarnet> you mean the people who decided that ln should do unlink() then link() instead of link() then rename()? yeah, I could teach them.
20:32 <TemptorSent> And get rid of any that are dynamically assigned.
20:33 <TemptorSent> *lol* Yeah, I don't LIKE a lot of design decisions in unix, but the fact is that's what we're working with and supporting idiomatic usage is required until we're ready to take on rewriting a lot more than a few config file formats :)
20:34 <skarnet> says the guy rewriting the initramfs :P
20:34 <TemptorSent> I just want things to not break using the existing idiom wherever possible.
20:34 <TemptorSent> *grin* Got me there :P
20:35 <TemptorSent> Of course, that coming from the guy who rewrote most of the primitaves into something sane....
20:37 <TemptorSent> Anyway, I'm going to ditch the existing /usr/share/mkinitfs/(passwd|group) in favor of the ones from baselayout.
20:37 <skarnet> check with ncopa/fabled first, but that shouldn't hurt
20:38 <TemptorSent> Yeah, I'll verify it, but it couldn't possibly be worse than whats there now.
20:38 <TemptorSent> That just leaves what to do with the /usr/share/mkinitfs/fstab
20:40 <TemptorSent> The only difference between it, and the one in baselayout is that baselayout omits /dev/fd0
20:41 <TemptorSent> Which, considering I don't believe we can actually fit on a floppy, is probably correct.
20:44 <TemptorSent> skarnet: Also, are you aware of /etc/modprobe.d/i386.conf which is installed on armhf/aarch64 as well as x86*, is actually used on those archs? If so, it probably should be renamed, if not, it probably should be removed from baselayout on those archs.
20:45 CoOlCyrus joined
20:46 BitL0G1c joined
20:49 <skarnet> I have no idea, I'm not involved in the installer at all. Ask the real devs ^^'
20:57 <TemptorSent> Who's the resident baselayout expert besides ncopa/fabled, who are nearly impossible to catch on it seems.
21:00 <skarnet> on Sunday nights EU time, there's no resident expert.
21:01 <skarnet> (you only caught me because I happened to be there and made the mistake of answering. :P)
21:02 <TemptorSent> *grin* Sunday is a good day for me to work on Alpine as I don't have anything else I have to do.
21:04 <TemptorSent> Although now that the weather is getting good, there are other things I *WANT* to do, so I'll probably be out and about rather than at the terminal more than less on weekends soon.
21:19 fabled_ joined
21:49 <TemptorSent> Where busybox provides a given tool (/usr/sbin/nbd-client for instance) that's also available through a stand alone package (nbd-client for instance), is there any compelling reason to install the independent package by default unless we know BB doesn't actually support the functionality we need?
21:52 <TemptorSent> In the same vein, is there a reason why busybox doesn't 'provide' such files in a way that is clear from a package-management standpoint (something requires nbd-client, busybox is installed, busybox provides nbd-client and nbd-client package is not installed > use nbd-client from BB)
21:58 <Shiz> because busybox doesn't provide nbd-client
21:58 <Shiz> it provides /usr/sbin/nbd-client
21:58 <Shiz> and that part should be part of its autogenerated deps
21:58 <Shiz> afaik
21:58 <Shiz> err
21:58 <Shiz> autogenerated provides
21:58 <Shiz> just like clang provides /usr/bin/clang
21:59 <TemptorSent> Okay, where would one find such autogenerated provides and how do I tell apk that I need at least one provider of /usr/sbin/nbd-client installed?
22:01 <Shiz> hmm actually that might only happen for so's
22:01 <Shiz> that would go through for instance
22:01 <Shiz> apk add so:libssl.so.39
22:02 <Shiz> that'll install any package that provides that .so
22:02 minimalism joined
22:09 <TemptorSent> Yeah, for the libs I can manage, but the binaries and especially config/aux files are a real problem.
22:13 <TemptorSent> It might almost make sense to make subpackages for each of BB's toolsets, such as bb-nbd-client, bb-findutils, bb-vi, etc.
22:14 <TemptorSent> But I think there is an issue that needs to be addressed at a higher level of abstraction in apk to make things work sanely with such deps.
22:31 blueness joined