<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  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 _2_7  
28 29 30 31
00:24 qrwteyrutiyoup joined
00:44 lucybun joined
01:36 s33se_ joined
02:28 jirutka joined
02:39 minimalism joined
03:21 czart_ joined
05:22 fabled joined
05:48 minimalism joined
07:09 fekepp joined
07:22 zakame joined
07:22 <zakame> hi, how do I compile perl-5.24 without locale support? I'm experimenting building on alpine linux (which has somewhat incomplete locale support) and was encountering test failures
07:22 <zakame> for context, I'm trying to solve https://github.com/Perl/docker-perl/issues/23
07:44 t0mmy joined
07:50 black_ant joined
07:59 <tru_tru> zakame: same issue for me (incomplete locale support) and that's why some perl modules dont have "make test"
08:00 <tru_tru> https://gist.github.com/truatpasteurdotfr/e20019cd06027775284e19779ed79d67
08:00 black_ant joined
08:15 vakartel joined
08:35 vakartel joined
09:52 royger joined
09:52 leo-unglaub joined
09:58 <clandmeter> Shiz, can i close #7257 ?
09:58 <algitbot> Bug #7257: Update llvm-libunwind and add libc++abi and libc++ - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7257
10:28 <Shiz> yes
11:28 LouisA joined
11:32 <ncopa> i think we can get rid of ffmpeg2.8 \o/
11:32 <algitbot> \o/
11:33 Emperor_Earth joined
11:39 <ncopa> can we move grub to main?
11:39 <ncopa> i think its needed for the ppc64le iso
11:40 <^7heo> directly from testing?
11:43 <ncopa> yes
11:51 <^7heo> meh; I don't have a powerPC 64bit little endian.
11:51 <^7heo> So it won't affect me.
11:51 <^7heo> But so far I really tried to stay away from Grub.
11:51 <^7heo> it's kinda insane in complexity.
11:51 <^7heo> Anyway that's not a discussion about that specifically; if there's no other candidate for booting that arch...
11:51 <^7heo> I guess we have no choice.
11:52 <^7heo> But we should tag it as "risky" somehow and make that a very clear exception.
11:52 rdutra joined
12:14 <ncopa> can someone help me test if grub works at all on x86_64?
12:14 <ncopa> even in a vm
12:17 <^7heo> wait, are we replacing syslinux by grub?
12:23 <ncopa> no
12:23 <ncopa> but we need support grub
12:23 <ncopa> for some arches
12:24 <ncopa> which means we need move the grub package to main
12:24 <ncopa> before doing so i want verify that the package itself is ok
12:24 <ncopa> that it works
12:24 gromero joined
12:24 leitao joined
12:32 gromero joined
12:37 leo-unglaub joined
12:49 <_ikke_> ncopa: I can try testing it, but that will be only in a couple of hours
12:50 <^7heo> ncopa: I'd love to have an alternative to Grub for those arches.
12:50 <^7heo> s/arches/archs/
12:50 <^7heo> but I guess that time-wise it's not wise (aha)
12:51 <ncopa> :)
13:12 farosas joined
13:12 <ncopa> Shiz do you have url to the latest release notes?
13:24 <clandmeter> not sure if this is the latest https://txt.shiz.me/MGY0YTIxYz
13:27 <^7heo> nginx \o/
13:27 <algitbot> \o/
13:46 <leitao> rdutra, hi
13:46 <rdutra> leitao: hi
13:46 <leitao> rdutra, what qemu command did you use to boot alpine iso on ppc6l4?
13:46 <leitao> rdutra, ncopa wants to try it
13:47 <rdutra> leitao: ncopa: sudo qemu-system-ppc64 -enable-kvm -m 32G -smp 16,sockets=16,cores=1,threads=1 -nodefaults -nographic -serial stdio -cdrom <iso_name>
13:48 <ncopa> rdutra: i get openfirmware interface
13:48 <ncopa> but it does not boot the generated iso
13:49 <ncopa> Trying to load: from: disk ...
13:49 <ncopa> E3405: No such device
13:49 <ncopa> Trying to load: from: /vdevice/v-scsi@71000002/disk@8200000000000000 ...
13:49 <ncopa> E3404: Not a bootable device!
13:49 <rdutra> ncopa: umm. how you generated the iso?
13:49 <rdutra> ncopa: I mean, the command
13:50 <ncopa> sh scripts/mkimage.sh ...
13:50 <ncopa> sh scripts/mkimage.sh --outdir out --repository http://dl-cdn.alpinelinux.org/alpine/v3.6/main
13:51 <rdutra> ncopa: I used > ./mkimage.sh --profile vanilla --repository http://rsync.alpinelinux.org/alpine/edge/main/
13:52 <rdutra> ncopa: let me think...I also need to have "grub-ieee1275" installed to generate the correct ISO
13:52 <ncopa> aha
13:56 <ncopa> ha \o/
13:56 <algitbot> \o/
13:56 <ncopa> Linux localhost 4.9.28 #3-Alpine SMP Thu May 18 20:06:47 GMT 2017 ppc64le Linux
13:56 <leitao> nice
13:56 <rdutra> ncopa: :)
13:57 <ncopa> i suppose the setup script will not work though
13:58 <ncopa> since it hardcodes syslinux iirc
13:58 <ncopa> but at least it boots
13:58 <ncopa> this is great
14:01 <rdutra> ncopa: when I run the "setup-alpine" script, in the part that it calls "setup-disk" it returns "No disks found."
14:01 <rdutra> ncopa: not sure if it is related with syslinux or because booting inside qemu
14:05 <ncopa> probably because the script does someting stupid, like assume that disk should be /dev/sd*
14:14 <leitao> rdutra, which disks do you see when you run the setup script?
14:17 <rdutra> leitao: umm..it does not show me any information about disks
14:19 <leitao> fdisk -l shows anything?
14:19 vakartel1 joined
14:20 <rdutra> leitao: no, shows nothing
14:20 <leitao> rdutra, did you attach a disk ?
14:20 <leitao> rdutra, this command " sudo qemu-system-ppc64 -enable-kvm -m 32G -smp 16,sockets=16,cores=1,threads=1 -nodefaults -nographic -serial stdio -cdrom <iso_name>" does not seem to have a disk attached.
14:22 <rdutra> leitao: umm, I will see how to attach a disk do qemu command
14:22 <leitao> rdutra, starts qemu with a disk
14:22 <leitao> it should be easier.
14:23 <ncopa> we build the x86/x86_64 iso images as isohybrids
14:23 <ncopa> so they show up as disks for qemu
14:53 <Shiz> jirutka: >K. Wang, Y. Lin, S. M. Blackburn, M. Norrish, and A. L. Hosking, "Draining the Swamp: Micro Virtual Machines as Solid Foundation for Language Development",
14:53 <Shiz> questionable paper name choices
15:24 <ncopa> do we have anything that needs be fixed before rc2?
15:26 <Shiz> the udhcpc thing preferably imo
15:27 <Shiz> ncopa: also ok to move julia to community?
15:27 <Shiz> most of the testsuite passes
15:27 <ncopa> how long time does it take to build (on arm)
15:27 <Shiz> building doesn't take very long
15:27 <Shiz> the testsuite is a bit longer, we can disable it on arm?
15:27 <ncopa> possibly
15:28 <ncopa> how long does it take?
15:28 <ncopa> its nice to run it though
15:28 <Shiz> it takes about 25 mins to build + test on the x86_64 builder
15:28 <Shiz> iirc
15:29 <ncopa> so atleast an hour on arm
15:30 <Shiz> but it's only enabled for x86_64 right now
15:30 <ncopa> ok
15:30 <ncopa> i suppose then push it
15:31 <Shiz> aight
15:31 <ncopa> re iso vomlume id
15:31 <ncopa> -volid "alpine-$PROFILE $RELEASE $ARCH"
15:31 <Shiz> don't need to bump pkgrel right?
15:31 <ncopa> should not be needed
15:31 <ncopa> you dont need bump pkgrel
15:32 <ncopa> xorriso : WARNING : -volid text problematic as automatic mount point name
15:32 <ncopa> xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
15:32 <Shiz> hmm
15:32 <Shiz> probably doesn't like spaces?
15:33 <Shiz> it it <= 32 chars?
15:35 <Shiz> ncopa: "Specifies the volume ID text. (32 chars out of [A-Z0-9_])","
15:36 <Shiz> it has to be said that apparently nobody cares about this restriction
15:36 <Shiz> ncopa: do we use joliet?
15:37 <Shiz> because that allows for less restricted volids
15:38 <ncopa> yes we use joilet
15:38 <ncopa> seems loike nobody cares
15:38 <ncopa> OpenBSD/amd64 6.1 boot-only CD
15:38 <ncopa> Gentoo Linux amd64 20170209
15:38 <ncopa> Linux Mint 18.1 MATE 32-bit
15:38 <ncopa> except freebsd
15:38 <Shiz> yep
15:38 <ncopa> seems to comply
15:38 <ncopa> 11_0_RELEASE_P1_AMD64_BO
15:39 <ncopa> i remember having issues with < 32 earlier
15:39 <Shiz> oh
15:39 <Shiz> ncopa: actually
15:39 <Shiz> it seems like it includes a restricted shell char too
15:40 <ncopa> ok?
15:40 <Shiz> that set is limited to [a-zA-Z_-+=:.,~@]
15:40 <Shiz> i guess that's again the space
15:40 <Shiz> that's 'automatic mount point name' warning
15:40 <ncopa> ok
15:40 <ncopa> i am open to suggestion what we set it too
15:41 <ncopa> we keep it as is?
15:41 <Shiz> i think it's fine as it is
15:43 <ncopa> it will likely be difficult to change once we have it implemented in libosinfo
15:43 <ncopa> ok, lets keep it as is
15:44 <ncopa> one thing that would be nice to find out before release, is why did virtharden kernel module doube size (in the 4.4 -> 4.9 upgrade)
15:45 <Shiz> hmm
15:45 <Shiz> what's libosinfo?
16:16 <ncopa> library and database with OS information
16:16 <ncopa> virt-manager uses it when creating new virtual machines
16:42 Topic for
16:53 t0mmy joined
17:02 <_ikke_> ncopa: Do you still need someone to test grub?
17:02 NIN101 joined
17:03 <ncopa> _ikke_: would be nice if you have time
17:03 <_ikke_> sure
17:04 <_ikke_> ncopa: default image?
17:04 <ncopa> sure
17:54 vakartel joined
17:55 <_ikke_> grub-install returns "failed to get cannonical path of /boot/grub", anyone familiar with that error?
17:56 <_ikke_> (I'm chrooted in the new installation)
17:57 kunkku joined
17:57 <_ikke_> ok, forgot to mount proc/sys/dev
18:08 cyteen joined
18:09 <_ikke_> Next issue: cannot find grub drive for /dev/sda1, check your device.map
18:11 <leo-unglaub> hey friends, i have a quick question
18:11 <leo-unglaub> what was the tought behind the current naming convetion of the alpinelinux nameservers?
18:11 <leo-unglaub> currently beeing ns1.alpinelinux.org and ns2.alpinelinux.org
18:12 <leo-unglaub> is it not normal to use a.ns.alpinelinux.org and b.ns.alpinelinux.org for that anymore?
18:12 <Shiz> i don't think i've ever seen a.ns and b.ns
18:12 <Shiz> anywhere, to be honest
18:13 <leo-unglaub> it was an old standard to but got replaced by the ns1 and ns2 in a lot of places
18:13 <_ikke_> Why would you need to refer to them in the first place?
18:13 <Shiz> _ikke_: because how else is it gonna find which nameservers serve your domain? :P
18:13 <leo-unglaub> the reason i am asking is that there was a reason for using a.ns and b.ns but i forgot it
18:13 <leo-unglaub> and i would need that for an article i am writing :(
18:27 <clandmeter> kaniini, can you take a look at #7155
18:27 <algitbot> Feature #7155: Xen: Enable livepatch - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7155
18:28 <_ikke_> Anyone know why grub-probe says cannot find grub device for dev/sda1?
18:30 <Shiz> leo-unglaub: probably just in the spirit of the hierarchical nature of DNS
18:30 <clandmeter> grub is a pita
18:30 <Shiz> "ns.x" hosts all nameservers, "a.ns.x" is the first, etc
18:30 <_ikke_> yeah, I'm trying to test it for ncopa
18:31 <clandmeter> i remember those errors when i needed to boot aarch64
18:31 <lxGzx53qO34r> leo-unglaub: isn't that the naming convention for the root nameservers of which there is more than usually 2?
18:31 <leo-unglaub> yeah, exactly
18:31 <_ikke_> I'm in a chroot right now, it seems to have placed the files in the boot dir, but fails at installing the bootloader
18:31 <leo-unglaub> they use it
18:32 <clandmeter> install bootloader from chroot?
18:34 <_ikke_> clandmeter: yeah
18:34 <_ikke_> That's how you usually, do it, right?
18:35 <clandmeter> let me see if i can find a script i used
18:36 <TBB> you'll need access to the device, which means bind mounting /dev to the chroot, correct?
18:37 <_ikke_> I did
18:37 <_ikke_> mount -obind /dev /mnt/dev
18:38 <Shiz> better is --rbind i think
18:38 <TBB> next on my list of guesses would be a specific grsec option on the host side
18:47 <clandmeter> _ikke_, the script i made is for a bootable hybrid uefi iso with grub, so it wont help you much.
18:50 <_ikke_> ok
18:59 ingo__ joined
19:04 <_ikke_> thanks anyway
19:11 fekepp joined
19:28 <clandmeter> _ikke_, did you mount proc?
19:47 <_ikke_> clandmeter: I ddi
19:47 <_ikke_> did
19:47 <_ikke_> mount -t proc none /mnt/proc
19:47 <clandmeter> what if you bind mount it?
19:48 <_ikke_> let me try
19:48 <clandmeter> both dev and proc
19:48 <_ikke_> Right, still the same issue
19:48 <_ikke_> mount --rbind /proc /mnt/proc
19:48 <_ikke_> same for dev
19:48 <clandmeter> which error do you get?
19:50 <_ikke_> http://tpaste.us/djbL
19:50 <clandmeter> hmm, it works for me.
19:52 <_ikke_> How did you setup the disk?
19:54 <clandmeter> one partition ext4 and apk install --root...
19:54 <_ikke_> ok, let me try that
19:54 <clandmeter> it doesnt boot though :)
19:54 <clandmeter> but it says its installed
19:54 <_ikke_> hehe
19:55 <clandmeter> i think i need to use ext2
19:57 <clandmeter> _ikke_, http://tpaste.us/40bX
19:59 <_ikke_> apk install is not a command?
20:00 <clandmeter> lol
20:00 <clandmeter> my mistake...
20:00 <clandmeter> just apk add ...
20:00 <clandmeter> with root
20:00 <_ikke_> no such file or directory
20:01 <clandmeter> wait let me give you the whole cmd
20:03 <clandmeter> apk add --keys-dir /etc/apk/keys --repositories-file /etc/apk/repositories --root my/disk --update-cache alpine-base grub-bios
20:03 <clandmeter> thats from my head...
20:03 <_ikke_> 5ok
20:04 <clandmeter> after it installs base alpine you can bind dev and proc
20:04 <clandmeter> and then chroot and grub-install
20:06 <_ikke_> Looks like I'm still missing something in that apk command
20:08 <_ikke_> --initdb?
20:08 <clandmeter> yes
20:08 <clandmeter> sorry
20:08 <clandmeter> missed that one
20:09 <_ikke_> That worked
20:10 <clandmeter> nice
20:11 <clandmeter> grub-install as well?
20:12 <_ikke_> Not yet
20:12 <_ikke_> But I have 2 partitions, one ext2, other ext4
20:13 <_ikke_> You just have one ext4 partition?
20:13 <clandmeter> yes
20:13 <clandmeter> but it shouldnt matter as long you provide the correct device where your boot is located.
20:13 <_ikke_> I do, but still the same error
20:14 <clandmeter> can you add strace and check what happens?
20:14 <_ikke_> I can
20:15 <clandmeter> seems my error is related to vmware
20:16 <clandmeter> you could also try to add --verbose and see if it tells you more.
20:21 <_ikke_> hmm, any way to update /dev nodes? I formatted the disk, but not new /dev/sda* nodes are created
20:23 <_ikke_> already tried partprobe, but not helping
20:23 <_ikke_> mdev -s
20:31 dave_9911 joined
20:36 Fooster joined
20:39 <_ikke_> http://tpaste.us/ELx6
22:38 <leo-unglaub> jirutka: have you ever thought about the security implications of building the entire aports tree statically linked?
22:40 <jirutka> leo-unglaub: yes
22:40 <jirutka> leo-unglaub: why?
22:41 <leo-unglaub> well, i cannot sleep and started thinking ... thats just how my mind works *g*
22:42 <jirutka> leo-unglaub: XD
22:42 <jirutka> leo-unglaub: is your mind statically linked? :P
22:42 <leo-unglaub> yes ... hehehehe
22:42 <leo-unglaub> but think about the implications that would have ... an statically linked alpine
22:43 <leo-unglaub> the disc size would grow up a little bit, but it would get the heck of a lot faster
22:43 <Shiz> i don't think it would be significantly faster
22:43 <jirutka> not sure about performance, but it’d be more secure and unbreakable :P
22:44 <Shiz> more secure, having to replace all binaries when we find another vuln in libressl?
22:44 <Shiz> ;)
22:44 <jirutka> is that a problem?
22:44 <Shiz> yes, people will upgrade less fast if they have to download 200mb of binaries
22:44 <leo-unglaub> well, in my lab i test stuff like this simetimes and it fully depends on the binary created ... but usually with small libraries you get around 10% more speed because you have less different io reads to get all depending .so files
22:44 <Shiz> there's also the thing that not all aports stuff supports static PIE
22:45 <leo-unglaub> download size is not a problem, just do delta updates
22:45 <jirutka> you just need to keep track what pkgs embeds what libs and rebuild/update all of them when sec vul. found
22:45 <Shiz> like go, i think
22:45 <leo-unglaub> even windows 10 does delta updates now
22:45 <Shiz> leo-unglaub: we'd need to rearchitecture apk for that
22:45 <Shiz> not likely to happen anytime soon
22:45 <jirutka> yeah
22:46 <leo-unglaub> Shiz: i am not talking about doing it this weekend ...
22:46 <leo-unglaub> its just part of my job as a security auditor
22:46 <jirutka> IMHO liberation from FHS will bring more benefits than statically linked binaries
22:46 <Shiz> jirutka: 'just need to keep track' is not as easy as it sounds
22:47 <Shiz> oh yeah
22:47 <Shiz> i talked with dalias about the /pkgs stuff
22:47 <Shiz> or /pkg, whatever
22:47 <leo-unglaub> well, keeping track is the easy part
22:47 <leo-unglaub> because we alredy have this information today in apk
22:47 <Shiz> his suggestion was to symlink all libs needed in /pkg/$name/$version/lib
22:47 <leo-unglaub> the automatically dependenty tracker
22:47 <Shiz> and set an rpath of $ORIGIN/../lib in all binaries
22:47 <Shiz> leo-unglaub: nope
22:47 <Shiz> that only works for dynamically linked binaries
22:47 <Shiz> :)
22:47 <Shiz> that is one of its axioms in fact
22:48 <leo-unglaub> yes, but we have the information once ... moving this part into compiletime is not that hard and export a .depends file to keep track of when to recompile
22:48 <leo-unglaub> thats the smallest problem with it
22:48 <Shiz> (btw cc kaniini on this)
22:49 <Shiz> leo-unglaub: the part is already in compiletime
22:49 <Shiz> but it simply can not track dependencies for static output
22:49 <Shiz> you can export from a dynamically linked compile once, but who says it's 1) identical to the static version 2) kept up to date
22:49 <TemptorSent> Tracking the deps isn't all that hard, but it would need to be handled at link time.
22:49 <Shiz> there's also the thing where static linking has no SONAME stuff
22:49 <Shiz> so you don't know when to recompile in light of SONAME bumps
22:50 <leo-unglaub> Shiz: during a static linking just track what the linker does and export the data during every build fpr every version
22:50 <Shiz> what the linker does where?
22:50 <Shiz> you realise a linker may link many binaries
22:50 <Shiz> and not all of them present in the final package
22:50 <Shiz> we don't integrate with build systems on that level
22:50 <leo-unglaub> YET! ;)
22:51 <Shiz> and we won't if i have anything to say about it
22:51 <Shiz> :P
22:51 <jirutka> TemptorSent: btw if you’d like to practice your shell-fu, we still need a proper script for ABI breakage detection; not necessarily real ABI comparison, just need to know if dependent pkgs must be rebuilt when upgrading pkg providing some shared libs
22:51 <Shiz> simply because it's not feasible and doesn't scale
22:51 <TemptorSent> We need some of that to fix the build-deps discovery.
22:52 <Shiz> jirutka: don't we have SONAME checks for that right now?
22:52 <jirutka> Shiz: no, we don’t
22:52 <jirutka> Shiz: we have only checkapk (or apkcheck?) and it do only diff of pkg files, not very usaable for automation
22:53 <Shiz> right
22:53 <TemptorSent> jirutka: I have full revdep detection working for shared libs, but it doesn't look at actual ABI -- that requires build-time modifications.
22:54 <jirutka> TemptorSent: we already know what pkgs depends on the pkg being rebuild
22:54 <TemptorSent> The ABI comparison tools that I've looked at rely on a build with debug symbols.
22:54 <jirutka> TemptorSent: apk tracks shared libs etc.
22:54 <jirutka> TemptorSent: hm, maybe we can build -dbg subpkg automatically for all…?
22:55 <jirutka> TemptorSent: IIRC debian do this, all pkg automatically have some pkg with debug symbols
22:55 <TemptorSent> That's a possibility...
22:55 <kaniini> jirutka no
22:55 <jirutka> no chance without debug symbols?
22:55 <kaniini> it is maintainer opt in
22:55 <TemptorSent> And that would allow us to use the ABI checker tools.
22:55 <jirutka> kaniini: yes, currently… why we can’t make it default?
22:55 <kaniini> ubuntu has -dbgsym which is unconditional
22:55 <kaniini> but debian does not
22:55 <jirutka> doesn’t matter…
22:56 <TemptorSent> Not really anything solid w/o debug symbols because the prototyping isn't stored once debug symbols are removed.
22:56 <Shiz> i don't think it's worth testing for abi breakage aside from SONAME to be honest
22:56 <jirutka> is there some reason why we should not enable -dbg by default for e.g. all pkgs that provides some shared libs?
22:56 <kaniini> i was just clarifying that your example is not correct :)
22:56 <kaniini> no we absolutely should enable -dbg by default
22:56 <Shiz> jirutka: btw, enabling -dbg on julia stripped it down by 25mb
22:56 <Shiz> lol
22:57 <jirutka> eh, what?
22:57 <jirutka> aha, yes
22:57 <jirutka> b/c I did it wrongly before
22:57 <Shiz> from 70mb to a bit over 40mb
22:57 <Shiz> i renamed julia-debug to julia-dbg and called default_dbg in the split func
22:57 <TemptorSent> ABI breakage tessting will allow us to determine if an existing package is going to break when compiled against the new version of a lib.
22:57 <jirutka> our -dbg does not produce full binary with debug symbols, just debug symbols
22:57 <Shiz> :P
22:57 <Shiz> TemptorSent: that's the entire purpose of SONAME
22:57 <kaniini> i agree with shiz soname is fine
22:58 <jirutka> it’s not…
22:58 <kaniini> we just need more intelligence in the build tools
22:58 <jirutka> b/c foo.so.1.2.3
22:58 <kaniini> stupid maintainers are stupid and we fix the soname in those cases
22:58 <jirutka> when foo.so.1.2.3 → foo.so.1.2.4, it’s usually not needed to rebuild all depending pkgs
22:58 <Shiz> jirutka: that's
22:58 <Shiz> not how sonames work
22:58 <kaniini> yes that's not the soname tho
22:58 <jirutka> but this relies on particular versioning schema
22:58 <TemptorSent> SONAME doesn't tell you if an updated lib breaks an existing API/ABI for a particular function.
22:58 <kaniini> the soname is foo.so.1
22:58 <kaniini> anyway
22:59 <jirutka> ??
22:59 <Shiz> it actually does exactly that, TemptorSent
22:59 <Shiz> jirutka: SONAME is a field in the ELF .so file
22:59 <Shiz> when you break ABI, you bump it
22:59 <Shiz> it has little to do with the filename
22:59 <jirutka> uh, aha
22:59 <Shiz> e.g.
22:59 <jirutka> what if author does not bump it?
22:59 <Shiz> then upstream is stupid :p
23:00 <Shiz> it's their responsibility to bump soname when they break ABI
23:00 <TemptorSent> I've quite often run into minor revs that broke specific functions.
23:00 <kaniini> then we fix it downstream
23:00 <Shiz> i think automated ABI testing is better fixed by implementing a check() for all packages
23:00 <Shiz> just saying
23:00 <Shiz> ;)
23:00 <jirutka> yes, it is, we know that, that’s why I think that detecting real ABI breakage would be good
23:00 <kaniini> what shiz says
23:00 <kaniini> anyway
23:00 <jirutka> no, we don’t rerun check in all depending pkgs when we upgrade som epkg…
23:01 <Shiz> the problem is that "ABI testing" is an unsolvable issue
23:01 <Shiz> ABI means literally everything, from the tiniest changes in how a library behaves
23:01 <Shiz> and a lot of changes are justified
23:01 <TemptorSent> Also, detecting NON breaking changes in SONAME bumbs is useful as well, as we can determine if a specific package using a specific API will work with the newer lib or not.
23:01 <Shiz> e.g. if the documentation states you should not rely on something
23:01 <kaniini> this conversation annoys me
23:01 <Shiz> how are you gonna exhaustively test if a library behaves differently
23:01 <kaniini> somebody tell me when 3.6 is out
23:01 <jirutka> $ readelf -a /usr/lib/libcares.so.2.2.0 | grep SONAME # → 0x000000000000000e (SONAME) Library soname: [libcares.so.2] … hmm
23:01 <Shiz> and whether those changes are justified
23:02 <Shiz> jirutka: yeah
23:02 <Shiz> you bump the last digit when you break ABI
23:02 <Shiz> so it would be beumped to libcares.so.3
23:02 <kaniini> if you like overengineered solutions i hear Nix and Guix are things
23:02 <jirutka> okay, so back to the task… we need proper script that would compare at least this ;)
23:02 <kaniini> it is all i have to say on it
23:03 <TemptorSent> See https://lvc.github.io/abi-compliance-checker
23:03 <Shiz> jirutka: agree :)
23:03 <jirutka> and just return boolean value, not full diff of all files
23:03 <kaniini> apks contain all soname as providers
23:03 <jirutka> so we can use it for automation, at least automatically add comment to PR that some pkgs needs to be rebuilt
23:03 <jirutka> I know
23:03 <Shiz> jirutka: that sounds fine
23:04 <kaniini> the build scripts can use that data to see what needs rebuild
23:04 <Shiz> TemptorSent: sure, this tests for differences, but it doesn't meaningfully make it automatable
23:04 <Shiz> that is my point
23:04 <Shiz> it tells you what's different, but the problem with ABI breakage is not what is different
23:04 <Shiz> it is what is different AND documented
23:04 <jirutka> but I don’t have time right now to write that script, even when it’d be probably easy, so just letting now ;)
23:05 <TemptorSent> The detection of differences can be automated and if something differs, it can be flagged for manual review.
23:05 <Shiz> then everything will be flagged every update
23:05 <Shiz> have you seen the reports it outputs
23:05 <jirutka> at least if we know that there’s SOME difference, we can trigger rebuild of depending pkgs and if they have check() and proper tests, we would know…
23:06 <TemptorSent> Yeah, I don't love the reporting in that particular one.
23:06 <Shiz> jirutka: talking about soname or the abi checker now?
23:06 <kaniini> TemptorSent: with all due respect there are far more critical needs than this. SONAME checks are good enough for now.
23:06 <TemptorSent> But the error codes are probably enough for breakage detection.
23:06 <Shiz> because my fear is the abi checker will just flag every package upgrade, keeping us needlessly busy
23:06 <jirutka> ideally ABI checker, but soname would be good enough for now
23:07 <Shiz> anyway yeah, soname checking seems good
23:07 <TemptorSent> kaniini: Agreed - the ABI checking is not immediately critical.
23:07 <TemptorSent> What sonames are NOT checked currently?
23:08 <Shiz> all of them
23:08 <TemptorSent> It seemed that abuild didn't necessarily follow the dep chain to discover packages from solibs.
23:08 <Shiz> actually
23:08 <TemptorSent> On the apk side, this works, right kaniini?
23:09 <Shiz> jirutka: checkapk does in fact check SONAMEs
23:09 <Shiz> separately from the rest of the files
23:09 <kaniini> this channel is getting bad for my health
23:09 <jirutka> Shiz: but the result is quite useless
23:09 <jirutka> currently
23:09 <Shiz> sure, but there's not a lot that needs to be changed to make it useful
23:09 <Shiz> :P
23:09 <TemptorSent> does checkapk recurse the deptree?
23:10 <Shiz> no, why would it
23:11 <Shiz> it only needs to check if the provides change
23:11 <Shiz> for soname
23:12 <kaniini> right then it queries apkindex to learn the depends
23:12 <kaniini> er rdepends
23:12 <jirutka> I need to go sleep now, I must get up very early tomorrow; I hope that you understand what is the goal I’d like to achieve, so please discuss what is the best way to it ;)
23:12 <TemptorSent> Hmm.. The cases I'm concerned with is a bin which deps on a lib which deps on another lib, where the bin uses a header for the second lib but doesn't link it directly.
23:13 <* kaniini> headdesks
23:13 <Shiz> that wouldn't matter at all
23:13 <TemptorSent> I'm afraid I'm not sure exactly which problem you're currently working to solve jirutka.
23:13 <jirutka> TemptorSent: uh, what?
23:13 <Shiz> it would flag the intermediate lib, which would need to be rebuilt
23:13 <Shiz> if it doesn't link against it...
23:13 <Shiz> and this all seems extremely corner-casey
23:13 <TemptorSent> Yeah, one I'
23:13 <TemptorSent> ve hit
23:13 <Shiz> anyway
23:13 <jirutka> maybe I’ve missed something, but transitive dependencies are not a problem in this case, are they?
23:14 <Shiz> no
23:14 <TemptorSent> Usually it's a struct defined in the lower level lib that's used in the bin directly.
23:14 <Shiz> jirutka: here's my thought before you go to bed:
23:14 <Shiz> a modification to the travis script and checkapk
23:14 <Shiz> checkapk outputs a list of changed sonames
23:14 <Shiz> and the packages that depend on it
23:15 <Shiz> travis checks at the end of the session if those packages were rebuilt too
23:15 <Shiz> if not, it fails the build
23:15 <TemptorSent> So the transitive deps shouldn't be a problem if the package deps on ALL libs it uses structs of.
23:15 <jirutka> but what about foo.so.1.2.3 → foo.so.1.2.4? does it need rebuild as well? please note that checkapk compares only file names, not real SONAME in ELF binary
23:15 <Shiz> jirutka: wrong
23:15 <Shiz> it checks the real soname
23:15 <TemptorSent> Shiz - That sounds like it would solve the immediate problem quite nicely.
23:16 <jirutka> hm, I need to verify it…
23:16 <Shiz> jirutka: https://git.alpinelinux.org/cgit/abuild/tree/checkapk.in#n82
23:16 <Shiz> it's a separate check from the file list check
23:16 <jirutka> grr, it’s output is really extremely confusing
23:16 <kaniini> jirutka: it checks real soname
23:16 <jirutka> aha
23:17 <Shiz> anyway
23:17 <Shiz> this would enforce that any PR that breaks soname also includes commits to bump the relevant pkgrels
23:17 <Shiz> or the travis build fails
23:17 <TemptorSent> In-depth API/ABI compatability analysis is something to work on for supporting devs and automated bumps.
23:17 <jirutka> but then I don’t understand foo.so.x.y.z, cause I’ve seen many times when checkapk printed diff with just change in <z>
23:17 <jirutka> so are these totally unrelated or what?
23:17 <jirutka> no, it should not fail build
23:17 <Shiz> checkapk prints both a changed filelist and changed sonames
23:17 <jirutka> just warn
23:17 <Shiz> no, it should fail
23:18 <jirutka> aha
23:18 <Shiz> packages will fail to load if the soname was bumped
23:18 <Shiz> they will not work anymore
23:18 <jirutka> no it definitely should not
23:18 <Shiz> at all
23:18 <jirutka> think about consequences
23:18 <Shiz> you break packages if you update soname and not the packages
23:18 <jirutka> look, ideally we need two checks
23:19 <jirutka> so contributor can know if the pkg itself is okay and/or there is need to bump some other pkgs
23:20 <TemptorSent> jirutka: I'm not sure you can do that without first building the newer pkgs to compare with anyway.
23:20 <jirutka> eh?
23:21 <jirutka> okay, I go sleep, it seems that I’m too tired to properly express my thoughts or dunno :)
23:21 <TemptorSent> If anything, the abi checking might be useful to determine the LAST version of a lib to work with a particular version of a package, but checking newer ones requires building the new libs first and comparing against the old.
23:21 <Shiz> :P
23:22 <TemptorSent> jirutka: Get some sleep and poke at it more when you're fresh.
23:22 <jirutka> ofc it requires building one, I thouhht that it is very obvious…
23:22 <jirutka> yeah, lack of sleep is bad :(
23:23 <TemptorSent> Autobumping isn't the easiest to solve, since you don't know what version to bump TO automatically for the deps.
23:24 <TemptorSent> Doing that would require source analysis and comparison of prototypes between both old and new packages and old and new libs (possibly trying many version to match)
23:24 <Shiz> and that's out of scope
23:24 <TemptorSent> Agreed.
23:27 <TemptorSent> A heuristic approach and flagging manual intervention is probably doable, but since we don't build and store every version of every dep, we'll only be able to say a specific build did or did not match, not ask which version did.
23:28 <TemptorSent> (unless the metadata for previous versions of a package is stored somewhere?)
23:29 <TemptorSent> I guess the question that needs to be answerable for proper versioning is 'In which version of $pkg did SONAME last have the value of X and in which version did it first have the value of Y
23:32 <TemptorSent> That would allow you to determine the proper dep version string required.
23:36 LouisA joined
23:41 <TemptorSent> abi-compliance-checker DOES look very useful as a tool for Contributors and QA, but probably in a semi-automated fashion.