2020-08-01 09:14:55 <mps> maxice8: !10801 if you have time
2020-08-01 09:19:46 <mps> s390x CI is stuck or ?
2020-08-01 09:20:25 <maxice8> s390x likes to take long breaks
2020-08-01 09:21:30 <mps> vacation season on north hemisphere :)
2020-08-01 09:30:01 <mps> maxice8: above MR shows fail because of s390x stuck
2020-08-01 09:30:15 <maxice8> ignore it
2020-08-01 09:31:37 <ikke> quite a bit of a backlog on s390x
2020-08-01 09:32:51 <Newbyte> what's the status on armv7?
2020-08-01 09:33:09 <Newbyte> most packages seem to be up but kaccounts-providers is gone still
2020-08-01 10:10:46 <PureTryOut[m]> Does anyone dare to merge !10325? CI is only failing because of too many packages to upload as artifacts, and the 32-bit rebuild still going on causing bad signatures when installing some deps
2020-08-01 10:25:05 <maxice8>  Fast-forward merge is not possible. To merge this request, first rebase locally.
2020-08-01 10:35:48 <PureTryOut[m]> Don't you always rebase locally? I can do it in a sec
2020-08-01 10:38:24 <PureTryOut[m]> maxice8: actually, preferably !10601 gets merged first
2020-08-01 10:39:01 <maxice8> done
2020-08-01 10:39:31 <PureTryOut[m]> Awesome thanks!
2020-08-01 10:43:36 <PureTryOut[m]> maxice8: rebased
2020-08-01 10:47:35 <maxice8> Currently merging stuff from others
2020-08-01 10:47:55 <maxice8> 97% tests passed, 2 tests failed out of 59
2020-08-01 10:48:04 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/akonadi/akonadi-20.04.2-r1.log
2020-08-01 10:48:04 <maxice8> @PureTryOut ^
2020-08-01 10:51:47 <nmeum> with firefox using python3 now and rethinkdb removed only 6 packages left which require python2 \o/
2020-08-01 10:52:12 <PureTryOut[m]> ok wtf why do they suddenly fail?
2020-08-01 10:52:33 <nmeum> not sure if chromium manages to upgrade to python3 in time for 3.13, ancient mozjs version will probably also be a problem
2020-08-01 10:53:47 <maxice8> @PureTryOut s390x doesn't obey the normal laws of our universe
2020-08-01 10:54:03 <PureTryOut[m]> I believe that now yes
2020-08-01 10:54:12 <PureTryOut[m]> It passed s390x CI damn it
2020-08-01 10:54:28 <PureTryOut[m]> Maybe just retry it?
2020-08-01 10:58:11 <PureTryOut[m]> Nope, just retrying it doesn't make it succeed, wtf
2020-08-01 10:58:20 <PureTryOut[m]> Guess I'll disable those 2 tests for now
2020-08-01 11:14:07 <ikke> ugh, apk upgrade -U on x86 edge breaks apk
2020-08-01 11:14:20 <ikke> it first upgrades apk-tools before upgrading musl, and then it's broken
2020-08-01 11:17:41 <mps> safety rule, apk add apk-tools-static
2020-08-01 11:21:32 <ikke> sure, but just running apk ugrade while not changing major version should not break
2020-08-01 11:25:14 <PureTryOut[m]> maxice8: !10894
2020-08-01 11:25:27 <maxice8> done
2020-08-01 11:35:56 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/open-vm-tools/open-vm-tools-11.1.0-r3.log
2020-08-01 11:36:03 <maxice8> openvm-tools seem to have a time related failure
2020-08-01 11:39:27 <Cogitri> > ERROR: meson-vim-0.54.3-r1: BAD signature
2020-08-01 11:39:27 <Cogitri> What was the command to run to purge packages again?
2020-08-01 11:43:18 <ikke> curl -XPURGE URL
2020-08-01 11:43:56 <ikke> apparently cogitri purged himself :P
2020-08-01 11:48:48 <nmeum> ikke: re: musl and apk on x86, we could just add musl>=1.2.0 to depends
2020-08-01 11:49:04 <nmeum> that should force apk to upgrade musl first and then apk
2020-08-01 11:56:16 <PureTryOut[m]> maxice8: !10325 is good to go now
2020-08-01 11:56:26 <maxice8> Will look later
2020-08-01 11:56:27 <maxice8> playing chess
2020-08-01 11:56:35 <PureTryOut[m]> It'll clear my repology list a whole lot 😛
2020-08-01 11:56:37 <PureTryOut[m]> Lol ok
2020-08-01 11:58:19 <MY-R> damn emoji! I changed my terminal to termite to see them!
2020-08-01 11:59:33 <nmeum> alacritty is also capable of displaying emojis
2020-08-01 12:00:38 <PureTryOut[m]> Every terminal with utf-8 support should be able to display them no? Just make sure you have a proper font installed for it
2020-08-01 12:00:55 <ikke> no, not necessarily
2020-08-01 12:01:03 <MY-R> hmm I was thinking about alacritty, I will try it
2020-08-01 12:01:59 <MY-R> te see those black/white emoji need just utf8
2020-08-01 12:02:26 <MY-R> problem is with color ones
2020-08-01 12:07:11 <MY-R> but looks like not always, in urxvt many times saw just black squares, ok, end off topic, sorry! and thanks nmeum for recommendation
2020-08-01 12:07:57 <mps> MY-R: st term
2020-08-01 12:09:16 <ikke> where you need to collect patches to get functionality :P
2020-08-01 12:13:21 <MY-R> mps, I like to have something what can configure but also need something what will work out of the box :D another reason why I prefer to use bash... :\
2020-08-01 12:16:26 <Ganwell> MY-R: you have to enable to color emoji. Let me search it.
2020-08-01 12:17:22 <ikke> hmm?
2020-08-01 12:17:23 <Ganwell> MY-R:  something like that: https://gist.github.com/IgnoredAmbience/7c99b6cf9a8b73c9312a71d1209d9bbb . I haven't tested that particular gist.
2020-08-01 12:17:47 <ikke> Is that for konsole?
2020-08-01 12:18:18 <Ganwell> No
2020-08-01 12:18:24 <Ganwell> For any terminal
2020-08-01 12:18:44 <Ganwell> It was just the first gist with fontconfig I found
2020-08-01 12:19:29 <Ganwell> MY-R: here is another one: http://flammie.github.io/dotfiles/fontconfig.html
2020-08-01 12:19:59 <Ganwell> MY-R: fontconfig has many ways to achive the same thing. let me see I find my old config.
2020-08-01 12:20:37 <MY-R> Ganwell, well emojis working for me  everywhere without problem, problem is urxvt which support only those single color ones
2020-08-01 12:20:44 <ikke> yea, indeed
2020-08-01 12:20:50 <Ganwell> MY-R: be aware any application using libxft will crash on color emojis. There aren't many left.
2020-08-01 12:21:35 <Ganwell> MY-R: urxvt probably uses libxft and they are disabling color to avoid the crash.
2020-08-01 12:22:02 <Ganwell> MY-R: https://git.suckless.org/st/file/FAQ.html#l224
2020-08-01 12:22:05 <mps> I added Symbola fonts in ~/.fonts, license don't allow distribution
2020-08-01 12:22:39 <MY-R> dunno, or 256 colors arent enough :D
2020-08-01 12:22:40 <mps> no color emojis but I don't like color emojis :)
2020-08-01 12:23:36 <mps> hmm, I don't like any emoji
2020-08-01 12:23:51 <MY-R> arent so bad, more "readable" from those mono ones or I would have to increase font size to the point where could see max 30 lines of text on screen :D
2020-08-01 12:23:53 <Ganwell> MY-R: I can confirm that all alacritty works with color emoji. In my color emoji phase I switched from st to alacritty
2020-08-01 12:24:48 <MY-R> I was using something with GPU acceleration kitty and something was wrong with it and alacritty looks for now more "adult"
2020-08-01 12:25:05 <MY-R> termite also working fine but is kind of slow - vte
2020-08-01 12:25:43 <Ganwell> MY-R: Actually I am not sure about alacritty, sorry I can't remember with what terminal I finally got color emoji. But it was a big waste of time. In the end I hated color emojis and went back to st.
2020-08-01 12:26:40 <Ganwell> But back then I had to switch in noto to get the color emojis. Maybe the are now finally complete fonts with color emoji, so that fontconfig is not needed anymore.
2020-08-01 12:28:50 <Ganwell> @MY-R: If you get color emojis with alacritty, I'd use it. I liked it the most of all the terminals I was try. Except of course st which I love.
2020-08-01 12:36:48 <Ganwell> mps: at work they are doing commit messages with emojis. at least they don't bother me to do the same.
2020-08-01 12:39:09 <mps> huh, funny :)
2020-08-01 12:40:40 <Ganwell> https://gist.github.com/parmentf/359667bf23e08a1bd8241fbf47ecdef0
2020-08-01 12:41:57 <MY-R> Ganwell, ye color emojis working with noto font fine, and configuration file looks nice
2020-08-01 12:42:19 <Ganwell> Cool!
2020-08-01 12:43:28 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/176578#L213
2020-08-01 12:43:55 <Cogitri> Seems like armv7 has lots of packages with bad signatures too
2020-08-01 12:43:59 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/176575
2020-08-01 12:57:13 <insep_> does apk error out on unknown sections in apkindex?
2020-08-01 13:07:51 <Ganwell> Ariadne: chromium? I am interested :-)
2020-08-01 13:12:35 <MY-R> Ganwell, yep alacritty need extra font .conf file because using single color emojis :) but ye, no problem
2020-08-01 17:14:32 <Ariadne> PureTryOut[m]: i think i figured out akonadi crashing issue.  if i am right, i will push 20.04.3-r1 with stack size adjustment
2020-08-01 17:15:15 <Ariadne> Cogitri: we issued new key for signing time64 binaries on arm
2020-08-01 17:20:17 <nmeum> Ariadne: is it a 4096 bit RSA key? last time I checked we were still using 2048 bit keys
2020-08-01 17:20:27 <nmeum> in fact, 2048 bits is still the default for abuild-keygen
2020-08-01 17:20:41 <Ariadne> i don't know
2020-08-01 17:20:57 <Ariadne> i just know we issued a new key so that time32 and time64 packages can't mix
2020-08-01 17:21:37 <afontain_> Oh, that's smart
2020-08-01 17:21:54 <Ariadne> and the time64 does not have the old key
2020-08-01 17:22:39 <Ariadne> so far akonadi with 1MB stack is not crashing
2020-08-01 17:33:06 <PureTryOut[m]> Ariadne: oh awesome!
2020-08-01 17:33:11 <PureTryOut[m]> Good job!
2020-08-01 17:33:36 <Ariadne> still has not crashed
2020-08-01 17:33:42 <Ariadne> normally it would have crashed by now
2020-08-01 17:33:45 <Ariadne> i think i'm going to send it
2020-08-01 17:33:55 <PureTryOut[m]> Sounds good to me 👍️
2020-08-01 17:34:06 <PureTryOut[m]> Please consider upstreaming it :D
2020-08-01 17:34:14 <Ariadne> it is just LDFLAGS
2020-08-01 17:34:25 <Ariadne> the proper upstream fix is, idk
2020-08-01 17:35:41 <Ariadne> doing a test build to make sure it picks up the stack size hint
2020-08-01 17:37:42 <Ariadne> PureTryOut[m]: yes, my theory is that it is crashing due to recursively walking email threads
2020-08-01 17:37:55 <Ariadne> and being C++ bloatware, it probably blasts through 80KB stack quickly
2020-08-01 17:38:42 <Ariadne> have to say, having the ability to run abuild with -j64 on my desk is nice
2020-08-01 17:39:23 <PureTryOut[m]> Ah, infinite recursive loop? Awesome lol
2020-08-01 17:40:36 <Ariadne> not infinite, but deep enough to blast through 80kb stack
2020-08-01 17:41:07 <PureTryOut[m]> Ah yeah ok
2020-08-01 17:41:28 <mps> huh, gitlab.a.o using WEB interface is unusable for me because of heavy JS, I think
2020-08-01 17:42:08 <ikke> mps: hmm, nothing changed on gitlab recently
2020-08-01 17:42:21 <Ariadne> the JIT on aarch64 seems a little disappointing
2020-08-01 17:44:31 <mps> it is interesting that on one aarch64 it works quite fine but on another one it is practically unusable
2020-08-01 17:44:52 <mps> both machine have 4GB RAM
2020-08-01 17:45:20 <PureTryOut[m]> Ariadne: btw I made a bug a while ago for the keyboard shortcuts not working on Wayland. https://bugs.kde.org/show_bug.cgi?id=417227. Contains some comments from devs
2020-08-01 17:45:31 <Ariadne> it's because d-bus is missing
2020-08-01 17:45:38 <Ariadne> kwin isn't hooked up to d-bus
2020-08-01 17:49:08 <mps> disabling dark reader somewhat helps
2020-08-01 17:50:10 <PureTryOut[m]> Ariadne: that is what the dev debugging on my laptop back then saw as well. For some reason kwin fails to start kglobalaccel via dbus, but other processes later on somehow _do_ manage but then kwin doesn't know about it
2020-08-01 18:03:43 <Ariadne> and now it is dead AGAIN
2020-08-01 18:10:02 <Ariadne> wtf
2020-08-01 18:10:12 <Ariadne> strace -f akonadi_control makes it come up
2020-08-01 18:10:17 <Ariadne> is this a race condition
2020-08-01 18:14:06 <PureTryOut[m]> Ugh
2020-08-01 18:25:51 <Ariadne> answer: yes, two processes are contending on the same dbus bus name
2020-08-01 18:26:24 <Ariadne> if you kill the {QDBusConnection} one
2020-08-01 18:26:27 <Ariadne> it recovers
2020-08-01 18:26:31 <Ariadne> whatever will figure that out later
2020-08-01 18:29:27 <Newbyte> Is it by intention that new activity messages are appended to the box without removing the current one in the activity column on build.alpinelinux.org?
2020-08-01 18:30:27 <ikke> Newbyte: it should show up to 3 items
2020-08-01 18:30:51 <Newbyte> got it
2020-08-01 18:35:15 <Ariadne> ok
2020-08-01 18:35:29 <Ariadne> this is the biggest pile of shit ever
2020-08-01 18:36:43 <z3ntu> PureTryOut: mautrix-telegram seems to be a pain, latest release doesn't work with mautrix-python (py3-mautrix) v0.6.x , maybe partial https://github.com/tulir/mautrix-telegram/commit/0080b028bfc566b52409f91363b876b4ff44b1f6#diff-1651614ddefef26061807128fbcfebba would fix at least the failures on build.alpinelinux.org but I doubt it would be working well
2020-08-01 18:38:04 <PureTryOut[m]> Yeah the MR got merged too quickly. CI wasn't green but it got merged anyway
2020-08-01 18:39:09 <Ariadne> i give up
2020-08-01 18:39:16 <Ariadne> i am just going to use evolution
2020-08-01 18:39:17 <Ariadne> for now
2020-08-01 18:39:23 <PureTryOut[m]> Lol
2020-08-01 18:39:35 <PureTryOut[m]> I've been using Thunderbird since it's been broken 🤷‍♂️
2020-08-01 18:39:52 <PureTryOut[m]> z3ntu: strange thing is that mautrix-telegram passes the tests locally, but not on CI or builders
2020-08-01 18:42:35 <PureTryOut[m]> I guess I'll just update to latest commit for now to fix this issue...
2020-08-01 18:47:04 <PureTryOut[m]> !10940 will fix it for now
2020-08-01 19:46:54 <PureTryOut[m]> how does this ever succeed? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/genrootfs.sh#L35
2020-08-01 19:46:58 <PureTryOut[m]> the apk command above it doesn't actually install busybox
2020-08-01 20:03:55 <maxice8> It does via the $@
2020-08-01 20:04:27 <maxice8> if you look at mkimg.minirootfs.sh it passes $rootfs_apks which includes busybox
2020-08-01 20:04:41 <maxice8> So i guess people that call it pass busybox as an arg :D
2020-08-01 20:05:53 <Cogitri> PureTryOut[m]: sorry for merging too early, I thought CI was only red due to bad signatures (once again)
2020-08-01 20:06:17 <PureTryOut[m]> That would be only the 32-bit architectures, this CI was red on all arches 😉
2020-08-01 20:06:17 <Cogitri> But to be honest, I kind of experct MRs without a WIP: to be locally tested and found to be working
2020-08-01 20:06:22 <PureTryOut[m]> Np, but it's blocking the builders currently
2020-08-01 20:06:26 <PureTryOut[m]> Locally it worked
2020-08-01 20:06:32 <Cogitri> Huh
2020-08-01 20:06:33 <PureTryOut[m]> Just not on CI 🤷‍♂️ No clue what happened
2020-08-01 20:06:42 <Cogitri> Weird
2020-08-01 20:06:43 <PureTryOut[m]> Guess locally I had mixed versions of packages or something
2020-08-01 20:06:58 <Cogitri> Possibly, yeah
2020-08-01 20:07:17 <Cogitri> Gonna look into the fixed MR in a bit, thanks for taking care of it :)
2020-08-01 20:10:29 <PureTryOut[m]> fixed MR is just a upgrade to latest commit. Possibly not as stable but at least it passes through tests and is compatible with the upgrade py3-mautrix
2020-08-01 22:12:43 <PureTryOut[m]> Besides shoving apk's into the `$apks` variable, what else do I need to do to make an application available in a live image generated with the mkimage.sh script?
2020-08-01 23:06:05 <Hello71> depends on what you mean by "available"
2020-08-02 09:13:44 <PureTryOut[m]> Hello71: available as in can run a binary from such a package from the live environment.
2020-08-02 09:14:49 <PureTryOut[m]> I added a package to the `$apks` variable, and although it's available in the apks folder on the resulting image, the package isn't actually installed when booting the system
2020-08-02 09:15:35 <PureTryOut[m]> I can install it manually with `apk add /media/cdrom/apks/<something>` but that's not what I want
2020-08-02 10:09:13 <Hello71> /media/cdrom/apks is already in /etc/apk/repositories, you only need apk add pkg
2020-08-02 10:12:55 <PureTryOut[m]> Yeah but that's not what I mean. I want it to be installed already
2020-08-02 10:13:41 <PureTryOut[m]> In reality I want to run the program on bootup, so installing it manually after booting it won't do
2020-08-02 10:18:16 <ikke> I suspect you'd need an apkovl for that
2020-08-02 10:29:35 <PureTryOut[m]> Any docs for that?
2020-08-02 10:31:48 <ikke> sadly not, I'm just reading what's in the source
2020-08-02 10:31:50 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/genapkovl-dhcp.sh
2020-08-02 11:18:44 <PureTryOut[m]> Ah that seems to do some stuff yes, thanks. Added a package to world with it and it's installed in the live image now
2020-08-02 11:20:07 <ikke> coolk
2020-08-02 11:28:09 <ikke> PureTryOut[m]: The alternative would be to provide pkgs to the kernel cmdline
2020-08-02 11:28:19 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L580
2020-08-02 11:28:43 <ikke> By default it only installs alpine-base
2020-08-02 11:32:36 <ikke> Ofcourse, the normal process of what you try to do is to just do a run-from-ram install, install the package and any configuration, and run lbu commit to persist that
2020-08-02 11:32:41 <ikke> which then generates that apkovl
2020-08-02 12:32:33 <ikke> PureTryOut[m]: libphonenumber looks pretty broken
2020-08-02 12:32:57 <PureTryOut[m]> always is, just let it rebuild till it works
2020-08-02 12:33:15 <ikke> any clue hwy?
2020-08-02 12:33:17 <ikke> why
2020-08-02 12:33:33 <ikke> grep ': error:' more then 1000 matches
2020-08-02 12:33:41 <PureTryOut[m]> some issues with the static library part of it. But I haven't found how to disable that part
2020-08-02 12:34:09 <ikke> failed again
2020-08-02 12:34:30 <ikke> now a linking error
2020-08-02 12:34:41 <ikke> undefined reference to `i18n::phonenumbers::PhoneMetadata::~PhoneMetadata()'
2020-08-02 12:38:04 <PureTryOut[m]> Yup, just retry 🤷‍♂️ It'll get through eventually
2020-08-02 12:38:15 <PureTryOut[m]> It's an annoying one
2020-08-02 12:38:26 <ikke> yup, quite
2020-08-02 12:38:32 <ikke> ok, now it went through
2020-08-02 13:05:15 <mps> 'monte carlo' build method :)
2020-08-02 13:08:54 <ikke> :D
2020-08-02 17:53:47 <maxice8> fascinating
2020-08-02 17:56:22 <maxice8> I need extra hands on merging MRs
2020-08-02 17:56:24 <maxice8> we are over 200
2020-08-02 17:56:55 <Cogitri> Many MRs for fixing license fields from @mpolanski
2020-08-02 17:58:50 <maxice8> :3 I have asked ncopa to give him commit-bit
2020-08-02 17:59:24 <maxice8> fak
2020-08-03 06:34:02 <ncopa> morning
2020-08-03 06:38:34 <mps> \o
2020-08-03 06:42:11 <Cogitri> Morning
2020-08-03 06:52:42 <ollieparanoid[m]> good morning
2020-08-03 06:56:20 <ollieparanoid[m]> FWIW, installing wlroots and sway still gives "BAD signature" errors: https://builds.sr.ht/~postmarketos/job/271615#task-pmbootstrap_build-540
2020-08-03 06:57:22 <ollieparanoid[m]> (ikke looked into it on friday and found that the hash on the builder is different than on the mirrors)
2020-08-03 07:03:24 <ollieparanoid[m]> opened an issue about this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11807
2020-08-03 07:28:38 <Cogitri> I think Ariadne mentioned that there's a new signing key being used for binaries built against the new musl version so users can't mix things and break their systems
2020-08-03 07:29:02 <Cogitri> I'm not sure where users would get the public key for the upgrade though...
2020-08-03 11:30:31 <ikke> Cogitri: shouldn't users get them automatically from alpine-keys? Though the question is then, how is that package trusted
2020-08-03 11:30:54 <Cogitri> Yes, it would have to be signed with the old key
2020-08-03 11:31:15 <TBB> a custom package containing only that key perhaps?
2020-08-03 11:31:23 <Cogitri> I guess we'll make an update for that pkg signed with the old key once the builders are done building
2020-08-03 11:35:55 <ikke> but I've never noticed any issues with untrusted packages after upgrading..
2020-08-03 11:36:09 <ikke> or while upgrading
2020-08-03 12:19:02 <PureTryOut[m]> Hmm seems with genapkovl I can't put stuff in other directories than `/etc`... Any clue on how to do that?
2020-08-03 12:20:38 <mps> TBB: apk info alpine-key
2020-08-03 12:20:54 <mps> huh, apk info alpine-keys
2020-08-03 13:19:58 <kytart> Hi! I'm trying to setup udhcpd on my rpi and it's not creating pidfiles. Eventually I figured out that in aports in busybox-extras it's not enabled, but it's enabled in regular busybox. I wonder if that's a bug or a feature.
2020-08-03 13:24:42 <dalias> you mean pidfile config is inconsistent between the two?
2020-08-03 13:24:50 <kytart> I think so
2020-08-03 13:24:53 <dalias> that's probably a bug
2020-08-03 13:25:17 <kytart> in busyboxconfig there's CONFIG_FEATURE_PIDFILE=y but in busyboxconfig-extras it's missing
2020-08-03 13:25:54 <kytart> I'll test it and possibly create PR
2020-08-03 13:37:51 <dalias> unless =y is the default yes this seems like an inconsistency that's almost surely unintentional/a-bug
2020-08-03 18:40:30 <Cogitri> Any objections to adding musl>=1.2 to apk-tools' deps so we don't break every 32-bit user's apk-tools?
2020-08-03 18:43:06 <ikke> +1 from me
2020-08-03 18:48:47 <dalias> why are programs not automatically getting dep version dependencies for the version they need?
2020-08-03 18:48:59 <dalias> this happens with lots of libs not just libc
2020-08-03 18:49:40 <ikke> This is a special case. If apk-tools is out of date, it will first update apk-tools
2020-08-03 18:49:47 <ikke> before doing anything else
2020-08-03 18:49:59 <ikke> but if musl is not upgraded at the same time, apk-tools is broken
2020-08-03 18:50:18 <dalias> i mean why doesn't it already have the >=1.2 requirement?
2020-08-03 18:50:22 <dalias> i kinda know the answer
2020-08-03 18:51:07 <ikke> Because the dependency on musl is implicit :)
2020-08-03 18:51:08 <dalias> but i don't understand why, if alpine doesn't want to hard-code dep on >= the version present at compile-time which is usually gratitous, it doesn't at least adopt some sort of minimal semver
2020-08-03 18:51:38 <dalias> so if x.y.z is present at compile time, you get a dep on >= x.y
2020-08-03 18:52:40 <ikke> Normally the soname takes care of that, but I feel there is a reason that does not apply to musl
2020-08-03 18:53:06 <ikke> (eg, libc)
2020-08-03 18:53:19 <Cogitri> Would be nice if we were to actually check the ABI instead of only using soname
2020-08-03 18:53:42 <dalias> yes soname can't be used with musl because it's also ld-*.so
2020-08-03 18:54:04 <dalias> and having an soname would cause glibc ldconfig to make symlinks to it matching the soname
2020-08-03 18:54:35 <Cogitri> And I do like dalias' idea, but that'd bloat docker images a lot because you can't add a package/do partial upgrades with out upgrading most of the other packages too
2020-08-03 18:55:10 <ikke> right now you are kind of forced to do so anyway on 32-bits platforms
2020-08-03 18:55:16 <ikke> apk add curl: broken
2020-08-03 18:57:12 <Cogitri> Fair, but usually you wouldn't want to upgrade all packages
2020-08-03 18:57:31 <Cogitri> But let's just fix apk-tools for now
2020-08-03 18:58:06 <ikke> And we need to figure out why certain packages haven't been uploaded to the mirrors
2020-08-03 18:58:41 <ikke> (while the index has been updated)
2020-08-03 18:59:37 <dalias> are most packages lacking the dep on musl entirely?
2020-08-03 18:59:45 <dalias> or do they have it but with no specific version
2020-08-03 19:00:22 <ikke> curl-7.71.1-r0 depends on:
2020-08-03 19:00:22 <dalias> it sounds to me like if the existing model doesn't encode the dep right because of lack of soname, something should be changed to solve that, possibly just a quick hack in the short term to keep ppl from breaking their systems
2020-08-03 19:00:28 <ikke> so:libc.musl-x86.so.1
2020-08-03 19:00:43 <ikke> it depends on the shared object
2020-08-03 19:00:58 <ikke> but any version of musl satisfies that
2020-08-03 19:01:26 <dalias> ah yes
2020-08-03 19:17:58 <mps> ah, I didn't had this problem
2020-08-03 19:19:11 <Cogitri> Then you upgraded musl first or didn't reinstall apk-tools
2020-08-03 19:19:53 <ikke> I noticed this when running an older docker image that didn't have the latest version of apk-tools yet
2020-08-03 19:20:04 <ikke> so it upgraded apk-tools and then was broken
2020-08-03 19:20:26 <mps> true for install on 'metal', but on lxc I did apk upgrade -a
2020-08-03 19:22:59 <ikke> mps: even with apk upgrade -a it can break
2020-08-03 19:23:26 <ikke> if apk notices that apk-tools is out of date, it will first upgrade apk-tools separately, and then try to restart the upgrade with the new version, which is then broken
2020-08-03 19:25:17 <mps> ikke: yes, ofc. I was just lucky, probably
2020-08-03 19:25:58 <ikke> apk-tools hasn't upgraded recently, so you most likely already had the latest version
2020-08-03 19:30:56 <mps> but doesn't 'apk upgrade -a' reinstall all pkgs
2020-08-03 19:31:23 <ikke> yes, but apk-tools is special cased
2020-08-03 19:31:43 <mps> aha, good thing to remember
2020-08-03 19:32:02 <ikke> so it will first upgrade that before anything else
2020-08-03 19:32:25 <Cogitri> !11041
2020-08-03 19:32:38 <Cogitri> Would be good if someone else can take a look before I break everyone's system
2020-08-03 19:33:04 <ikke> Cogitri: commit message is missing details ;-)
2020-08-03 19:34:38 <dalias> if there'd been a good solution to this back when musl was first adopted in alpine, the libc.musl-*.so.1 naming hack would never have been needed
2020-08-03 19:35:03 <Cogitri> ikke: right :D
2020-08-03 19:36:02 <ikke> I check commit messages first before anything else :P
2020-08-03 19:36:22 <[[sroracle]]> <@ikke> if apk notices that apk-tools is out of date, it will first upgrade apk-tools separately, and then try to restart the upgrade with the new version, which is then broken
2020-08-03 19:36:32 <[[sroracle]]> there's a flag to disable the critical upgrade
2020-08-03 19:37:04 <[[sroracle]]> --no-self-upgrade / --self-upgrade-only
2020-08-03 19:37:22 <ikke> right, but you need to be aware of running it :)
2020-08-03 19:37:39 <ikke> If you just run apk upgrade -Ua, as advised, your system could be broken :)
2020-08-03 19:37:52 <mps> and there is apk-tools-static, which i prefer to use in big upgrades
2020-08-03 19:38:12 <mps> and busybox-static, btw
2020-08-03 19:38:18 <ikke> yes, indeed
2020-08-03 19:38:50 <ikke> but you should also remember to install them before
2020-08-03 19:38:59 <ikke> (or manually install it afterwards)
2020-08-03 19:39:09 <mps> I don't forget such things :)
2020-08-03 19:39:23 <ikke> The upgrade from uclibc to musl included those instructions
2020-08-03 19:39:54 <mps> actually, when I switched to alpine I read that on wiki and keep this behavior
2020-08-03 19:39:57 <Cogitri> Updated !11041
2020-08-03 20:40:28 <Ariadne> Cogitri: that will solve it.  i merged it
2020-08-03 20:43:51 <Ariadne> dalias: agreed that soname dependencies should be so:foo.so>=${provider_version}
2020-08-03 20:44:00 <Cogitri> Thanks 👍
2020-08-03 20:44:07 <Ariadne> unfortunately it is a little tricky to do
2020-08-03 22:21:26 <Ariadne> mps: are you working on bumping linux-edge to 5.8?
2020-08-03 23:59:21 <dalias> ariadne, i think just >= ${provider_version} rounded down to major.minor
2020-08-04 06:17:43 <mps> good morning
2020-08-04 06:18:04 <Cogitri> Morning
2020-08-04 06:18:18 <mps> Ariadne: yes, I work but didn't had much time yesterday
2020-08-04 06:19:32 <mps> I already testing 5.8 from -rc4 on two machines (aarch64)
2020-08-04 06:20:11 <mps> but it shows some 'quirks', mostly driver issues
2020-08-04 06:21:09 <mps> I thought to wait for 5.8.1 when some of these issues will probably be fixed, or serious ones at least
2020-08-04 06:21:31 <mps> Cogitri: gutten morgen :)
2020-08-04 06:24:39 <mps> Ariadne: I have 'fear' that upgrade right now could make some users unhappy
2020-08-04 06:26:37 <mps> but all these new features tempting me, especially for aarch64 (BTI - Branch Target Identification and SCS -Shadow Call Stack)
2020-08-04 06:27:27 <mps> KCSAN (Kernel Concurrency Sanitize) also
2020-08-04 06:29:00 <mps> Ariadne: but if you need 5.8 right now we can upgrade, don't mind you or I will do
2020-08-04 06:30:11 <mps> (maybe my 'issues' are just because I experimented to much with .config)
2020-08-04 08:52:16 <zenny> Hi, I am getting `ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? errors pretty printing info` with `docker info` and docker service fail to run. Followed https://wiki.alpinelinux.org/wiki/Docker Is this a bug?
2020-08-04 08:52:52 <ikke> did you start the docker service?
2020-08-04 08:52:57 <ikke> and is it running
2020-08-04 08:53:15 <ikke> We are using docker extensively on alpine, so it should work just out of the box
2020-08-04 08:58:55 <Cogitri> And you either have to be in the docker group or start it with sudo/doas etc.
2020-08-04 08:59:06 <Cogitri> You can't access the docker socket as unprivileged user
2020-08-04 08:59:40 <Cogitri> Also, please don't ask the same question in two channels at the same time
2020-08-04 08:59:50 <ikke> apparently zenny posted this in #alpine-linux as well
2020-08-04 09:00:26 <Cogitri> Yup
2020-08-04 09:05:17 <zenny> ikke and Cogitri: already in the `docker group, the docker service has been enabled at boot. Ran for the first time, but when https://wiki.alpinelinux.org/wiki/Docker#Isolate_containers_with_a_user_namespace, the docker service fails to run, too with the errors posted at http://ix.io/2taU (apology for cross-posting)
2020-08-04 09:06:07 <ikke> what does rc-service docker status return?
2020-08-04 09:06:30 <ikke> enable on boot does not start the service directly
2020-08-04 09:08:23 <zenny> ikke: `# rc-service docker status` > 1* `status: stopped`
2020-08-04 09:09:10 <ikke> there is your answer then
2020-08-04 09:09:16 <ikke> rc-service docker start
2020-08-04 09:10:35 <zenny> ikke: http://ix.io/2taU
2020-08-04 09:11:27 <zenny> that is what the verbose output of  trying to start docker as `root`
2020-08-04 09:13:35 <ikke> can you try to just run dockerd and see if it starts or what it logs?
2020-08-04 09:13:38 <ikke> dockerd -l info
2020-08-04 09:25:31 <zenny> I am on alpine v 3.12 and therefore, I didn't make cg-related addition which was supposedly not working in alpine3.9. However, without that part that does not seem to work. However, there was a typo in daemon.json (missed comma) at the end that is preventing. That made clear while running `dockerd -l info`. Thanks ikke.
2020-08-04 09:26:56 <ikke> yw
2020-08-04 10:15:19 <Hello71> mps: add to testing?
2020-08-04 10:15:27 <Hello71> that's how Arch does it
2020-08-04 10:15:38 <ikke> it is already in testing
2020-08-04 10:15:40 <mps> hmm, new in 5.8 kernel 'CONFIG_BLK_INLINE_ENCRYPTION', block layer handle encryption, so users can take advantage of inline encryption hardware if present
2020-08-04 10:15:43 <ikke> we use testing differently from how arch does it
2020-08-04 10:16:41 <mps> I would not use 'hardware block encryption' for sure, but what you all think, to enable or not
2020-08-04 10:17:18 <mps> Hello71: don't understand what to add to testing
2020-08-04 10:18:32 <Hello71> never mind
2020-08-04 10:18:37 <ikke> mps: in arch, testing repo is more like a stage. New versions and changes are first provided through testing before they go to the main repository
2020-08-04 10:19:21 <mps> ikke: aha, like our edge
2020-08-04 10:19:40 <ikke> more or less. Note that arch is rolling release only
2020-08-04 10:19:46 <ikke> so they do not have stable branches
2020-08-04 10:20:17 <ikke> it's more like we have a copy of every APKBUILD in testing, and first push upgrades to there, and afterwards to main
2020-08-04 10:20:49 <mps> yes, understand. thanks
2020-08-04 10:36:18 <mps> what about enable compression of kernel modules, apk will not be smaller but the space used on disks will be halved at the price of somewhat slower loading
2020-08-04 10:37:32 <mps> ikke: ncopa: Ariadne: ^
2020-08-04 10:38:54 <ikke> I guess it depends on how much slower it takes to load modules
2020-08-04 10:42:39 <mps> this will need some time. Arch alarm compress them on arm32 and arm64
2020-08-04 10:42:56 <ikke> loading modules is a relatevily rare event, so it shouldn't matter a lot. But if it hypothetically adds considerable boot delay, people might object
2020-08-04 10:44:54 <Hello71> I was thinking to do that, but it should be coordinated with modloop
2020-08-04 10:45:23 <Hello71> modloop creation should decompress the modules first, otherwise it will be double compressed so the modloop will grow
2020-08-04 10:45:57 <ikke> or not compressing the modloop in the first place?
2020-08-04 10:46:16 <ikke> not sure what makes more sense
2020-08-04 10:47:31 <Hello71> well it (probably) won't be worse than not compressing at all, but it will be worse than compressing together
2020-08-04 10:48:10 <ikke> ack
2020-08-04 10:48:23 <Hello71> I don't think Linux supports uncompressed squashfs anyways, and the only other plausible read-only format is UFS?
2020-08-04 10:48:29 <Hello71> slash ISO9660
2020-08-04 10:52:27 <mps> another new 'feature' is PSTORE (Persistent Storage) block device where kernel can save panic log/msgs (and some other)
2020-08-04 10:52:45 <mps> sorry, FS not block dev
2020-08-04 10:52:51 <ikke> ncopa: can we sync 32-bitds builder repos again to master? We get quite some bad signatures due to signature mismatches directly from master
2020-08-04 10:53:00 <Hello71> fwiw I've had https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/6 open for a while for (slightly) smaller modloops
2020-08-04 10:53:07 <Hello71> mps: this is a very old feature?
2020-08-04 10:53:22 <Hello71> https://lwn.net/Articles/434821/ says it was added in 2.6.39
2020-08-04 10:53:37 <mps> yes
2020-08-04 10:53:51 <mps> but is not enabled in alpine
2020-08-04 10:53:58 <Hello71> ok
2020-08-04 10:54:36 <Hello71> imo alpine kernel configs are quite confusing
2020-08-04 10:55:13 <mps> well, there is simple solution 'make allconfig' :)
2020-08-04 10:58:21 <Hello71> you mean allyesconfig?
2020-08-04 10:58:22 <mps> interesting new feature is 'Improve the readahead for FAT entries', as we use FAT for anything except /boot
2020-08-04 10:58:28 <Hello71> I wonder how big that is nowadays
2020-08-04 10:58:40 <mps> or reading camera sd cards
2020-08-04 11:01:43 <mps> allyesconfig or allmodconfig
2020-08-04 15:13:08 <markand> hey there
2020-08-04 15:13:28 <markand> is there a problem with the armv7 builder? my pipeline does not even starts because of an apk error: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9123
2020-08-04 15:20:19 <insep_> https://gitlab.alpinelinux.org/markand/aports/-/jobs/179264#L131 this seems to be your error, i've seen it today too
2020-08-04 15:20:49 <markand> 131 ERROR: libpulse-mainloop-glib-13.0-r10: BAD signature
2020-08-04 15:20:52 <markand> this ?
2020-08-04 15:21:43 <insep_> yup
2020-08-04 15:22:01 <insep_> maybe outdated mirror, not sure
2020-08-04 15:22:14 <Cogitri> No, this is due to the musl 1.2 rebuild
2020-08-04 15:22:36 <Cogitri> The new packages are signed with a new key so you don't accidentally mix packages (which could cause missing symbols)
2020-08-04 15:22:53 <ikke> I don't think that's the issue
2020-08-04 15:22:58 <Cogitri> Someone who knows more about that stuff should really do a post to the ML (Ariadne/ncopa?l
2020-08-04 15:22:59 <ikke> I have not seen any new keys
2020-08-04 15:23:17 <ikke> What I've seen is that the signatures of the packages in the mirrors are different from the master
2020-08-04 15:23:25 <ikke> or not master
2020-08-04 15:23:27 <ikke> the builders
2020-08-04 15:23:32 <ikke> so these packeges were not uploaded
2020-08-04 15:23:59 <ikke> clandmeter mentioned the master was out of space, so I recon that caused issues with uploading
2020-08-04 15:25:00 <maxice8> Ikke
2020-08-04 15:25:09 <ikke> That's me ;-)
2020-08-04 15:26:35 <maxice8> yes
2020-08-04 15:26:51 <maxice8> mkmr 0.0.27 disposes of .git/config and now has $XDG_CONFIG_HOME/{config,remotes}
2020-08-04 15:49:54 <mps> Ariadne: I pushed kernel 5.8.0. if you find anything which need fix or change ... you know :)
2020-08-04 16:50:01 <dalias> is there any hope of fixing gitlab to stop logging me out? :-p
2020-08-04 16:50:22 <dalias> it looks like it's also binding sessions to an IP address which is completely wrong post-1989
2020-08-04 16:57:15 <ikke> We would need to find out what is causing the logout
2020-08-04 16:57:22 <ikke> and see if we can prevent that from happening
2020-08-04 17:01:24 <ikke> still open: https://gitlab.com/gitlab-org/gitlab/-/issues/14870
2020-08-04 21:40:12 <mps> free -m => Mem:           3808        1037        1805         307         965        2463
2020-08-04 21:41:11 <mps> with firefox opened 6 tabs, few teminals, ssh
2020-08-04 21:41:19 <mps> musl 1.2.1
2020-08-04 21:42:00 <mps> aarch64 with kernel 5.8
2020-08-04 21:42:58 <mps> very nice dalias :)
2020-08-04 22:23:57 <Terror> Hi team, can we enable svlogd in the default busybox config? It'd be really useful for containerised workloads to have some sort of log mgmt out of the box
2020-08-04 23:34:09 <minimal> Hi folks. Seems there a bit up with the build infrastructure the past day.
2020-08-04 23:35:41 <minimal> MR #11049 armv7 failed due to a BAS signature on py3-pyrsistent-0.16.0-r0 and x86 failed due to BAD signature on py3-json-pointer-2.0-r3
2020-08-04 23:37:21 <minimal> Also MR I just submitted appeared to pass ok but looking at the build-aarch64 logs I see errors during the "Signing the index..." stage such as "gzip: invalid magic"
2020-08-05 03:50:16 <Ariadne> please test ifupdown-ng 0.7.0, it is basically in the state that we intend to ship in 3.13 :)
2020-08-05 07:58:49 <z3ntu> Is anybody taking care of the aria2 build failure for armv7? The tests fail there
2020-08-05 09:03:22 <Thermi> Hi, I got some MRs for aports open for some time now that, as far as I can tell, are ready for merging. I haven't heard back from anyone on the team for some time now too. Could you please take a look at it and, if possible, merge them? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10428 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569
2020-08-05 09:03:30 <Thermi> ncopa: I also got a PR on GH for lddtree.sh: https://github.com/ncopa/lddtree/pull/10
2020-08-05 09:13:59 <Thermi> ncopa: ty
2020-08-05 09:16:57 <mps> https://www.linuxfoundation.org/press-release/2020/08/technology-and-enterprise-leaders-combine-efforts-to-improve-open-source-security/
2020-08-05 09:17:39 <mps> and they want to put cookie in my browser :D
2020-08-05 09:22:50 <ncopa> Thermi: I dont think !10428 will solve anything
2020-08-05 09:23:20 <ncopa> you need access to http repos anyway
2020-08-05 09:24:03 <Thermi> ncopa: I believe that patch is needed to make at least local repos working.
2020-08-05 09:25:38 <ncopa> adding lvm2 and sfdisk would make it possible to create the partition table and set up lvm without network
2020-08-05 09:26:10 <ncopa> but you will not be able to install the system to the craeted lvm partition without network
2020-08-05 09:26:13 <Thermi> ncopa: It's been some months (was pre SARS-CoV2) since I last worked on that issue on site. As far as I can remember, this was used in conjunction with a custom built kernel and initramfs, as well as possibly some local packages. I do not remember specifically about the last part though.
2020-08-05 09:26:17 <ncopa> so it would fail anyway
2020-08-05 09:26:36 <Thermi> ncopa: Well, yeah, obviously packages that are required but not available can't be installed
2020-08-05 09:27:02 <ncopa> right, so you would need to add those package to you custom local repo
2020-08-05 09:27:24 <Thermi> That'd then be some more stuff that needs to be done by users with that situation
2020-08-05 09:27:53 <Thermi> I believe adding sfdisk and lvm2 is the proper way to do it because the scripts use those tools
2020-08-05 09:29:12 <ncopa> the boot image includes only the things needed to boot and get access to the network so it can get the rest from there
2020-08-05 09:29:30 <ncopa> we could possibly rename the alpine-standard to alpine-netinst or similar
2020-08-05 09:30:36 <ncopa> i mean, we could ofc just add those things to the base image and increase the size, but users would still need the network
2020-08-05 09:31:02 <ncopa> so we could just keep the boot media small
2020-08-05 09:31:34 <ncopa> and we dont really know if lvm2 is needed at all. it depends on how the user wants to install it
2020-08-05 09:31:44 <Thermi> I believe the patch will avoid some errors and manual intervention, even if it's running some additional commands. That's as far as I can contribute to this before I get back on site to work on the project needing this patch.
2020-08-05 09:32:53 <Thermi> I believe if the addition of those packets helps even one user, that is fine. Some KB/1-2 MB aren't that big of a deal. Storage is really cheap in comparison to such file sizes.
2020-08-05 09:33:57 <Thermi> If the addition _adds_ considerable problems to users because of the growth in size, then those users already have the much bigger issues that their method of delivery for the boot image is quite lacking.
2020-08-05 09:33:57 <ncopa> right. but doing that for 1000 different users would result in 1-2G
2020-08-05 09:34:09 <midasi> I don't think your installation manual in the wiki works without those packages, https://wiki.alpinelinux.org/wiki/Installation
2020-08-05 09:34:18 <midasi> it will fail on the disk setup
2020-08-05 09:34:53 <Thermi> Data transfers of 1-2G additional to existing (already humongous) data transfer sizes is miniscule because the rest of Alpine is already so big
2020-08-05 09:35:10 <mps> I usually need util-linux, e2fsprogs and f2fs-tools during install but never asked to be included
2020-08-05 09:35:47 <Thermi> Also, having to download the packages every time adds some more time that the user is required to invest into installation.
2020-08-05 09:36:01 <Thermi> *every time one installs Alpine
2020-08-05 09:36:05 <ncopa> midasi: the installation manual in the wiki will work because setup-alpine will set up network and get lvm2 and sfdisk from network when needed
2020-08-05 09:37:07 <midasi> well, we mostly install without network
2020-08-05 09:37:17 <ncopa> we already include e2fsprogs. i wonder why they were added
2020-08-05 09:37:30 <mps> ah, didn't noticed
2020-08-05 09:37:43 <ncopa> the alpine-extended image is the one that is to be used for installs without network
2020-08-05 09:38:04 <ncopa> i think what we may want to do is rename alpine-standard to alpine-netinst
2020-08-05 09:38:10 <mps> right
2020-08-05 09:38:21 <ncopa> to make it clear that it requires network
2020-08-05 09:38:35 <ncopa> and we could possibly introduce an alpine-extended for arm
2020-08-05 09:38:38 <midasi> extended is not only available for aarch64
2020-08-05 09:39:07 <ncopa> yeah, it may make sense to add an -extended for aarch64
2020-08-05 09:39:47 <midasi> moreover, the extended has a lot of packages which are not needed for a basic installation
2020-08-05 09:40:06 <ncopa> that way, those who wants a truly minimal boot image get that, and those who does not care bout 700MB for convenience can use that
2020-08-05 09:40:55 <midasi> ...such as strongswan, openvpn etc...
2020-08-05 09:40:57 <ncopa> midasi: yes, because it can also be used for diskless installs
2020-08-05 09:41:31 <midasi> in our case, we just need a basic installation we can use without network...and for that we only miss these two packages in the base image....
2020-08-05 09:42:17 <ncopa> what is the size difference if we add them?
2020-08-05 09:44:08 <ncopa> what i wonder is why e2fsprogs is included. i dont think it makes sense
2020-08-05 09:44:35 <mps> also I
2020-08-05 09:45:36 <ncopa> ok. it was there since the beginning
2020-08-05 09:45:40 <mps> install without network doesn't work anyway, so I don't see reason to add pkgs which can be downloaded
2020-08-05 09:45:42 <midasi> perhaps it's required if you use the iso as a bootimage to change the partitions of the main installation
2020-08-05 09:46:20 <midasi> mps: and what is not working in your opinion?
2020-08-05 09:47:17 <midasi> we do this all the time
2020-08-05 09:47:25 <ncopa> installing the system to disk. kernel is missing
2020-08-05 09:47:29 <ncopa> how do you install the kernel?
2020-08-05 09:47:37 <ncopa> i suppose you have a custom kernel
2020-08-05 09:47:43 <midasi> yes
2020-08-05 09:48:29 <mps> hmm, I have this in my install script for aarch64 and armv7 'apk add util-linux e2fsprogs udev'
2020-08-05 09:48:32 <ncopa> so you have a custom boot media, using a custom install script
2020-08-05 09:48:34 <midasi> we have an own mkimage script for our aarch64 kernel and some additional package we need. And it's based on the base image
2020-08-05 09:49:07 <ncopa> can you add lvm2 and sfdisk together with the additional package?
2020-08-05 09:49:08 <midasi> in fact we have several of those... for marvell and nxp chips
2020-08-05 09:49:52 <ncopa> the thing is that even if we add those to the base image, it does not cover all cases we support
2020-08-05 09:50:03 <ncopa> like mdadm and potentially cryptsetup
2020-08-05 09:50:31 <midasi> we actually did... but it doesn't solve the problem with the main arm image
2020-08-05 09:50:31 <ncopa> and what aboout bootloader, syslinux and/or grub?
2020-08-05 09:51:22 <ncopa> i think it may make sense to add an extended image for aarch64
2020-08-05 09:51:52 <midasi> we use u-boot as bootloader
2020-08-05 09:52:00 <ncopa> which includes the kernel package, lvm2 and packages for all supported disk installs
2020-08-05 09:54:07 <mps> u-boot? then all u-boot variants should be added to install media
2020-08-05 09:56:03 <midasi> what about basis installations for x86_64... they will miss those 2 packages as well if they install without network¨
2020-08-05 09:56:45 <ncopa> yes, install without network will fail, but it will fail even without those packages
2020-08-05 09:57:09 <ikke> even with those packages you mean??
2020-08-05 09:57:18 <ncopa> yes :)
2020-08-05 09:57:21 <midasi> why? I think we use this scenario often
2020-08-05 09:57:38 <ncopa> it will fail even with those packages if you select mdadm in the setup secript
2020-08-05 09:57:48 <ncopa> it will fail unless you add your custom kernel
2020-08-05 09:59:51 <ncopa> how about this, we add those packages to the profile_uboot?
2020-08-05 10:00:23 <ncopa> which are more likely to be using custom kernel
2020-08-05 10:00:40 <mps> (perfection is not when you don't have anything more to add but when you don't have anything to remove)
2020-08-05 10:01:40 <midasi> we use the standard lts kernel in x86_64 and I don't think it fails apart of the setup-disk... but let me verify that again
2020-08-05 10:03:22 <ncopa> well, actually, there may be a case for  data disk only
2020-08-05 10:04:01 <ncopa> if you have no network, and select data disk during setup-disk
2020-08-05 10:04:17 <ncopa> but i think in those cases it would still make more sense to use the -extended image
2020-08-05 10:05:01 <ncopa> i think this may be a compromise: https://tpaste.us/LYJa
2020-08-05 10:05:32 <mps> no
2020-08-05 10:05:40 <ncopa> adding lvm2 sfdisk for your specific usecase for armv7/aarch64, which requires custom kernel
2020-08-05 10:06:02 <ncopa> it only adds "bloat" to arm users but not for *everyone*
2020-08-05 10:06:21 <Cogitri> That seems a bit inconsistent though
2020-08-05 10:06:33 <mps> no, it makes sense only if you build -extended for arm
2020-08-05 10:06:45 <Cogitri> I mean I'd personally find it confusing finding different tools on ISOs for different arches
2020-08-05 10:06:58 <ncopa> good point
2020-08-05 10:06:58 <Cogitri> (Unless those tools are strictly specific to that arch of course)
2020-08-05 10:07:18 <mps> you don't need u-boot for x86*
2020-08-05 10:07:40 <ncopa> but what is requested here is an exception for a specific use case
2020-08-05 10:08:10 <Cogitri> I think for specific use cases one should build their own ISO, no?
2020-08-05 10:08:19 <Cogitri> I mean we can't really satisfy every specific usecase
2020-08-05 10:08:21 <mps> imo, we shouldn't make exceptions without good reason
2020-08-05 10:09:07 <ncopa> thats my point. they already do build their own custom thing. but addign those 2 packages at a price for 2M for *every other user* makes their usecase easier
2020-08-05 10:09:31 <ncopa> i think adding an -extended image for arm makes more sense
2020-08-05 10:09:34 <midasi> we only use custom kernels for arm, but not for x64
2020-08-05 10:10:11 <mps> making -extended arm is probably ok
2020-08-05 10:10:33 <Cogitri> 👍
2020-08-05 10:10:33 <ncopa> midasi: thats why im suggesting adding the exception packages for arm only, not for "base"
2020-08-05 10:11:23 <ncopa> i thing adding an -extended release image for arm is what makes most sense
2020-08-05 10:11:28 <midasi> ncopa: but we need it for x64 as well... but as mentioned before, let me quickly verify this case
2020-08-05 10:11:44 <mps> ncopa: no, I think that's not needed, better is to  make -extended
2020-08-05 10:13:01 <ncopa> i think we can even remove e2fsprogs from base
2020-08-05 10:13:11 <mps> yes
2020-08-05 10:13:36 <mps> anyway I always add it :)
2020-08-05 10:13:43 <ncopa> and possibly haveged
2020-08-05 10:14:08 <mps> if it is not started on install boot then yes
2020-08-05 10:14:45 <ncopa> maybe even openssh
2020-08-05 10:15:10 <mps> yes
2020-08-05 10:15:47 <mps> setup offers choice beetwen dropbear and openssh anyway
2020-08-05 10:16:33 <ncopa> the only reason to keep openssh is that it may make sense to have it there for headless installs
2020-08-05 10:16:48 <ncopa> eg. boot, start network, start sshd
2020-08-05 10:17:04 <ncopa> so user can log in via ssh and do the rest of setup from there
2020-08-05 10:17:27 <mps> then it should be configured to allow root access with predefined password
2020-08-05 10:17:31 <detha> yes. On this topic, one thing that is annoying with the netinst is that it assumes 'network access' includes internet access
2020-08-05 10:18:23 <ncopa> it assumes access to some sort of network repository access
2020-08-05 10:18:41 <ncopa> mps: i was thinking of adding an ssh key to the boot media or similar
2020-08-05 10:18:51 <ncopa> or adding ssh key as boot option
2020-08-05 10:19:15 <detha> yup. but there are various things (iirc ntp and getting mirror list) that sit there for a long time staring at you
2020-08-05 10:19:42 <ncopa> aha
2020-08-05 10:20:08 <mps> ncopa: if this is posible it is better than passwd
2020-08-05 10:20:38 <detha> it gets through eventually though, and one can get to local mirror
2020-08-05 10:20:39 <ncopa> detha: i think we should create an issues for those two
2020-08-05 10:20:47 <mps> but I have no idea how it would work, ssh keys I mean
2020-08-05 10:20:57 <ncopa> ntp should be possible to pick up from dhcp server
2020-08-05 10:21:20 <detha> it is (and it doesn't, my dhcp server gives it an ntp server)
2020-08-05 10:21:38 <ncopa> that is a fixable problem
2020-08-05 10:21:51 <MY-R> ye dhcp client need to be extra configured to work with it
2020-08-05 10:22:13 <ncopa> it makes perfect sense to fix that
2020-08-05 10:22:36 <ncopa> when it comes to mirrors list
2020-08-05 10:22:44 <ncopa> i wonder if we could use an env var
2020-08-05 10:22:45 <MY-R> 
ACTION don't car emuch, /me always using chrony

2020-08-05 10:23:18 <ncopa> so you could do: export APK_MIRROR=....; setup-alpine
2020-08-05 10:23:38 <ncopa> and it woudn't even try get the mirrors list
2020-08-05 10:23:51 <detha> that would be an excellent solution yes
2020-08-05 10:25:51 <detha> (admittedly this environment is rather 'special', in that VMs never have direct internet access, only some filtered http(s) access through a proxy, not something that seems common)
2020-08-05 10:27:29 <ncopa> i have worked in that kind of env in the past
2020-08-05 11:19:57 <midasi> ncopa: you're right. for x86_64 we use in fact a custom profile as well adding the standard kernel and a few tools^.
2020-08-05 11:20:31 <ncopa> 👍
2020-08-05 11:22:02 <midasi> otherwise it wouldn't work without network
2020-08-05 11:23:13 <midasi> Therefore, your proposed solution with an extended arm profile would be sufficient for our use cases
2020-08-05 12:29:59 <clandmeter> did we get rid of bb patch?
2020-08-05 12:31:03 <ikke> "CONFIG_PATCH is not set"
2020-08-05 12:31:39 <ikke> 38ef6cebfd8498e03f0636b00c62bdf42fbf5eb2
2020-08-05 12:37:09 <clandmeter> bummer
2020-08-05 12:37:18 <clandmeter> lots of docker setups will be broken now
2020-08-05 12:39:56 <Cogitri> I think bb patch was dropped because it's not that useful because it doesn't support fuzzing
2020-08-05 12:40:09 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11001
2020-08-05 12:40:58 <clandmeter> yes i can read why its less useful, im just expressing it will break setups that were depending on it.
2020-08-05 12:43:22 <Hello71> who is using patch without build-base?
2020-08-05 12:43:34 <ikke> clandmeter apparently :)
2020-08-05 12:43:45 <ikke> it's not only for building packages ofcourse
2020-08-05 12:43:47 <Hello71> also does debian even come with patch? I thought you needed build-essential
2020-08-05 12:44:18 <clandmeter> im using patch in Dockerfiles
2020-08-05 12:44:29 <Hello71> yeah, build-essential -> dpkg-dev -> patch
2020-08-05 12:45:06 <clandmeter> i dont need std patch if bb is good enough, but i guess thats changed now :)
2020-08-05 12:57:00 <mps> I was against dropping if from bb
2020-08-05 12:58:01 <mps> knowing someone will need it sooner or later
2020-08-05 13:51:47 <clandmeter> I wonder what the considerations are for removing applets from bb. what if somebody wants to remove vi from bb in favor for vim?
2020-08-05 14:18:59 <mps> iirc, reasoning was that someone don't like it to be in bb because s/he was confused don't knowing it is not from patch pkg
2020-08-05 14:23:59 <mps> clandmeter: #11001
2020-08-05 14:24:36 <clandmeter> mps: yes but that could also apply to vi right?
2020-08-05 14:25:44 <mps> sure, I know that
2020-08-05 14:26:15 <mps> because that I wrote there I'm against removal (and ikke also was against)
2020-08-05 14:26:38 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11001#note_56292 :P
2020-08-05 14:26:43 <ikke> mps: ^
2020-08-05 14:26:55 <mps> ikke: ok, I read it
2020-08-05 14:26:57 <ikke> I was not for, nor against it :P
2020-08-05 14:27:09 <mps> yes, right
2020-08-05 14:27:20 <mps> but I was against :P
2020-08-05 14:27:44 <clandmeter> they did not consider all use cases.
2020-08-05 14:28:19 <mps> imo, we are much to relaxed in accepting users requests
2020-08-05 14:28:48 <mps> clandmeter: promote me to BDFL position and be assured I will be more conservative :)
2020-08-05 14:29:20 <mps> and bb vi will be secured :)
2020-08-05 14:30:16 <mps> hmm, not so BDFL would be better :D
2020-08-05 14:31:00 <clandmeter> 
ACTION sets mode for mps to +bdfl

2020-08-05 14:31:07 <ikke> :D
2020-08-05 14:31:31 <clandmeter> now give me my applet back! :p
2020-08-05 14:32:11 <mps> I will do my best, I promise
2020-08-05 14:32:34 <mps> first will be issue report request
2020-08-05 14:33:15 <clandmeter> im calling it a day after fighting a netbox upgrade
2020-08-05 14:33:36 <clandmeter> something changed in 3.12 python setup
2020-08-05 14:33:50 <clandmeter> no energy to figure it out
2020-08-05 14:36:39 <Cogitri> 3.12 dropped the python symlink
2020-08-05 14:59:50 <Hello71> i'm skeptical that no link is better than py3 link
2020-08-05 15:00:41 <ikke> Hello71: it kind of forces you to choose one, so that later it's easier to find out what still depends on python2
2020-08-05 15:02:24 <Cogitri> And it saves us from having the same mess again when py4 comes around
2020-08-05 15:02:51 <Cogitri> I think that 3.12 might have been a bit early for the switch, but I definitely thing the switch was the right move
2020-08-05 15:50:57 <Danct12[m]> can anyone take a look at: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11066
2020-08-05 16:02:54 <Cogitri> Done
2020-08-05 16:52:01 <minimal> Who's the best person(s) to talk to about build-pipeline issues? Still seeing "BAD signature" error in one of my MRs
2020-08-05 16:54:39 <Ariadne> #alpine-infra but those issues are due to musl 1.2 transition so you will just need to be patient
2020-08-05 16:57:51 <minimal> Yeah I assumed as much but some of the strangeness has been going on for some time
2020-08-05 17:01:22 <Ariadne> clandmeter: i'm fundamentally opposed to reintroducing busybox patch because it is broken crap.  just install gnu patch
2020-08-05 17:02:35 <Ariadne> clandmeter: this was discussed in the change log, even.  i am okay with adding a conformant patch program to alpine-base, but *NOT* readding broken garbage
2020-08-05 17:03:54 <clandmeter> Your strong opinion breaks my setups.
2020-08-05 17:05:06 <Ariadne> clandmeter: my strong opinion is "add patch to alpine-base" which unbreaks your setup.
2020-08-05 17:05:40 <clandmeter> It does not solve it now, it's already broken.
2020-08-05 17:05:55 <Ariadne> clandmeter: readding busybox patch does not make it any less broken either
2020-08-05 17:06:20 <clandmeter> Damage is already done
2020-08-05 17:06:39 <Ariadne> but readding busybox patch *does* reintroduce a patch program that does not work correctly
2020-08-05 17:06:48 <clandmeter> I'm not asking to readd it
2020-08-05 17:07:00 <Ariadne> anyway, sorry your setup got broken
2020-08-05 17:08:16 <Ariadne> mps: busybox vi is conformant with POSIX, busybox patch is not
2020-08-05 17:08:36 <clandmeter> Many things are non posix
2020-08-05 17:08:46 <clandmeter> It's not a golden rule
2020-08-05 17:09:00 <Ariadne> sure, but busybox patch is still completely broken
2020-08-05 17:09:05 <Ariadne> patch is REQUIRED to support fuzzing
2020-08-05 17:09:09 <Ariadne> every other patch does so
2020-08-05 17:09:36 <clandmeter> Sure and I agree
2020-08-05 17:10:29 <clandmeter> But ppl should be careful when removing functions from base install.
2020-08-05 17:10:32 <Ariadne> like i said, sorry for breaking your setup.  i wanted to introduce GNU patch as a replacement in alpine-base, but there was no consensus
2020-08-05 17:10:57 <mps> I dissagree. We should not break 'current' things so easily
2020-08-05 17:11:09 <mps> even if it is broken
2020-08-05 17:11:25 <Ariadne> mps: we did not break current things 'so easily'.  it took a year to gain consensus to remove busybox patch.
2020-08-05 17:12:17 <Ariadne> what is unfortunate is that we did not gather sufficient data about patch usage outside of package building
2020-08-05 17:12:23 <mps> I was against, so we didn't reached consensus but majority
2020-08-05 17:12:40 <clandmeter> Yes that's exactly my point
2020-08-05 17:13:31 <Ariadne> great, and when busybox has an option to opt in to garbage
2020-08-05 17:13:37 <Ariadne> we can enable all the garbage you want
2020-08-05 17:14:09 <mps> no
2020-08-05 17:14:23 <Ariadne> i find it ironic that people developing a "security-oriented" solution trust in the quality of busybox applets
2020-08-05 17:14:38 <Ariadne> have you all run coverity on busybox?  it is a disaster
2020-08-05 17:14:55 <mps> personally I don't use bb patch, but I was against removal because expected someone will be 'surprised'
2020-08-05 17:15:17 <Ariadne> well, how do you expect us to make progress if nobody ever gets surprised
2020-08-05 17:15:54 <mps> is the progress our only goal?
2020-08-05 17:16:22 <Ariadne> the goal is to produce a secure and high-quality distribution.  busybox, unfortunately, in many areas is not compatible with this goal
2020-08-05 17:17:13 <mps> and I'm not against progress but we should be keep in mind backward 'compatibility' to some degree and where we can
2020-08-05 17:17:25 <Ariadne> sure
2020-08-05 17:17:44 <Ariadne> my point here is, what suggestions do you have to improve expectation management
2020-08-05 17:18:00 <mps> removing one/two applets will not make bb more secure
2020-08-05 17:18:14 <Ariadne> yes, but trimming the fat reduces scope of busybox
2020-08-05 17:19:13 <mps> well, that is hard to answer for distro without too formal policy and steering body
2020-08-05 17:20:03 <mps> imo, we only could now try to achieve some kind of consensus for critical parts
2020-08-05 17:20:28 <Ariadne> yeah and that allows one person to block progress even though everyone else agrees
2020-08-05 17:21:06 <mps> I'm aware of this problem, but I don't have any better idea
2020-08-05 17:21:51 <Ariadne> the solution for stuff like this is probably something along the lines of gentoo's "news" system
2020-08-05 17:22:10 <Ariadne> wherein you upgrade, and you can find out things like "patch is gone, install GNU patch"
2020-08-05 17:22:35 <Ariadne> keeping broken things around for the next decade is not the solution
2020-08-05 17:22:53 <Ariadne> clandmeter just wants a patch program, *any* patch program
2020-08-05 17:23:07 <mps> though I don't know what is Gentoo "news", something should be done, be it voting, BDFL 'last word' or something else
2020-08-05 17:23:16 <Thermi> ncopa: mps so what are you going to do?
2020-08-05 17:23:23 <Hello71> doesn't alpine have release notes for that
2020-08-05 17:23:30 <c705> what's wrong with busybox patch?
2020-08-05 17:23:45 <ikke> And we do all kinds of upgrades which might introduce breaking changes for users.
2020-08-05 17:23:45 <Ariadne> c705: it does not support fuzzing
2020-08-05 17:24:01 <Hello71> nobody said busybox patch must be removed *immediately*. in this case you could probably even patch it to print a warning on use
2020-08-05 17:24:14 <Ariadne> this already happened
2020-08-05 17:24:30 <Ariadne> deal with it
2020-08-05 17:24:54 <Ariadne> if anyone adds it back, i will escalate that for the core team to review
2020-08-05 17:24:59 <Hello71> 
ACTION rolls eyes

2020-08-05 17:25:02 <c705> do we need fuzzing ona fundamental level? why not keep busybox patch, and if people want fuzzing, install GNU patch
2020-08-05 17:25:40 <Ariadne> c705: because busybox patch just crashes and does not tell you anything about anything
2020-08-05 17:25:43 <mps> Ariadne: in issue report I asked you and other which I think are interested in problem about opionion
2020-08-05 17:25:56 <c705> hmm
2020-08-05 17:26:19 <mps> 
ACTION is not of those who push changes easily if some have objections

2020-08-05 17:26:23 <Ariadne> mps: i've made my opinion clear, i do not want it to come back ever
2020-08-05 17:26:38 <Ariadne> the only compromise in that regard i am willing to accept
2020-08-05 17:26:45 <Ariadne> is a busybox-broken-garbage package
2020-08-05 17:26:57 <Ariadne> that way you know what you're getting is broken garbage
2020-08-05 17:27:19 <ikke> But at that point you can just as well install patch
2020-08-05 17:27:23 <Ariadne> yeah
2020-08-05 17:27:25 <Ariadne> exactly
2020-08-05 17:27:25 <mps> Ariadne: nice to express your opinion clearly and with valid arguments
2020-08-05 17:28:07 <Ariadne> mps: my opinion is if you want patch: `apk add patch`
2020-08-05 17:28:21 <mps> ok
2020-08-05 17:28:38 <c705> exactly what i was thinking
2020-08-05 17:28:51 <mps> lets hear other interested in this
2020-08-05 17:28:54 <Ariadne> c705: yeah, and shipping a broken patch in busybox means people think they already have patch
2020-08-05 17:29:23 <ikke> I see Alpine as a more progressive distro honestly. We don't avoid breaking changes in newer versions. There are a lot more conservative distros out there
2020-08-05 17:30:00 <Ariadne> that patch is not really a patch implementation, in much the same way as the usb-c charging cable you got from amazon is not a valid usb-c charging cable
2020-08-05 17:30:19 <Ariadne> it will work for some things, but there are many cases where it will not work
2020-08-05 17:30:21 <mps> ikke: I agree, but we need something to alleviate such things what happened to clandmeter
2020-08-05 17:30:50 <ikke> If we want to get rid of bb patch, this will happen sooner or later
2020-08-05 17:30:52 <Ariadne> mps: i proposed adding GNU patch to alpine-base and all i heard was crickets
2020-08-05 17:31:11 <Ariadne> i did not hear yes, i did not hear no
2020-08-05 17:31:35 <Ariadne> mps: so do we add GNU patch or not
2020-08-05 17:31:59 <mps> Ariadne: this particular applet is not important (I agree) but I'm talking about our process when we make such changes
2020-08-05 17:32:01 <ikke> mps: and this is a very visible change. We do a lot more changes that are more subtle but may be just as breaking
2020-08-05 17:32:25 <Ariadne> the only thing this tells me is that people don't read the release notes
2020-08-05 17:32:36 <Ariadne> because busybox patch removal was prominently discussed there
2020-08-05 17:32:41 <mps> we need solution for when we do such things
2020-08-05 17:32:45 <ikke> The python 2 depreciation is breaking a lot of things as well
2020-08-05 17:32:46 <Ariadne> if you want to solve a problem, solve *that*
2020-08-05 17:33:06 <Ariadne> don't open a bug asking for a bad applet to be re-added
2020-08-05 17:33:07 <c705> mps: why not take the same approach that arch uses? i think a release mailing list would be appropriate
2020-08-05 17:33:20 <Ariadne> my goal is to ensure that in busybox, we only ship "busybox: the good parts"
2020-08-05 17:33:29 <Ariadne> because there is a lot in busybox that simply is not good
2020-08-05 17:33:42 <Ariadne> busybox has it's own TLS implementation now, shall we ship that?
2020-08-05 17:33:48 <mps> heh, I didn't had problem with it, but at least one our user did, and by coincidence this user our infra team member
2020-08-05 17:34:02 <Ariadne> and most likely
2020-08-05 17:34:07 <Ariadne> he forgot about patch removal
2020-08-05 17:34:41 <mps> ohm, we don't need to repeat this 'ad infinitum'
2020-08-05 17:34:43 <Ariadne> it is surely frustrating to forget about things, but we did everything by the book to announce the removal of the feature
2020-08-05 17:35:43 <Ariadne> and i do not appreciate having to take time out of my day to deal with this
2020-08-05 17:40:02 <Ariadne> not to mention
2020-08-05 17:40:15 <Ariadne> the original author of busybox patch (landley) says to use his toybox version instead
2020-08-05 17:41:38 <Ariadne> but like, if we cannot even move forward on killing off an incomplete patch program that crashes on anything other than perfect patches
2020-08-05 17:41:49 <Ariadne> i am not confident that we can move forward on python2 deprecation either
2020-08-05 17:41:57 <Ariadne> somebody will be like
2020-08-05 17:42:03 <Ariadne> WTF WHERE IS PYTHON2
2020-08-05 17:42:22 <Ariadne> and we will be stuck maintaining python2 ourselves into 2030
2020-08-05 17:42:34 <Ariadne> it sucks, but sometimes things have to be done
2020-08-05 17:47:05 <Ariadne> so i am sorry it is an inconvenience, but it is minor compared to other inconveniences that have happened before and will happen in future
2020-08-05 17:49:10 <Ariadne> context matters.  we removed a broken version of *patch* that many users have complained about over the years anyway.  it's not like we replaced openrc with systemd or something.
2020-08-05 17:57:44 <Ariadne> mps: to solve lack of patch in base system, i will be adding patch to alpine-base in 48 hours if there is no objection.  i object vehemently to the reintroduction of busybox patch.
2020-08-05 18:01:13 <Ariadne> if we are shipping a patch program in base, it will be a patch program that people do not come into IRC and complain about being broken
2020-08-05 18:01:32 <mps> Ariadne: sorry if I'm wrong, but I have impression that you took issue too personally
2020-08-05 18:01:54 <mps> or emotionally
2020-08-05 18:02:40 <mps> to repeat, change you introduced by removing bb patch was ok for me personally
2020-08-05 18:03:12 <Ariadne> mps: what i take personally is opening a bug proposing re-adding busybox patch, when that is one of several solutions
2020-08-05 18:04:17 <mps> I just wanted to discuss how to solve such changes in future (sorry for misleading subject)
2020-08-05 18:04:41 <Ariadne> well i agree that it is a problem if people are not reading the release notes
2020-08-05 18:05:17 <Ariadne> but i do not think that is a good justification for not doing necessary things
2020-08-05 18:05:42 <Ariadne> busybox patch has been especially a sore point for me for almost a decade, because we have had numerous people come and complain that it is broken
2020-08-05 18:05:50 <Ariadne> and then get upset when they are told `apk add patch`
2020-08-05 18:05:57 <mps> if I wanted revert I would create MR and ask in it
2020-08-05 18:06:08 <Ariadne> because they expect the patch in base system to be a fully functional patch
2020-08-05 18:06:31 <Ariadne> and so they get mad that we are making them install a different patch to get a "real" patch
2020-08-05 18:06:54 <Ariadne> this is why when rofl0r opened the bug i was like hell yes, let us do this
2020-08-05 18:06:56 <mps> well, that can be also with grep
2020-08-05 18:07:08 <Ariadne> yes, but busybox grep is mostly passable
2020-08-05 18:07:23 <Ariadne> busybox patch breaks on any input that is not a perfect unified diff
2020-08-05 18:07:34 <mps> it got -R in latest release, iirc
2020-08-05 18:07:41 <mps> grep, I mean
2020-08-05 18:08:57 <mps> Ariadne: to finish this (for me here), I don't insist on revert, just to hear opinions of other
2020-08-05 18:09:25 <Ariadne> then i think we should reframe this discussion as "do we need a patch program in base"
2020-08-05 18:09:29 <Ariadne> would that be fine to you?
2020-08-05 18:09:39 <Ariadne> because if we ship a patch program in base, i want it to be a fully functional one
2020-08-05 18:09:55 <Ariadne> busybox patch, as previously mentioned, is more like barely functional
2020-08-05 18:10:32 <Ariadne> when a program is non-functional to the point that people have complained about it, we should really re-evaluate whether or not it is good to have it :P
2020-08-05 18:12:12 <mps> I'm not sure that we need patch in base install
2020-08-05 18:12:37 <Ariadne> an alternative may be to add command-not-found to alpine base
2020-08-05 18:12:41 <Ariadne> then when you run patch
2020-08-05 18:12:50 <Ariadne> you get "run apk add patch to get patch"
2020-08-05 18:12:51 <Ariadne> :p
2020-08-05 18:13:01 <ikke> I find those tools annoying personally
2020-08-05 18:13:02 <mps> and yes, I personally prefer 'normal' patch if I install it
2020-08-05 18:13:25 <Ariadne> i also found the comparison to busybox vi to be confusing
2020-08-05 18:13:33 <Ariadne> because busybox vi is actually an excellent implementation of vi
2020-08-05 18:13:54 <Ariadne> nobody wants to kill busybox vi :)
2020-08-05 18:14:00 <ikke> Just as annoying :-P
2020-08-05 18:14:09 <Ariadne> how so?
2020-08-05 18:14:11 <mps> yes, first thing I do after install is 'apk add vim', sometimes even on install phase
2020-08-05 18:14:16 <Ariadne> well
2020-08-05 18:14:24 <Ariadne> yes, busybox vi may be annoying to a vim user :)
2020-08-05 18:14:37 <ikke> Using vi when you are used to vim can be frustrating :-)
2020-08-05 18:14:43 <mps> for me it is at least
2020-08-05 18:15:14 <ikke> But I'm happy at least vi is available in alpine-base
2020-08-05 18:15:28 <Ariadne> i use nano
2020-08-05 18:15:33 <Ariadne> we should add nano
2020-08-05 18:15:36 <Ariadne> to alpine-base
2020-08-05 18:15:37 <Ariadne> :D
2020-08-05 18:15:40 <mps> ikke: yes, it is good to have it at start
2020-08-05 18:16:01 <mps> nice, you didn't proposed emacs :)
2020-08-05 18:16:07 <ikke> Ha
2020-08-05 18:16:53 <Ariadne> but yes, especially when busybox patch was used with abuild
2020-08-05 18:16:58 <Ariadne> we used to get complaints all the time about it
2020-08-05 18:17:08 <Ariadne> that is why abuild depends on real patch now
2020-08-05 18:17:42 <Ariadne> admittedly that is one reason we did not consider that anyone may actually be using busybox patch
2020-08-05 18:18:42 <Ariadne> because literally all the feedback we have ever gotten about busybox patch
2020-08-05 18:18:46 <Ariadne> has been negative
2020-08-05 18:21:29 <Ariadne> in fact if you read #11001 it starts off as a user complaint about busybox patch being of limited functionality
2020-08-05 18:21:35 <Ariadne> :)
2020-08-05 18:23:35 <ikke> That user started at irc
2020-08-05 18:24:32 <ikke> Mostly talking about colleagues that were confused iirc
2020-08-05 18:24:37 <Ariadne> yes i believe they were encouraged to open a bug so we could finally start the process of killing off busybox patch ;)
2020-08-05 18:25:15 <Ariadne> like, i want to just reiterate
2020-08-05 18:25:39 <Ariadne> in the entire time i've been here, which is basically for almost the entire time alpine has been a thing
2020-08-05 18:25:45 <Ariadne> i have never ever seen anyone be like
2020-08-05 18:25:49 <Ariadne> wow busybox patch is great
2020-08-05 18:25:58 <Ariadne> literally everyone has been like "how do i get rid of this thing"
2020-08-05 18:26:35 <Ariadne> like the data overwhelmingly shows that alpine users are not helped by having busybox patch in base system
2020-08-05 18:26:56 <ikke> But isn't that the issue with more bb tools? If users are expecting coreutils and the like?
2020-08-05 18:27:00 <Ariadne> but having a patch that works in base system is worth discussing
2020-08-05 18:27:31 <Ariadne> ikke: yes/no.  what i'm saying is there's a certain level of functionality loss that is acceptable for busybox
2020-08-05 18:27:49 <Ariadne> busybox grep, for example, does not implement all GNU grep features, but is serviceable
2020-08-05 18:28:08 <Ariadne> (note in any future busybox replacement we should aim to do better than busybox, but i digress)
2020-08-05 18:28:36 <Ariadne> busybox patch on the other hand
2020-08-05 18:28:47 <Ariadne> it only supports unified diffs without fuzz
2020-08-05 18:29:04 <ikke> I don't think there is a concrete alternative for bb, right?
2020-08-05 18:29:09 <Ariadne> at this time, no :)
2020-08-05 18:29:20 <mps> huh, we all know all that about bb patch
2020-08-05 18:29:24 <Ariadne> "any future busybox replacement" would be some theoretical thing
2020-08-05 18:29:37 <ikke> Yes
2020-08-05 18:30:21 <Ariadne> mps: i know we do.  my point is that knowing this and continuing to ship busybox patch especially knowing that almost all users who encounter it immediately want to replace it with any other patch program, means we are wasting 20kb of space on something almost nobody uses
2020-08-05 18:30:29 <Ariadne> like, i was legitimately surprised to learn clandmeter was using it
2020-08-05 18:33:40 <mps> yes, I even forgot that long time ago
2020-08-05 18:34:34 <Ariadne> any objection to importing the thunderbird packaging from adelie?
2020-08-05 18:34:40 <Ariadne> what we are shipping is... uhh...
2020-08-05 18:34:43 <Ariadne> quite special
2020-08-05 18:35:14 <mps> I thought we should upgrade it, but I can't find time
2020-08-05 18:35:42 <mps> is the 78.x now supported version
2020-08-05 18:35:57 <mps> well, it is in testing so upgrade is ok, imo
2020-08-05 18:36:34 <Ariadne> the version we ship now crashes randomly
2020-08-05 18:36:48 <Ariadne> i looked at the APKBUILD and it was using gentoo ricer CFLAGS
2020-08-05 18:36:56 <Ariadne> which was ... concerning
2020-08-05 18:36:59 <Ariadne> so i fixed that
2020-08-05 18:37:07 <Ariadne> and now it is doing even more weird stuff
2020-08-05 18:37:11 <mps> heh, I upgraded it few times but I don't use so can't test
2020-08-05 18:37:16 <Ariadne> so i think it is better to import a known good packaging
2020-08-05 18:37:21 <Ariadne> that does not do weird stuff
2020-08-05 18:37:23 <Ariadne> :)
2020-08-05 19:00:25 <ncopa> i think its unfortunate that we break things for upgraders. So removal of bb patch and python changes was unfortunate. We should try avoid doing that kind of things
2020-08-05 19:00:28 <ncopa>  But in this case I think it was necessary.
2020-08-05 19:00:46 <Ariadne> basically this ^
2020-08-05 19:00:49 <Ariadne> is my position
2020-08-05 19:01:33 <Ariadne> anyway, about to push out ifupdown-ng 0.7 to a bunch of my customers
2020-08-05 19:01:34 <Ariadne> :P
2020-08-05 19:01:41 <ncopa> we could have added gnu patch, but that would give a cost for all. bloat for everyone except the few who uses it
2020-08-05 19:01:45 <Ariadne> i call it QA by perkele
2020-08-05 19:02:13 <ncopa> or accept that things break for the few who uses it
2020-08-05 19:02:28 <ncopa> I suppose we should been more verbose of that change
2020-08-05 19:02:28 <Ariadne> basically my position is
2020-08-05 19:02:34 <Ariadne> if we are going to have a patch in the base system
2020-08-05 19:02:37 <Ariadne> it needs to be an actual patch
2020-08-05 19:02:50 <Ariadne> not a version of patch you might buy off amazon for $2
2020-08-05 19:02:59 <mps> yes, I think solution is to be more verbose on upgrades
2020-08-05 19:03:07 <mps> releases*
2020-08-05 19:03:10 <ncopa> your position is that bb patch is simply not good enough
2020-08-05 19:03:11 <Ariadne> that is what the gentoo news thing does
2020-08-05 19:03:46 <Ariadne> ncopa: right, it crashes on too much cases, and this has historically caused lots of complaints
2020-08-05 19:04:06 <Ariadne> there are cases where busybox applets are the best you can get
2020-08-05 19:04:14 <Ariadne> there are also cases where the busybox applet is busybox patch
2020-08-05 19:04:21 <Ariadne> and just annoys people
2020-08-05 19:04:35 <Ariadne> i think in these latter cases, we are better off not shipping the applet
2020-08-05 19:04:54 <Ariadne> because shipping something that crashes with most patches and calling it patch just makes us look bad
2020-08-05 19:05:07 <ncopa> +1
2020-08-05 19:05:37 <Ariadne> ultimately all of this comes down to expectation management
2020-08-05 19:05:47 <Ariadne> both int erms of the expectation that users upgrades won't break
2020-08-05 19:05:50 <mps> anyone have issues with firefox-esr and musl 1.2.1
2020-08-05 19:06:01 <Ariadne> but also the expectation that we will ship useful programs
2020-08-05 19:06:20 <Ariadne> many busybox programs have less features than alternatives, but in most cases they are still useful
2020-08-05 19:06:38 <Ariadne> busybox patch on the other hand is too incomplete to really be useful
2020-08-05 19:07:34 <ncopa> python changes was unfortunate too. I have seen more than one struggle with it
2020-08-05 19:07:42 <ncopa> but the change needed to come sooner or later
2020-08-05 19:07:56 <Cogitri> Yup, but some kind of news system like in gentoo wouldn't hurt
2020-08-05 19:08:00 <Ariadne> python change is unfortunate, but the python community is largely to blame there
2020-08-05 19:08:16 <Ariadne> some portion of the python community refuses to use python3
2020-08-05 19:08:24 <ncopa> heh
2020-08-05 19:08:28 <Ariadne> likewise, we refuse to ship something that is abandoned upstream
2020-08-05 19:08:44 <Ariadne> not much can be done about it
2020-08-05 19:08:55 <ncopa> exactly
2020-08-05 19:09:31 <Ariadne> but i think there is a lot in busybox we ship that we should get rid of
2020-08-05 19:09:38 <Ariadne> i doubt anyone is using nandwrite for example :P
2020-08-05 19:09:48 <ikke> ncopa: is there same way to resync the 32-bits arches with master?
2020-08-05 19:10:06 <ncopa> same way?
2020-08-05 19:10:13 <ikke> Some*
2020-08-05 19:10:19 <ncopa> :)
2020-08-05 19:10:39 <ncopa> should happend when builders succeed
2020-08-05 19:10:42 <Ariadne> i would like to strip busybox down to what we actually use, so that the attack surface is lessened
2020-08-05 19:11:06 <ikke> ncopa: MRs to fix issues stall due to it
2020-08-05 19:11:21 <Ariadne> this also narrows the scope for evaluating our busybox situation
2020-08-05 19:11:22 <ikke> checksum errors unrelated to dl-cdn
2020-08-05 19:11:27 <mps> well, I usually add coreutils after install
2020-08-05 19:11:29 <Ariadne> :D
2020-08-05 19:11:53 <ncopa> ikke: i cuess the most convenient thing would be to make the 32 bit builders continue on error again
2020-08-05 19:11:54 <Ariadne> mps: we ship coreutils to our customers, and real iproute2
2020-08-05 19:12:04 <Ariadne> ncopa: yes, lets do another round of that
2020-08-05 19:12:16 <Ariadne> when i bootstrapped mips, this is something i swapped between several times
2020-08-05 19:12:38 <mps> never wanted to propose add coreutils to base and remove applets from bb which are replaced by coreutils
2020-08-05 19:12:38 <ikke> ncopa: right was thinking along the same line
2020-08-05 19:12:52 <Ariadne> mps: yes, me neither, because we use busybox in initramfs
2020-08-05 19:12:56 <mps> yes, and real iproute2
2020-08-05 19:13:03 <Ariadne> mps: but running coverity on busybox is scary
2020-08-05 19:13:06 <Ariadne> like, really scary
2020-08-05 19:13:52 <Ariadne> running coverity on musl is not so bad
2020-08-05 19:14:06 <Ariadne> it generated a few dead store warnings and some false positives
2020-08-05 19:14:16 <Ariadne> busybox however is yikes
2020-08-05 19:15:18 <Ariadne> mps: what i am saying is, it would be very desirable to replace busybox with a replacement that is written to modern standards, following MISRA as much as possible
2020-08-05 19:15:44 <Ariadne> if we do it right, such a replacement may even be suitable enough to be an alternative to coreutils
2020-08-05 19:16:00 <Ariadne> *but* we are still a ways off from that.  right now, we need to figure out what busybox applets we actually need
2020-08-05 19:16:11 <mps> Ariadne: sometimes I think also but sometimes I'm not sure, because 'we' want small system
2020-08-05 19:16:26 <ncopa> the 32bit builders will no longer halt on errors
2020-08-05 19:16:27 <Ariadne> it is possible to achieve small system and also usable system
2020-08-05 19:16:39 <ikke> ncopa: thanks
2020-08-05 19:17:50 <Ariadne> ifupdown-ng is small, but also usable for example
2020-08-05 19:18:08 <Ariadne> we can certainly do the same with busybox (once we know our actual footprint)
2020-08-05 19:18:18 <ikke> ncopa: the cause apparently was a full disk on master.a.o. I wonder if we want to monitor that :)
2020-08-05 19:18:23 <mps> and I have impression we are loosing battle for simple, small. for secure we lost already
2020-08-05 19:18:34 <ncopa> ikke: i think that is a good idea
2020-08-05 19:18:53 <c705> mps: how so? the small footprint and the musl libc helps. nothing is 100% secure
2020-08-05 19:19:06 <c705> grsec is unfortunate, but what can you do?
2020-08-05 19:19:09 <mps> c705: right that
2020-08-05 19:19:52 <Ariadne> PaX, while nice, is in the process of being upstreamed
2020-08-05 19:20:04 <Ariadne> this stuff just takes a long time
2020-08-05 19:20:25 <Ariadne> anyway busybox is not simple or small :)
2020-08-05 19:20:49 <c705> i'd like to think we're better off than 95% of the other distros out there
2020-08-05 19:21:08 <c705> in terms of baseline security (which by the way, is also dependant heavily on the operator)
2020-08-05 19:21:26 <Ariadne> busybox is especially not secure :p
2020-08-05 19:21:48 <mps> c705: we are probably still better but ...
2020-08-05 19:23:56 <ikke> ncopa: question is how :)
2020-08-05 19:24:18 <ncopa> we dont run zabbix on that host?
2020-08-05 19:24:35 <c705> of course, always room for improvement
2020-08-05 19:24:45 <ncopa> ikke: lets talk about that tomorrow in #alpine-infra
2020-08-05 19:24:48 <ikke> ncopa: no, I don't have acess
2020-08-05 19:24:56 <ikke> ncopa: alright
2020-08-05 20:22:32 <Ariadne> ifupdown-ng 0.7 has been branched btw
2020-08-05 20:22:50 <Ariadne> alpine will follow ifupdown-ng 0.7.x branch for 3.13
2020-08-05 20:34:28 <Terror> Hi team, can we enable svlogd in the default busybox config? It'd be really useful for containerised workloads to have some sort of log mgmt out of the box
2020-08-05 20:34:40 <Terror> Sorry for the repeated message, my connection died and I lost all history :(
2020-08-05 20:34:50 <ikke> I don't think anyone responded yet
2020-08-05 20:34:55 <ikke> how bug would svlogd be?
2020-08-05 20:34:57 <ikke> big*
2020-08-05 20:35:16 <Terror> It says 16k on the .config file
2020-08-05 20:35:20 <ikke> And I think the tendency is to use less features of bb, not more
2020-08-05 20:35:54 <Terror> I can create an aport but it seems silly given that BB is already shipped on the base system
2020-08-05 20:37:58 <ikke> Isn't the idea with docker to log to stdout and let docker collect the logs? Or is this for more elaborate setups?
2020-08-05 20:37:58 <Terror> That's an interesting comment, I've been impressed with how much I can do with the base system. Alpine has been my daily driver for the last 6 years, but I don't use any DE so maybe that affects my opinion.
2020-08-05 20:38:48 <ikke> apparently bb code quality isn't that good.
2020-08-05 20:39:02 <Terror> Yes, that's the general recommendation. It is good enough in a vast majority of the cases.
2020-08-05 20:39:36 <Terror> I'm not qualified to asses BB code quality so I'll go with the project's opinion.
2020-08-05 20:44:47 <ikke> same for me :)
2020-08-05 21:05:02 <Ariadne> it is ok to enable svlogd
2020-08-05 21:05:11 <Ariadne> what we want to do
2020-08-05 21:05:22 <Ariadne> is figure out what parts of busybox are actually needed
2020-08-05 21:05:29 <Ariadne> that way we can figure out how we want to approach this
2020-08-05 21:05:40 <Ariadne> some parts of busybox we already plan to replace (such as ifupdown)
2020-08-05 21:05:57 <Ariadne> there are parts of busybox that are ok, too
2020-08-05 21:06:04 <Ariadne> its a mixed bag
2020-08-05 21:06:42 <ikke> Terror: so I guess you should open an issue on gitlab to request it to be enabled (or make a MR)
2020-08-05 21:07:04 <mps> svlogd is also in runit pkg
2020-08-05 21:07:29 <mps> care for conflict
2020-08-05 21:08:09 <ikke> shouldn't that be solved by the usual bb mechanisms?
2020-08-05 21:08:45 <ikke> runit places it in /sbin
2020-08-05 21:12:40 <mps> year ago I thought to enable all runit bins in bb, but didn't. apk add runit is good enough for me
2020-08-05 21:16:22 <Ariadne> honestly yeah
2020-08-05 21:16:24 <Ariadne> just use runit
2020-08-05 21:16:43 <Ariadne> lets not add more to busybox when there is already competent implementation available :P
2020-08-05 21:38:28 <Terror> Understood
2020-08-05 22:04:18 <minimal> Terror: for containerised Alpine have you looked at s6-overlay?
2020-08-05 22:04:32 <minimal> Its currently packaged in Edge.
2020-08-05 22:05:57 <Terror> Yes, used both s6 and runit. This was a simpler use case and I'm happy with installing any of those just for the `svlogd` of `multilog` binary.
2020-08-06 06:37:57 <ncopa> morning
2020-08-06 06:38:22 <ncopa> looks like chromium is broken. does not work with thelounge
2020-08-06 06:38:45 <ncopa> something this weeks seems to have introduced it
2020-08-06 06:39:41 <ncopa> and xfce4-terminal still deadlocks
2020-08-06 06:40:46 <ncopa> chromium gives: Error code: RESULT_CODE_INVALID_SANDBOX_STATE
2020-08-06 06:41:10 <Cogitri> Morning
2020-08-06 06:41:25 <Cogitri> I guess some seccomp thingie again
2020-08-06 06:42:42 <Cogitri> Weird that xfce-terminal is still broken for you,it was fixed for fabled with the glib upgrade 🤔
2020-08-06 06:42:54 <ncopa> yes, i think that is weird too
2020-08-06 06:43:10 <ncopa> seems like the problem got worse, with musl 1.2.1?
2020-08-06 06:43:24 <ncopa> ok. chromium works again with musl 1.2.0
2020-08-06 06:43:30 <Cogitri> The problem being xfce-terminal or Chromium?
2020-08-06 06:43:33 <Cogitri> Ah, chromium
2020-08-06 06:43:34 <ncopa> chromium
2020-08-06 06:43:56 <Cogitri> I also noticed my Chromium App thingie for Element.io crashing more often after upgrading
2020-08-06 06:47:40 <ncopa> i wonder if i could get some help debugging chromium
2020-08-06 06:51:34 <mps> also I have issues with firefox-esr after upgraded musl to 1.2.1
2020-08-06 06:52:03 <mps> I wrote about this yesterday on #musl
2020-08-06 06:52:48 <mps> *on aarch64
2020-08-06 06:53:39 <ncopa> firefox 79.0 seems to work on x86_64
2020-08-06 06:54:27 <mps> my is firefox-esr-78.1.0-r0, aarch64
2020-08-06 06:56:23 <mps> dalias mentioned it could be memcpy asm issue
2020-08-06 06:56:51 <mps> but I don't have time rebuild musl by remove this change
2020-08-06 07:41:58 <Cogitri> Hm, does someone know what's up with armhf python3 packages failing to pull in py3-ruamel.yaml ?
2020-08-06 07:42:10 <Cogitri> There doesn't seem to be a circular dep and it's not disable on armhf either
2020-08-06 07:45:24 <Cogitri> ^ that's currently the main blocker on armhf apparently
2020-08-06 07:48:24 <ncopa> no clue...
2020-08-06 07:51:29 <ncopa> any idea how to debug chromium? there was some args to make the sandbox run in strace or similar, but i cannot find it
2020-08-06 07:53:55 <Cogitri> If you're OK with recompiling chromium, replacing `SECCOMP_RET_KILL` with `SECCOMP_RET_TRAP` should make syscalls that seccomp doesn't like show up in strace
2020-08-06 07:57:42 <ncopa> thanks!
2020-08-06 07:57:49 <ncopa> --renderer-cmd-prefix="strace" is what i was looking for
2020-08-06 07:58:24 <ncopa> xfce4-terminal hangs are also very annoying. they seems to get worse with musl 1.2.1. will probably have to try debug that afterwardss
2020-08-06 07:58:56 <Cogitri> Good luck :)
2020-08-06 08:06:08 <ncopa> Thread 19 "Chrome_ChildIOT" received signal SIGSYS, Bad system call.
2020-08-06 08:06:08 <ncopa> [Switching to LWP 23135]
2020-08-06 08:06:08 <ncopa> 31		return ret;
2020-08-06 08:06:08 <ncopa> pthread_setschedparam (t=0x7fffe7479b20, policy=2, param=0x55555cd96130) at ./arch/x86_64/syscall_arch.h:31
2020-08-06 08:14:05 <ncopa> looks like it is SYS_sched_setscheduler
2020-08-06 08:18:59 <ikke> ncopa: I think we can set x86 back to fail on error? I saw that testing was uploaded
2020-08-06 08:19:22 <ncopa> lets keep it like it is til after the weekend
2020-08-06 08:19:25 <ikke> ok
2020-08-06 08:21:47 <Thermi> I still got some MRs open that need reviewing, e.g. https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/66
2020-08-06 08:22:58 <Thermi> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10694 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/7 https://gitlab.alpinelinux.org/Thermi/mkinitfs/-/merge_requests/1
2020-08-06 08:26:34 <ncopa> sorry, i dont think i will have time today :-/
2020-08-06 08:27:22 <Thermi> That's fine. It's been such a long time, I am concerned that it just gets forgotten because those MRs are actual bugfixes for stuff we found
2020-08-06 08:28:38 <Thermi> I'd be grateful for any response I get about the MRs, hopefully a positive one so I can scratch them from my to do list
2020-08-06 08:29:28 <Cogitri> Thermi: Could you please rebase !10694 ?
2020-08-06 08:29:42 <Thermi> Cogitri: Will do!
2020-08-06 08:29:51 <Cogitri> Also, seems like you accidentally made a MR against your fork of mkinitfs and not the actual upstream project
2020-08-06 08:30:08 <Thermi> I'll rebase that then too
2020-08-06 08:31:23 <Cogitri> I don't think rebasing will fix that, you'll have to open a MR at https://gitlab.alpinelinux.org/alpine/mkinitfs instead of doing it on your fork
2020-08-06 08:31:50 <ikke> I think you should be able to change the target of the merge request
2020-08-06 08:32:18 <Cogitri> Hm, I think you can only change the target branch and not the target project
2020-08-06 08:32:28 <ikke> yeah, indeed
2020-08-06 08:32:39 <Thermi> Cogitri: Oh, I just took a link at the URL and saw what you mean
2020-08-06 08:32:41 <ikke> thought you could change the target repo as well, but that's I guess only when you create the MR
2020-08-06 08:32:49 <Thermi> well, understood what you wrote exactly
2020-08-06 08:37:54 <Thermi> Cogitri: ikke https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/68
2020-08-06 08:38:03 <Thermi> Ty for telling me
2020-08-06 08:38:35 <Thermi> Cogitri: I also rebased !10694
2020-08-06 08:39:41 <Thermi> Btw, why exactly is amavis (and perl-db) not available on x86_64? It builds fine on those platforms.
2020-08-06 08:41:02 <Cogitri> Seems like they are available on x86_64, they're only disabled on x86
2020-08-06 08:42:46 <Thermi> Ah! I see. Sorry, didn't notice the difference.
2020-08-06 08:43:00 <Thermi> I'll make an amend to my MR to exclude x86 then too
2020-08-06 08:44:05 <Cogitri> 👍
2020-08-06 08:48:57 <Thermi> Cogitri: I added the exclude. The CI pipelines ran through, except build-ppc64le, that one is still waiting for a runner.
2020-08-06 08:51:12 <ikke> Cogitri: I see 2 jobs building firefox. I guess one can be canceled?
2020-08-06 08:51:20 <ikke> (2 jobs for ppc64le)
2020-08-06 08:53:48 <Cogitri> Ah yes, one of them can be cancelled
2020-08-06 08:54:14 <ikke> I assume the earlier one
2020-08-06 09:00:41 <Cogitri> Yup
2020-08-06 09:00:47 <clandmeter> in my docker image im switching from 3.11 to 3.12 and suddenly its missing some py modules. py3-six py3-setuptools py3-requests. i need to manually install them. is that some kind of change?
2020-08-06 09:02:36 <ikke> clandmeter: https://pkgs.alpinelinux.org/packages?name=py3-six&branch=v3.12
2020-08-06 09:02:56 <ikke> https://pkgs.alpinelinux.org/packages?name=py3-setuptools&branch=v3.12
2020-08-06 09:03:01 <ikke> They still exist
2020-08-06 09:03:11 <clandmeter> i know they exist
2020-08-06 09:03:12 <ikke> ok
2020-08-06 09:03:17 <ikke> I understand now what you mean
2020-08-06 09:03:31 <Thermi> Cogitri: pipelines passed
2020-08-06 09:03:41 <clandmeter> switch from 3.11 to 3.12 i suddenly need to manually install them
2020-08-06 09:03:54 <clandmeter> so i guess some dependency changed somewhere?
2020-08-06 09:03:57 <ikke> clandmeter: do you have an idea what pulled them in before?
2020-08-06 09:04:14 <clandmeter> its my netbox dockerfile
2020-08-06 09:05:23 <clandmeter> before i only installed python3 postgresql-client myself
2020-08-06 09:05:38 <clandmeter> rest came from requirements.txt with pip3
2020-08-06 09:10:14 <ikke> I'm not sure how you would have got them with 3.11
2020-08-06 09:10:34 <Cogitri> Thermi: Merged, sorry for the delay
2020-08-06 09:10:45 <ikke> just installing python3 and postgresql-client is not enough to get those modules installed, even on 3.11
2020-08-06 09:12:30 <clandmeter> ah there was another change, pip3 was missing in my build stage and in 3.11 it was not.
2020-08-06 09:13:17 <Thermi> Cogitri: ty!
2020-08-06 09:26:47 <Cogitri> Hm, why does mongo-cxx-driver fail on armhf? mongo-c-driver (the dep it doesn't find) is available on armhf 🤔
2020-08-06 09:29:07 <ikke> Cogitri: it's not present on the builder
2020-08-06 09:30:33 <Cogitri> Hm
2020-08-06 09:30:51 <ikke> build failure
2020-08-06 09:31:57 <ikke> https://tpaste.us/EOpR
2020-08-06 09:34:22 <Cogitri> Thanks, just gonna disable it for now to unblock builders then
2020-08-06 09:34:29 <Cogitri> I doubt anyone uses it on armhf anyway
2020-08-06 09:34:40 <ikke> it also failed on armv7
2020-08-06 09:35:45 <Cogitri> Oh
2020-08-06 11:27:07 <ncopa> i think i finally solved the xfce4-terminal issue
2020-08-06 11:27:33 <ncopa> vte has(had) a copy of the buggy glib code
2020-08-06 11:27:58 <ncopa> should be fixed in git master upstream after a refactor, but  they will not backport to current stable
2020-08-06 11:28:17 <Cogitri> Oh, good that you've caught it
2020-08-06 11:28:20 <ncopa> i think i have solved it though, by using alloca() instead of malloc()
2020-08-06 11:28:43 <Cogitri> I think Tilix sometimes for for me too (although rather infrequently), maybe that fixes that too :)
2020-08-06 11:29:05 <Cogitri> s/s for/s freezes/
2020-08-06 11:29:05 <alpine-meetbot> Cogitri meant to say: I think Tilix sometimes freezes for me too (although rather infrequently), maybe that fixes that too :)
2020-08-06 11:29:16 <Cogitri> Since that also uses vte3
2020-08-06 11:29:17 <ncopa> does tillix use vte3?
2020-08-06 11:29:29 <ncopa> yeah, i thikn this should fix tilix too
2020-08-06 11:41:24 <ikke> hmm, why isn't mopidy (in community) built before py3-mopidy-mpd (in testing)
2020-08-06 11:43:56 <Cogitri> Seems like there are more weird things like that, it's weird that py3-ruaml.yaml isn't built either (and lots of pkgs fail due to that)
2020-08-06 11:44:08 <Cogitri> I think it's because the builders are in keep going mode
2020-08-06 11:44:26 <ikke> If I look at the output of buildrepo -n community, these packages are listed to be built
2020-08-06 11:44:36 <Cogitri> Huh
2020-08-06 11:45:14 <ikke> https://tpaste.us/qlO9
2020-08-06 11:46:06 <Cogitri> That's weird
2020-08-06 13:20:59 <ncopa> ok, i think i found fix for chromium with musl 1.2.1
2020-08-06 13:29:03 <ikke> nice
2020-08-06 13:35:30 <Cogitri> 🎉
2020-08-06 13:57:26 <ncopa> needed to allowlist sched_setscheduler
2020-08-06 14:25:34 <maxice8> nice
2020-08-06 14:26:00 <maxice8> @ncopa the lib64 problem already has an MR present to add 'lib64' option to ignore checks on /lib64 and /usr/lib64
2020-08-06 14:49:25 <ncopa> ah good
2020-08-06 15:07:01 <Ariadne> [08:26:01] <@maxice8> @ncopa the lib64 problem already has an MR present to add 'lib64' option to ignore checks on /lib64 and /usr/lib64
2020-08-06 15:07:04 <Ariadne> lib64 problem ?
2020-08-06 15:07:14 <Ariadne> we don't want lib64
2020-08-06 15:07:54 <maxice8> that is the problem
2020-08-06 15:08:11 <maxice8> we don't want lib64 but some packages install it (cmake without CMAKE_INSTALL_LIBDIR=lib most commonly)
2020-08-06 15:08:18 <Ariadne> ah yes
2020-08-06 15:08:29 <Ariadne> i see what you're saying now
2020-08-06 15:08:38 <Ariadne> so other abuild users can override the policy
2020-08-06 15:08:50 <maxice8> so I added a check in postcheck() that will error out if /lib64 or /usr/lib64 is found
2020-08-06 15:09:00 <maxice8> apparently musl needs it for glibc compat so I need to add an option for it
2020-08-06 15:09:07 <Ariadne> huh?
2020-08-06 15:09:10 <maxice8> it being ignore the checks it is actually a legitimate usage of lib64
2020-08-06 15:09:22 <Ariadne> musl does not install anything to lib64
2020-08-06 15:09:35 <Ariadne> or do you mean libc6-compat?
2020-08-06 15:09:49 <Ariadne> because we should just drop libc6-compat and tell people use gcompat instead
2020-08-06 15:09:53 <maxice8> libc6-compat
2020-08-06 15:10:43 <Ariadne> hopefully the networking patches for honeycomb will be something reasonable by 5.9 ;/
2020-08-06 15:26:23 <mps> is the 'lib64' must for multiarch
2020-08-07 21:53:20 <ncopa> yes, 32bit only
2020-08-07 21:55:56 <dalias> so the mismatch does not seem to be a change to long long
2020-08-07 21:56:05 <dalias> it seems to be just size_t vs unsigned long
2020-08-07 21:56:15 <dalias> (same representation, different types)
2020-08-07 22:00:12 <ncopa> ok
2020-08-07 22:00:39 <ncopa> i guess its safe to simply remove the typedef
2020-08-07 22:01:11 <ncopa> and rely on the moonjit one
2020-08-07 22:07:33 <ncopa> thanks! and good night
2020-08-07 23:08:29 <timlegge> mps: ncopa oalders patched WWW-Mechanize-Cached to fix  https://github.com/metacpan/metacpan-client/issues/103 just waiting on a release now
2020-08-07 23:10:30 <mps> timlegge: nice
2020-08-07 23:12:17 <mps> so we don't need to merge your fix, just upgrade WWW-Mechanize-Cached when it is released?
2020-08-08 01:00:48 <dalias> ncopa, see the pulseaudio issue on #musl
2020-08-08 01:54:56 <timlegge> mps: pretty much unless the wait is too long for the release but i suspect a day or two
2020-08-08 08:00:46 <Cogitri> Does someone have the link to the source repo for your new docs handy?
2020-08-08 10:25:41 <Cogitri> I guess https://gitlab.alpinelinux.org/alpine/docs/developer-handbook is the repo for the new docs?
2020-08-08 10:27:05 <ikke> that's the developers part, yes
2020-08-08 10:27:09 <ikke> user handbooks is here: https://gitlab.alpinelinux.org/alpine/docs/user-handbook
2020-08-08 10:43:10 <Cogitri> Ah yes, I'll probably only work on the dev part
2020-08-08 12:09:36 <mps> timlegge: someone already merged it
2020-08-08 12:10:10 <Cogitri> Yup, merged it earlier today
2020-08-08 12:10:46 <mps> ah, ok. we have to care to not remember it when fixes are released
2020-08-08 12:11:09 <Cogitri> Upstream is already in the process of making a release for a proper fix I think
2020-08-08 12:11:24 <mps> yes, I know I follow it
2020-08-08 12:11:46 <Cogitri> 👍
2020-08-08 12:35:38 <timlegge> thanks I saw.  will keep an eye out on upstream.  there is a patch available for the issue that could be applied to perl-www-mechanize-cached but it can probably wait for a official release
2020-08-08 12:40:34 <ikke> hmm, clsync uses raw syscalls __NR_clock_gettime, __NR_gettimeofday
2020-08-08 12:40:41 <ikke> https://wiki.adelielinux.org/wiki/Project:Time64#Raw_system_calls
2020-08-08 15:05:07 <wsinatra> out of curiosity, are the 32bit builders still acting up?
2020-08-08 15:20:30 <ikke> There are still packages that fail to build, if that's what you mean
2020-08-08 15:23:17 <wsinatra> with all the musl changes that's not surprising, I guess it's more so on packages that do seem to build fine, I'm only seeing the 64 bit versions available after a new merge
2020-08-08 15:32:48 <ikke> Yes, we alternate the builders between continue on failure and halt on failure
2020-08-08 15:33:06 <ikke> right now, it's halt on failure, so it's easier to see what is currently blocking the builders
2020-08-08 15:40:21 <wsinatra> ah that makes a lot more sense then
2020-08-08 17:03:45 <ikke> Cogitri: I have the fix for mongo-c-driver not building btw
2020-08-08 17:04:57 <ikke> Nice, it's even upstream already: https://github.com/mongodb/mongo-c-driver/commit/547b23e94ab473b4d6754546e625bb2f1b8809ea
2020-08-09 13:21:27 <Cogitri> Hello 👋
2020-08-09 13:21:36 <Cogitri> I hope Synapse (&IRC) work again now
2020-08-09 13:24:07 <ikke> Cogitri: o/
2020-08-09 13:24:30 <ikke> gnr3-converted seems to have messed up permissions in the package
2020-08-09 13:24:36 <ikke> sorry,
2020-08-09 13:24:46 <Cogitri> Hooray, thanks for the msg, ikke :)
2020-08-09 13:24:52 <ikke> :)
2020-08-09 13:25:03 <ikke> py3-cx_freeze has messed up permissions
2020-08-09 13:25:10 <ikke> which is a dependency for gns3-converter
2020-08-09 13:25:18 <ikke> files that are 0700
2020-08-09 13:25:44 <ikke> directories that are 2700
2020-08-09 13:26:07 <ikke> and those files end up in the package with those permissions
2020-08-09 13:38:33 <shrizza> #alpine-linux
2020-08-09 14:41:28 <ikke> yay, circular dependency
2020-08-09 14:41:58 <ikke> py3-dask -> py3-fsspec -> py3-distributed -> py3-dask
2020-08-09 14:49:46 <ikke> PureTryOut[m]: ping
2020-08-09 14:50:00 <ikke> 1b3d1e04cc78dc7ec23cff0c1eeb763bd82d8276
2020-08-09 14:50:09 <ikke> Seems that caused the circular dependency
2020-08-09 14:51:59 <PureTryOut[m]> Ugh... Well, removing that package again would just disable the specific tests that need that dependency, so it's safe to remove
2020-08-09 14:56:25 <ikke> ok, will do
2020-08-09 14:57:51 <ikke> is it just enough to remove py3-distributed?
2020-08-09 14:58:29 <ikke> ugh, py3-fsspec upstream archive seems to have changed :-/
2020-08-09 14:58:37 <ikke> sha512sum: WARNING: 1 computed checksum did NOT match
2020-08-09 15:10:19 <minimal> is there any summary page of the current status of 32bit package builds?
2020-08-09 15:10:34 <ikke> not really
2020-08-09 15:11:16 <ikke> We only have https://build.alpinelinux.org, but that only shows recent failures
2020-08-09 15:12:46 <minimal> Ok. Noticing the same thing someone else mentioned before of merges for package updates resulting in 64 packages rolling out but 32bit archs staying on previous version of package
2020-08-09 15:13:34 <ikke> yes, that's expected indeed
2020-08-09 15:13:55 <ikke> We're working hard fixing all the build failures
2020-08-09 15:14:28 <minimal> yeah I realise there's issues, not trying to put pressure on anyone
2020-08-09 15:15:40 <minimal> its been a few weeks of build hiccups around musl 1.2.x, hopefully things will smooth out soon
2020-08-09 15:24:43 <maxice8> @PureTryOut ping
2020-08-09 15:37:11 <ikke> maxice8: hi
2020-08-09 15:37:19 <maxice8> Hey Ikke :D
2020-08-09 15:37:34 <ikke> You just missed PureTryOut[m] :)
2020-08-09 15:38:16 <ikke> hmm, filesystem_spec current package differs just one byte
2020-08-09 15:42:19 <Cogitri> Huh
2020-08-09 15:58:23 <ikke> checksum mismatch
2020-08-09 15:58:59 <ikke> filesystem_spec-0.8.0.tar.gz filesystem_spec-0.8.0_2.tar.gz differ: byte 88893, line 310 is 144 d 354 M-l
2020-08-09 15:59:13 <ikke> can be just a date or something like that
2020-08-09 16:06:50 <Cogitri> I guess it'd be safe to just update the checksum then?
2020-08-09 16:09:52 <ikke> yes, I think so too
2020-08-09 16:17:20 <ikke> Cogitri: any clue what this means? "error: use of deleted function 'QWebEngineFullScreenRequest& QWebEngineFullScreenRequest::operator=(const QWebEngineFullScreenRequest&)'"
2020-08-09 16:17:30 <ikke> qt5-qtwebengine
2020-08-09 16:18:22 <Cogitri> I don't know Qt, but I think that's on armv7?
2020-08-09 16:18:31 <ikke> yes
2020-08-09 16:18:49 <Cogitri> I think for some reason it's still on 5.14 on armv7
2020-08-09 16:18:55 <Cogitri> So there's a version mismatch
2020-08-09 16:19:11 <ikke> hmm
2020-08-09 16:21:01 <ikke> qt5-qtbase is on 5.15
2020-08-09 16:21:24 <ikke> I don't see anyhting on 5.14
2020-08-09 16:21:30 <ikke> https://pkgs.alpinelinux.org/packages?page=2&branch=edge&name=qt5-%2A&arch=armv7
2020-08-09 16:22:33 <Cogitri> Oh, I guess it might have been rebuild by now, last time I looked the builders were still in keep going mode
2020-08-09 16:22:41 <maxice8> Can someone vet !11248 ?
2020-08-09 16:25:14 <ikke> maxice8: seems pretty trivial?
2020-08-09 16:25:19 <ikke> https://lkml.org/lkml/2020/8/7/579
2020-08-09 16:32:30 <ikke> maxice8: any particular reason you ask to vet that upgrade?
2020-08-09 16:32:48 <maxice8> felt like it
2020-08-09 17:20:18 <ikke> ok
2020-08-09 17:28:25 <mps> does nm -u libname.so.x.y shows undefined symbols
2020-08-09 17:29:04 <mps> though I don't understand why they are then listed referenced by name in lib
2020-08-09 18:04:03 <awilfox> just out of curiosity, is there any reason why apk's download speed is so much slower than actual link speed?  I notice that if I use NFS mounted /srv/repository it is faster than if I use http with the same server
2020-08-09 18:04:10 <awilfox> over LAN
2020-08-09 18:04:20 <awilfox> not to mention WAN, where it at least seems to feel even slower
2020-08-09 18:04:54 <awilfox> I was hoping the TCP_CORK thing would fix it, but it doesn't seem to have done much/any good
2020-08-09 18:08:23 <ikke> How much speed difference are we talking about?
2020-08-09 18:10:12 <awilfox> looks like apk can just barely get 1 MB/s out of http
2020-08-09 18:10:20 <awilfox> it can do >40 MB/s using NFS
2020-08-09 18:13:36 <ikke> maybe something else in libfetch
2020-08-09 18:17:06 <detha> does apk open a new connection for each package?
2020-08-09 19:09:29 <mps> finally solved video playing problem with firefox on musl 1.2.1
2020-08-09 19:09:42 <Cogitri> Nice
2020-08-09 19:09:53 <mps> rebuilt FF without libpulse, pipewire and libdbus
2020-08-09 19:09:57 <maxice8> there was one ?
2020-08-09 19:10:40 <mps> maxice8: yes, FF and chromium have problem to play videos when musl is upgraded to 1.2.1
2020-08-09 19:11:11 <mps> at least on some arches, not yet tested extensively
2020-08-09 19:14:54 <mps> maxice8: I think it is related to #11815
2020-08-09 20:14:38 <c705> vlc as well
2020-08-09 20:14:56 <c705> I assume they're all releated
2020-08-09 22:05:29 <Cogitri> ikke: Ah, I think py3-qtwebengine is failing because it's still on 5.14, not the other way aorund
2020-08-09 22:33:13 <maxice8> Can someone confirm this circular dependency ? curl->brotli-dev->cmake->curl-dev
2020-08-09 22:34:02 <Hello71> sounds plausible
2020-08-09 23:47:21 <maxice8> This one py3-dask->py3-fsspec->py3-distributed->py3-dask
2020-08-10 00:14:57 <maxice8> oh, @Ikke fixed it
2020-08-10 00:18:54 <maxice8> @Ikke upgraded mkmr to 0.0.31 it should have nice manpages and should fit with your usecase nicely
2020-08-10 04:38:54 <ikke> maxice8: ok, wlll check it out
2020-08-10 07:27:08 <ncopa> morning
2020-08-10 07:29:53 <Cogitri> Morning 👋
2020-08-10 07:32:25 <mps> \o
2020-08-10 07:35:54 <mps> ncopa: did you solved chromium video playing issue
2020-08-10 07:40:03 <mps> for firefox I solved it by building without libpulse, pipewire and libdbus
2020-08-10 07:41:18 <mps> looks like the problem is somewhere how FF uses dbus
2020-08-10 07:42:26 <mps> on musl 1.2.1, I mean. on musl 1.2.0 this problem doesn't exists
2020-08-10 08:06:21 <ikke> good morning
2020-08-10 08:36:26 <Cogitri> Hm, I want to add install_if to gnome-software-plugin-apk since the current depends="gnome-software-plugin-apk" causes a circular dep on gnome-software -> gnome-software-plugin-apk -> gnome-software-dev
2020-08-10 08:36:48 <Cogitri> Since -plugin-apk is only available on x86_64 and aarch64, do I need to make the install_if conditional for those two arches too?
2020-08-10 08:39:46 <Cogitri> !11261
2020-08-10 09:28:40 <ncopa> mps: what chromium video playing issue? it seems like at least youtube works with chromium
2020-08-10 09:29:31 <ikke> https://gitlab.alpinelinux.org/alpine/aports/issues/11815
2020-08-10 09:31:14 <ncopa> right, thats firefox but afaik chromium works?
2020-08-10 10:17:50 <indy> hi all, i have apkbuild which tries to download source from site which uses authentication. will .netrc file help?
2020-08-10 10:23:33 <ikke> apk uses libfetch, so, no
2020-08-10 10:24:27 <indy> ikke, i tried .curlrc and it complained about format
2020-08-10 10:28:28 <mps> ncopa: ah, I thought that the chromium have same/similar problem as firefox
2020-08-10 10:29:27 <mps> but looks like both have issues with seccomp on musl 1.2.1, though I'm not sure
2020-08-10 10:29:45 <HRio> any idea for how the silent package hold back should be solved for v3.11 to v3.12 upgrades? #11714
2020-08-10 10:30:44 <HRio> at least 4 packages are held by by this (but apk just says OK)
2020-08-10 10:31:25 <HRio> In my case glib, libffi, p11-kit and python3 is held back
2020-08-10 10:33:17 <Cogitri> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10695
2020-08-10 10:33:32 <Cogitri> I think the only way to fix this is to rework the error reporting on apk-tools' side
2020-08-10 10:33:56 <HRio> should we not have an empty python package the depends on python2?
2020-08-10 10:34:49 <Cogitri> We had that previously via the `provides=python` thingie for python2
2020-08-10 10:35:01 <Cogitri> But that was removed so apps have to explicitly choose which python version they want
2020-08-10 10:35:08 <HRio> this package could be part of the python2 package so it has the correct version
2020-08-10 10:36:45 <HRio> if we have no technical fix, at least the upgrade docs should mention this
2020-08-10 10:36:56 <Cogitri> 5ad0ec7da1064361cc74d56edf7524960f49ef9b
2020-08-10 10:37:20 <Cogitri> There's really no technical fix other than fixing apk-tools and so far no one has stepped up to dig into that
2020-08-10 10:37:47 <Cogitri> But yes, it should definitely be in the update docs (I was under the impression we already added that after it broke some people's system)
2020-08-10 10:38:30 <HRio> only this https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0#python2_no_longer_provides_python_and_python-devel
2020-08-10 10:39:54 <HRio> I added this to the discussion page https://wiki.alpinelinux.org/wiki/Talk:Release_Notes_for_Alpine_3.12.0
2020-08-10 11:01:10 <detha> What would be nice would be something like a python-default3 package, that creates a symlink and changes apk's behavior so that 'apk install py-foo' becomes py3-foo.
2020-08-10 11:02:06 <detha> I already dread the day there will be a python4, and all ansible playbooks will have to be combed through. again.
2020-08-10 11:19:55 <Cogitri> We explicitly moved away from that
2020-08-10 11:20:34 <Cogitri> Because s/py3/py4/ on some install script is a lot better than your setup suddenly blowing up because you have a fun frankenstein mix of py3 and py4 things
2020-08-10 11:21:43 <Cogitri> And with pyX-default package we'd have more magic in the install process, suddenly py-foo could install whatever version for you because your docker baseimage installed pyY-foo instead of pyX-foo that you expected
2020-08-10 11:36:05 <nmeum> is there a specific reason why 52b080010796c7c54ab8f56fc1c50ad4c88b6d3c was not applied for firefox-esr?
2020-08-10 11:36:46 <Cogitri> I don't think so
2020-08-10 11:37:40 <nmeum> lets see if it applies cleanly…
2020-08-10 11:38:13 <nmeum> `abuild fetch unpack prepare` alone takes ages with firefox :(
2020-08-10 11:39:02 <Cogitri> Fortunately not as bad as chromium yet :D
2020-08-10 11:39:15 <nmeum> patch applies, should I just push it?
2020-08-10 11:40:52 <nmeum> https://tpaste.us/jxrn
2020-08-10 11:50:30 <nmeum> pushed it
2020-08-10 11:56:17 <Cogitri> 👍
2020-08-10 12:00:32 <indy> ikke, netrc in .curlrc was digested, but not effectively used
2020-08-10 12:01:51 <detha> Cogitri: hmm. py2 and py3 mixed runs fine, admittedly a symlink could cause some chaos
2020-08-10 12:03:14 <detha> guess it's better to just make it - "{{pyversion}}-foo" in the playbooks
2020-08-10 12:03:48 <Cogitri> detha: It runs fine if you expect things to be setup that way, but if your package X needs py4-foo but only py-foo is installed that could be any python version things are sure to blow up at some point
2020-08-10 12:04:38 <detha> there shouldn't be a py-foo, only py3-foo and py4-foo
2020-08-10 12:06:21 <detha> Just some magic so 'apk add py-foo' picks the right one for that system
2020-08-10 12:06:23 <Cogitri> py-foo would install that, yes
2020-08-10 12:06:46 <Cogitri> But imagine your base image changing the default version without you knowing about it
2020-08-10 12:07:07 <Cogitri> And then suddenly your py3 app you installed manually doesn't work anymore because only py4 packages are installed
2020-08-10 12:07:19 <Cogitri> Even though you do exactly the same install command as before
2020-08-10 12:07:54 <Cogitri> So IMHO doing one sed is a lot better than breaking everyone's system when we change the default python version
2020-08-10 12:08:16 <detha> Shouldn't happen, unless I change base install to have py4-default.
2020-08-10 12:08:21 <ikke> (we already broke a lot of peoples systems on upgrade)
2020-08-10 12:09:13 <detha> But then, I don't do much docker stuff, but I have playbooks that work across *bsd,centos,debian,alpine for some function
2020-08-10 12:09:45 <Cogitri> detha: Yes, but we'd have to change the default from py3 to py4 at some point, so at the latest when upstream Alpine changes it'd break
2020-08-10 12:10:36 <detha> no. don't set a default, just supply two packages default-py3 and default-py4 so someone can set the default
2020-08-10 12:10:57 <detha> neither of them comes in a base install
2020-08-10 12:11:11 <Cogitri> But most docker base images will want to install that
2020-08-10 12:11:29 <Cogitri> Two commands doing something completely different due to some magical package really doesn't seem like a good idea to me
2020-08-10 12:12:13 <Cogitri> Since again, changing from py3 to py4 probably will break something, so you don't want that change to be pushed to you without you knowing about it
2020-08-10 12:12:18 <detha> yeah. I forgot about the whole docker prebuilt ecosystem, so ne'er mind
2020-08-10 12:14:48 <ikke> there is more than just docker though
2020-08-10 12:16:53 <detha> yes. but it would probably be a Bad Thing(tm) to have something that breaks docker setups for mild gain elsewhere.
2020-08-10 14:32:50 <tmhoang> ikke: Hi, are you ok if I make a request to move testing/yq (recently added) to community and make a backport to 3.10-3.12 ?
2020-08-10 14:36:36 <ikke> tmhoang: we don't backport new packages..
2020-08-10 14:36:46 <ikke> tmhoang: moving it to community should be fine
2020-08-10 14:37:42 <tmhoang> understood, thanks
2020-08-10 14:37:55 <ikke> tmhoang: yq does not have any dependencies, so it should even be safe enough to use from edge
2020-08-10 14:38:07 <ikke> (except musl)
2020-08-10 14:38:50 <tmhoang> ikke: the people that poked me don't use testing - and refused to understand the dependencies as you just explained <sign>
2020-08-10 14:39:10 <ikke> Moving it to community should be no issue
2020-08-10 14:39:15 <tmhoang> yep
2020-08-10 14:40:13 <tmhoang> funny thing, while I was doing some reading on github, there are whole lot of important projects that are still using FROM alpine:3.7
2020-08-10 14:44:46 <Cogitri> Well, it's not like anything breaks with 3.7 or they get any warning, so unless someone in the project knows when alpine releases go EOL they wouldn't know how insecure their release is
2020-08-10 14:45:13 <Cogitri> And no one reads logs from container builds unless they fail, so I'm not sure what we can do here to improve the situation :/
2020-08-10 14:45:40 <maxice8> search 'FROM  alpine:3.7' on github and open issues I guess
2020-08-10 15:21:15 <benniej> hi everyone!
2020-08-10 15:30:58 <Cogitri> Hello 👋
2020-08-10 15:31:31 <benniej> what would be the easiest way to mariadb-connector-c
2020-08-10 15:32:10 <benniej> *replace mariadb-connector-c
2020-08-10 15:32:13 <benniej> ??
2020-08-10 15:32:51 <Cogitri> wdym?
2020-08-10 15:34:24 <benniej> Want to replace to test.  Have been getting "Segmentation fault (core dumped)" since perl-dbd-mysql was rebuilt against mariadb-connector-c
2020-08-10 16:00:48 <Cogitri> I guess revert https://gitlab.alpinelinux.org/alpine/aports/-/commit/0321de17865bb60181e25fe16b3f43488a269bfd
2020-08-10 16:16:36 <benniej> yup has been happening since Alpine 3.8.  Noticed it when I was trying to run "rt-setup-database --action init" from the rt4 package
2020-08-10 16:28:07 <benniej> still pulls in mariadb-connector-c-dev from mariadb-dev
2020-08-10 16:28:43 <Cogitri> Would be good if you opened an issue with a backtrace
2020-08-10 16:33:56 <ncopa> a05c8ecf39e0efd4d22c2681fd5a99e4a8c1b80e
2020-08-10 16:34:47 <ncopa> maxice8: this commit is bad: https://git.alpinelinux.org/aports/commit/?id=a05c8ecf
2020-08-10 16:35:22 <ncopa> i wonder if the ci returns success if the APKBUILD does not contain valid shell code
2020-08-10 16:39:46 <PureTryOut[m]> ikke: seems to be broken for me too. Could you make an issue and assign me to it?
2020-08-10 16:41:56 <maxice8> sorry, seems like i mismerged a few backports
2020-08-10 16:45:37 <Hello71> I feel like git should have a builtin warning for committing merge markers
2020-08-10 16:47:34 <maxice8> can probably add it to githooks
2020-08-10 16:47:46 <maxice8> grep '^={,n}'
2020-08-10 16:49:42 <maxice8> or even have the githook source the shell file, it will return 2
2020-08-10 17:00:50 <Hello71> well yes but I'm saying it should be for all git repos
2020-08-10 17:01:57 <benniej> Cogitri: will do that. Tried mailing it to alpine@bugs.alpinelinux.org back in April but that did not work.  Will try the Web UI
2020-08-10 17:02:03 <maxice8> I can't make that happen
2020-08-10 17:05:05 <ikke> PureTryOut[m]: alright
2020-08-10 18:27:13 <ikke> maxice8: ping
2020-08-10 18:27:18 <maxice8> pong
2020-08-10 18:28:26 <ikke> Trying to add a new lint to apkbuild-lint (I've opened an issue for it), but wondering how we can verify things for example only in the source variable. grep has no multiline matching afaik
2020-08-10 18:28:53 <maxice8> You can use sed to extract the lines
2020-08-10 18:29:09 <maxice8> sed -n '^source="/,/"/p'
2020-08-10 18:29:26 <maxice8> we are reached the limits of what shell is nice for
2020-08-10 18:29:52 <ikke> yup
2020-08-10 18:30:10 <ikke> hmm, I see that you are iterating over source in one test, that's even simpler
2020-08-10 18:30:38 <maxice8> that expands variables
2020-08-10 18:30:49 <maxice8> so if you want to check that a $var is being mis-used then that is not the way
2020-08-10 18:31:27 <ikke> right, but that's not an issue for what I'm testing
2020-08-10 18:31:56 <maxice8> that that is a way
2020-08-10 18:32:25 <ikke> I want to test if there are patches directly from github
2020-08-10 18:34:49 <ikke> seems you forgot to document some linters
2020-08-10 18:35:16 <ikke> last one in man 5 alint is AL53, last one in source is AL58
2020-08-10 18:37:02 <maxice8> huh
2020-08-10 18:37:23 <maxice8> I see AL58 documented in alint.5.scd
2020-08-10 18:37:27 <maxice8> deprecated-packages
2020-08-10 18:38:38 <maxice8> guess I didn't release a new version
2020-08-10 18:38:50 <ikke> I'm checking the source
2020-08-10 18:38:54 <ikke> not the package
2020-08-10 18:39:08 <ikke> aha, not in order, ok
2020-08-10 18:39:16 <ikke> my bad
2020-08-10 18:39:30 <maxice8> /
2020-08-10 18:44:01 <ikke> ag --no-filename -o '\[AL\d+\]' | sort -u --version-sort :P
2020-08-10 18:49:40 <ikke> but iterating over source makes it hard to get the line number :(
2020-08-10 19:31:56 <maxice8> I did that
2020-08-10 19:32:01 <maxice8> it isn't pretty
2020-08-10 19:32:12 <maxice8> i just asked cat -n to print all line numbers
2020-08-10 19:32:31 <maxice8> yes, it is as criminal as it sounds
2020-08-10 19:33:13 <maxice8> see superfluous_cd_builddr() specially line 297
2020-08-10 19:35:30 <c705> .quit
2020-08-10 20:34:32 <timlegge> when you get >>> WARNING: perl-sereal-decoder*: Redundant /usr/lib in rpath found is it appropriate to chrpath -d "$builddir/blib/arch/auto/Sereal/Decoder/Decoder.so"
2020-08-10 20:34:55 <timlegge> I've done that in some APKBUILD files but forgotten in others
2020-08-10 20:38:50 <Cogitri> I usually don't do anything about that warning
2020-08-10 21:54:14 <timlegge> thanks Cogitri Ihave noticed packages getting accepted either way so I was not sure if any action is necessary
2020-08-10 21:58:50 <Cogitri> I think we should either remove the warning or have apk automatically remove the RPATH IMHO
2020-08-10 21:59:00 <Cogitri> Because the current warning is a bit useless
2020-08-11 00:31:06 <timlegge> ncopa mps !11299 and  !11298 for the new release of www-mechanize-cached to fix  https://github.com/metacpan/metacpan-client/issues/103
2020-08-11 05:46:03 <ikke> Cogitri: vala has a test faiure on all arches
2020-08-11 05:49:24 <maxice8> huh
2020-08-11 05:50:44 <ikke> core dump
2020-08-11 05:51:11 <ikke> ERROR:/home/buildozer/aports/main/vala/src/vala-0.48.9/tests/_test/control_flow_bug736774_2.c:68:_vala_main: assertion failed: (keep != "test")
2020-08-11 05:55:52 <Cogitri> Huh, didn't it pass on CI?
2020-08-11 06:12:14 <Cogitri> Ah, seems like it didn't, looking into it, thanks dor the notification
2020-08-11 06:43:18 <Cogitri> Seems like the old version (0.48.8) fails tests too
2020-08-11 06:43:22 <mps> timlegge: looks like some already merged them. thank you for care and work
2020-08-11 06:44:03 <Cogitri> And Vala 0.48.9 works on 3.12, so something about our edge is broken/Vala with new packages 🤔
2020-08-11 06:45:30 <mps> s/some/someone/
2020-08-11 06:45:31 <alpine-meetbot> mps meant to say: timlegge: looks like someone already merged them. thank you for care and work
2020-08-11 06:45:50 <mps> meh, I'm not yet awaken
2020-08-11 11:02:08 <hc-hmk> I see that LibreSSL is in the alpine repos. How feasable is it to replace OpenSSL with LibreSSL for the entire system?
2020-08-11 11:03:08 <ikke> hc-hmk: You need to rebuild everything to link to libressl, then you need to fix API breakages that libressl introduced
2020-08-11 11:03:24 <hc-hmk> Yeah, that's what I thought.
2020-08-11 11:03:27 <Cogitri> It's not going to be fun
2020-08-11 11:03:43 <ikke> There is a reason we switched back to openssl
2020-08-11 11:04:06 <hc-hmk> I was very impressed by OPNSense and their success in replacing openssl.
2020-08-11 11:06:38 <ikke> I would imagine that opensense scope is a lot smaller
2020-08-11 11:07:29 <hc-hmk> Considering that it's not a general purpose system, I'd agree. They do have to support nginx, squid etc, so it's not exactly trivial.
2020-08-11 11:10:25 <Cogitri> Does OPNSense also use libressl portable?
2020-08-11 11:10:39 <Cogitri> There are some rather unnice limitations to libressl portable
2020-08-11 11:14:44 <hc-hmk> I honestly have no clue.
2020-08-11 11:25:37 <ncopa> hi, finally got my machine working (i think)
2020-08-11 11:25:54 <ncopa> replaced my i7 desktop with a i9 :)
2020-08-11 11:26:15 <clandmeter> oh no, intel the sinking ship ;-)
2020-08-11 11:26:51 <clandmeter> using intel gfx?
2020-08-11 11:27:15 <ncopa> yes. that was the main reason why i went for the sinking chip
2020-08-11 11:27:28 <clandmeter> hehe
2020-08-11 11:27:32 <clandmeter> nice wording
2020-08-11 11:28:10 <ncopa> i seriously considered amd ryzen, but it requires a graphics card in addition, which would mean a bit more expensive and 2 more fans
2020-08-11 11:28:17 <clandmeter> so i guess there is no proper oss driver implementation for amd?
2020-08-11 11:28:18 <ncopa> and i want it quiet
2020-08-11 11:28:41 <ncopa> i think the amd radeon should have pretty good drivers
2020-08-11 11:28:46 <ncopa> opensource
2020-08-11 11:29:17 <clandmeter> it needs extra fans?
2020-08-11 11:29:35 <ncopa> a radeon graphics card yes.
2020-08-11 11:29:48 <ncopa> they all comes with a fan
2020-08-11 11:29:53 <ncopa> or two
2020-08-11 11:29:54 <Cogitri> Yes, unfortunately there aren't really good passively cooled AMD cards :/
2020-08-11 11:29:56 <insep_> <ncopa "i think the amd radeon should ha"> it does, work even better than proprietary ones
2020-08-11 11:30:10 <insep_> because proprietary ones don't work :D
2020-08-11 11:30:14 <ncopa> :D
2020-08-11 11:30:43 <Cogitri> I think the proprietary drivers tend to be a bit better at OpenCL still
2020-08-11 11:30:49 <ncopa> i may get a radeon card later
2020-08-11 11:30:52 <Cogitri> But I guess that'll change once ROCm gets into shape
2020-08-11 11:31:06 <ncopa> but now it works without
2020-08-11 11:31:29 <Cogitri> Also, sorry to interfere, but do we have an official stance on berkeley DB now? Are we going to drop it?
2020-08-11 11:31:35 <Cogitri> Asking for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569#note_107403
2020-08-11 11:31:37 <ncopa> if we can
2020-08-11 11:31:57 <Cogitri> I guess introducing new packages which need it probably won't fly?
2020-08-11 11:32:19 <ncopa> hum
2020-08-11 11:32:34 <ncopa> would prefer avoid if possible
2020-08-11 11:34:42 <Cogitri> Same, but I'd be very helpful if we had some statement somewhere which I can link :)
2020-08-11 11:35:34 <clandmeter> ncopa: how many cores does the i9 have?
2020-08-11 11:35:54 <ncopa> 10
2020-08-11 11:36:34 <mps> Cogitri: db removal for now is 'blocked' by postfix, iiuc
2020-08-11 11:36:42 <ikke> Cogitri: not an official statement, but: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0
2020-08-11 11:36:56 <ncopa> i suspect we cannot get rid of it
2020-08-11 11:37:33 <mps> if we can decide what to do with postfix we probably can remove db for 3.13
2020-08-11 11:39:17 <Cogitri> ikke: Alright, I guess I'll reply with that, but it'd be nice if we had a tracker issue for it
2020-08-11 11:40:17 <mps> Cogitri: I think we should not 'accept' new pkgs which depends on bdb
2020-08-11 11:42:47 <Cogitri> Probably, but I'd prefer to have something written down I can point contributors to so I don't say wrong things
2020-08-11 11:43:20 <mps> write one :)
2020-08-11 11:45:32 <mps> when we are here, I started to make trimmed down variants of some pkgs for me local use
2020-08-11 11:45:57 <mps> mpv, firefox, vim, mesa is planned
2020-08-11 11:46:32 <mps> question, would that be acceptable for alpine?
2020-08-11 11:47:36 <mps> asking because it is more work needed for them if they be in aports, than making it locally which is not complicated task
2020-08-11 11:48:05 <mps> s/making it/making them/
2020-08-11 11:48:05 <alpine-meetbot> mps meant to say: asking because it is more work needed for them if they be in aports, than making them locally which is not complicated task
2020-08-11 11:50:59 <ncopa> i dont think we want maintain 2 different versions of those packages
2020-08-11 11:53:25 <Cogitri> +1, if we want something like that we should have something built-in in abuild
2020-08-11 11:53:37 <Cogitri> Otherwise it'll be easy to forget to update one of the packages
2020-08-11 11:54:28 <mps> we already have pkgs where two variants are built, can't remember from head which ones
2020-08-11 11:54:42 <ncopa> we want avoid that if possible
2020-08-11 11:55:25 <Thermi> Cogitri: Regarding !8569, we're okay with getting the patches upstream, but we'd like to continue with the APKBUILD and avoid delays if at all possible.
2020-08-11 11:55:38 <mps> personally I prefer to maintain locally, but from time to time users ask for trimmed down variants
2020-08-11 11:55:46 <Cogitri> We have some -elogind variants for some pkgs already
2020-08-11 11:56:09 <Cogitri> Thermi: Well, if you commit to getting those upstream that's fine by me
2020-08-11 11:56:21 <Cogitri> But I had quite a lot of comments on the last review round
2020-08-11 11:56:40 <Cogitri> And for the future, it'd be much appreciated if MRs were a bit more split up, reviewing that was a bit brutal
2020-08-11 11:57:43 <insep_> how about splitting those minimal variants to subpackages?
2020-08-11 11:57:57 <insep_> iirc emacs package does something similar
2020-08-11 11:57:59 <Thermi> Cogitri: Yes, I saw those and I am working on them. I want to clarify that the patches are so musl specific, that it's unlikely they'll be accepted or it will take some time for them to be done. I understood your comments about the patches as such that you'd be unwilling to merge the packages until the patches were not necessary anymore.
2020-08-11 11:59:06 <mps> insep_: yes, that is option I have in mind
2020-08-11 11:59:36 <Cogitri> Thermi: Ah no, but if patches aren't upstream those need to be marked explicitly, so we know their status
2020-08-11 11:59:53 <Cogitri> All the patches contain descriptions, so that's nice already :)
2020-08-11 12:00:15 <Cogitri> 
ACTION dislikes working with mystery patches without any description a lot

2020-08-11 12:00:22 <Cogitri> Always fun when those don't apply anymore
2020-08-11 12:00:54 <Thermi> Cogitri: Alright, I get it now. :) Thank you.
2020-08-11 12:01:42 <Thermi> Cogitri: about berkeley db: Some parts/tools of kopano require bsddb3 and hence berkeley db, so I'd need to rewrite those. What about postfix, what do you want to do about its berkeley DB dependent stuff?
2020-08-11 12:02:04 <ikke> Thermi: that's the tricky part
2020-08-11 12:03:55 <mps> Thermi: postfix, replace with something other which is acceptable
2020-08-11 12:04:31 <mps> sooner or later this will come to us
2020-08-11 12:05:11 <ikke> our version of bdb accrues more and more vulnerabilities
2020-08-11 12:05:33 <ikke> with no good way to fix them (or even know whether the vulnerabilities even apply)
2020-08-11 12:05:35 <Thermi> mps: the internal postfix dbs are all berkeley dbs by default. You'd need to integrate a completely new db.
2020-08-11 12:05:44 <Thermi> (In the C code)
2020-08-11 12:06:35 <mps> ldb has compatibility layer, iirc
2020-08-11 12:07:02 <mps> though hashing will not work
2020-08-11 12:07:29 <mps> didn't looked details long time so I'm not sure in current state
2020-08-11 12:14:10 <mps> Thermi: for test I built postfix apk without bdb few weeks ago, but didn't installed. just wanted to check if build works
2020-08-11 12:47:36 <Thermi> mps: the critical question is if postfix still works without bdb
2020-08-11 12:50:30 <mps> Thermi: it works, but old DBs on already system have to be converted to some other format
2020-08-11 12:50:52 <mps> (I would like to use sqlite, but eh ...)
2020-08-11 12:51:40 <Thermi> is bdb mt safe?
2020-08-11 12:51:54 <Thermi> sqlite isn't, so there's that.
2020-08-11 12:51:59 <mps> I don't know
2020-08-11 12:52:19 <Thermi> wait that was wrong
2020-08-11 12:56:29 <hc-hmk> ulimit reveals that soft limit for open files is 1024 and hard is 4096. How do I raise this in a persistent manner? /etc/security/limits.conf is not a thing on alpine.
2020-08-11 12:57:06 <ikke> afaik there is no way to do it persitently for normal users
2020-08-11 12:57:40 <hc-hmk> I'm not sure what you mean by 'normal users'
2020-08-11 12:57:46 <ikke> non-root :)
2020-08-11 12:58:12 <ikke> You inherrit the ulimits from the parent process, and there is nothing in that chain that allows you to raise it
2020-08-11 12:58:26 <hc-hmk> Oh, that's not an issue. I was hoping to set a value in a config file at buildtime.
2020-08-11 12:58:40 <ikke> Is it for a service?
2020-08-11 12:59:47 <ikke> openrc has settings to set rc_ulimit per service
2020-08-11 13:00:28 <hc-hmk> I was hoping for a system-wide setting. I guess I could raise the limit for docker daemon, but that seems dirty.
2020-08-11 13:00:38 <ikke> ulimit is not a system wide setting
2020-08-11 13:00:56 <Cogitri> I think usually it's applied per user via PAM
2020-08-11 13:01:06 <ikke> yes, that's how it is done on other systems
2020-08-11 13:01:12 <ikke> (PAM is what reading limits.conf)
2020-08-11 13:01:14 <Cogitri> But that's currently broken on Alpine because our PAM setup is a bit weird in general apparently
2020-08-11 13:01:29 <ikke> well, it requires login to use pam iirc
2020-08-11 13:01:54 <hc-hmk> Oh, fair
2020-08-11 13:02:39 <ikke> processes inherit the limits from the process that spawns it, and it requries root or CAP_SYS_RESOURCE to be able to raise hard limits
2020-08-11 13:03:03 <ikke> And I haven't found a sysctl setting or something like that to specify the default ulimits either
2020-08-11 13:03:30 <hc-hmk> Me neither, first thing I looked at was sysctl.conf
2020-08-11 13:04:32 <mps> iirc, it could be set in shell rc file
2020-08-11 13:04:48 <hc-hmk> Internet says /etc/rc.conf
2020-08-11 13:05:01 <ikke> hc-hmk: that's for openrc services, and it recommends to set it per service
2020-08-11 13:07:57 <ikke> hc-hmk: try: cat /proc/1/limits
2020-08-11 13:08:17 <ikke> You see hard limits already set to 4096 for max open files
2020-08-11 13:08:27 <ikke> so any process spawned from init inherits that
2020-08-11 13:08:30 <hc-hmk> Actually, the root cause I'm trying to fix is that raising docker containers is EXTREMELY slow. Like unreasonably, super slow. Several minutes. iotop reveals basically no IO. 80% memory is unused. CPU utilization is 10%. Network is unrelated. The only thing I found to be odd is that open file handles is greater than soft ulimit.
2020-08-11 13:08:49 <ikke> raising docker containers?
2020-08-11 13:09:27 <ikke> We user docker extensively at Alpine, and we haven't noticed any slowness
2020-08-11 13:10:27 <hc-hmk> Yup. Calling "docker-compose up" is painfully slow. The containers aren't that complex either. And it used to be fast a few months ago, but now it isn't. This is across multiple machines on bare metal. I'm unsure what has gone wrong.
2020-08-11 13:12:54 <hc-hmk> If no resources seem to be exhausted, where do I look? CPU, RAM, NET and IO are fine.
2020-08-11 13:13:11 <ikke> strace maybe?
2020-08-11 13:16:00 <hc-hmk> I'm completely unfamiliar with strace, but thank you for the hint. The only debuggers I've used are gdb and the one bundled in jetbrains.
2020-08-11 13:16:29 <ikke> strace shows you the systemcalls that a process executes
2020-08-11 13:23:20 <hc-hmk> I'll check it out tomorrow. It's too late for wild debug sessions now. Thanks
2020-08-11 14:30:58 <hc-hmk> Does anyone here have experience with cgroups and docker? Starting a container with "--net=host" is instant for me, but removing that argument increases that time to around 30 sec. This makes me think that creating a cgroup namespace for that containers networking is somehow broken. ikke do you have any suggestions?
2020-08-11 14:31:38 <Thermi> It's not cgroups, it's network namespaces
2020-08-11 14:32:01 <Thermi> Check system logs to see what docker does
2020-08-11 14:32:11 <hc-hmk> Oh, I didn't know there was a difference. I'll have a look hold on.
2020-08-11 14:38:57 <hc-hmk> I'm an idiot for not reading the logs closer. It's timing out waiting for registry-1.docker.io. Unfortunately that's unavailable because the thing is on a network without internet access. How in the world do I disable docker phoning home on each container startup?
2020-08-11 14:44:59 <hc-hmk> Noo, hold on that can't be it. Disregard that.
2020-08-11 14:45:52 <clandmeter> hc-hmk: this is not a support channel. we have #alpine-linux for such things.
2020-08-11 14:48:04 <hc-hmk> Sorry, most of my other questions (aside from today) has been about actual development stuff, such as the canutils package. I'll join #alpine-linux instead.
2020-08-11 14:50:19 <clandmeter> we are not that strict, so we dont shoot immediately.
2020-08-11 15:03:51 <kytart> hey, I'm building a subset of aports using buildrepo command. Any idea why my docker package says it's size is 0? In the same package in the official repo it's size is 4096. Because of this apk fetch doesn't work with my repo.
2020-08-11 15:04:47 <kytart> it doesn't contain anything because it's just a virtual parent package for other subpackages
2020-08-11 15:32:19 <kytart> in the abuild script there's this line "local size=$(du -sk | awk '{print $1 * 1024}')"
2020-08-11 15:32:54 <kytart> that means in the official build there was 4  bytes of something but what?
2020-08-11 15:34:27 <kytart> I downloaded the package and looked inside and there's nothing except for .dummy file with size 0
2020-08-11 16:12:49 <ikke> kytart: if you look at the apkbuild, it only creates the root of the package
2020-08-11 16:13:07 <Ganwell> kytart: did you call buildrepo directly on your workstation? maybe you had a different version of du (from coreutils) or awk (from gawk) installed.
2020-08-11 16:13:33 <kytart> @ikke I know but somehow the size is not 0 in the official apk
2020-08-11 16:13:51 <ikke> kytart: understood, not sure where the difference is coming from
2020-08-11 16:14:15 <kytart> @Ganwell I did it in docker container. I can investigate what kind of du I have in that environment
2020-08-11 16:16:06 <Ganwell> kytart: in that case there is no need, a fresh docker-container has only busybox installed.
2020-08-11 16:16:35 <kytart> I have some other deps there
2020-08-11 16:17:12 <Ganwell> kytart: "apk info" should give you a list of all currently installed packages.
2020-08-11 16:18:12 <kytart> both du and awk are busybox
2020-08-11 16:19:02 <kytart> ah yes but coreutils is docker's dependency so it installs it during the build
2020-08-11 16:19:38 <Ganwell> kytart: in that case the alpine-builder would have had installed coreutils as well.
2020-08-11 16:20:20 <kytart> true
2020-08-11 16:21:25 <kytart> alpine-builder runs in docker too, right?
2020-08-11 16:21:30 <ikke> lxc
2020-08-11 16:22:02 <kytart> right
2020-08-11 16:22:49 <Ganwell> kytart: maybe because it uses a different file-system or file-system-container-driver
2020-08-11 16:23:19 <ikke> Our CI system uses docker
2020-08-11 16:27:18 <kytart> the file system type is xfs
2020-08-11 16:27:21 <kytart> it's on AWS
2020-08-11 16:31:28 <ikke> kytart: did you try to verify the ouput of du -sk?
2020-08-11 16:31:30 <ikke> on the pkgdir
2020-08-11 16:35:12 <kytart> I'll try
2020-08-11 17:19:43 <kytart> @ikke found it! Due to some black magic the same directory has 0 on xfs but 4 on ext4
2020-08-11 17:20:00 <kytart> I mean from "du -ks"
2020-08-11 17:20:36 <kytart> I guess I'll have to switch to ext4
2020-08-11 17:20:44 <kytart> but still it seams like a bug
2020-08-11 17:24:02 <ikke> kytart: aha, interesting
2020-08-11 17:24:27 <ikke> You see here that there is already some special casing for some filesystems: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1042
2020-08-11 17:24:42 <ikke> can you try to run sync and see if that makes a difference?
2020-08-11 17:25:36 <afontain_> there's `du --apparent-size`?
2020-08-11 17:25:59 <ikke> afontain_: does bb du has that?
2020-08-11 17:26:10 <afontain_> gnu one has it, at least
2020-08-11 17:26:26 <afontain_> that person mentionned gnu, I think?
2020-08-11 17:26:35 <ikke> afontain_: this is for abuild
2020-08-11 17:26:48 <afontain_> :-/
2020-08-11 18:05:38 <kytart> for now I started migrating to ext4
2020-08-11 19:19:00 <crosbymichael> is there a reason why the linux-lts pkg not honor MAKEFLAGS and has -j1 set?
2020-08-11 19:19:08 <crosbymichael> was looking through the changelog
2020-08-11 19:20:28 <dalias> maybe at one time someone thought linux had a bug in parallel build..?
2020-08-11 19:21:06 <dalias> i've always used -j4 for linux and linux is one of the most useful places to use it (because it's actually well-factored into files not C++ template idiocy where each g++ invocation needs 15 GB)
2020-08-11 19:21:14 <ikke> I only see -j1 used in certain steps
2020-08-11 19:22:04 <ikke> I don't see it provided in the build phase
2020-08-11 19:22:22 <dalias> ah
2020-08-11 19:22:50 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-lts/APKBUILD#L130
2020-08-11 19:24:04 <crosbymichael> humm, maybe MAKEFLAGS isn't propagating for me, for some odd reason
2020-08-11 21:50:30 <timlegge> !11337 removes the now unused patch from perl-metacpan-client.  I forgot to remove it - this does not increment the pkgver since the patch was unsued anyway let me know if that is an issue
2020-08-11 21:51:00 <ikke> no, these kinds of things don't need to increase pkgrel
2020-08-11 21:51:28 <ikke> eg, we don't need to force the package to be rebuilt
2020-08-11 21:56:08 <timlegge> thanks ikke
2020-08-11 21:59:12 <ikke> you're welcome
2020-08-12 06:28:20 <mps> https://fedoraproject.org/wiki/User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora
2020-08-12 06:29:02 <mps> summary of fedora bdb removal status of packages
2020-08-12 07:56:23 <tmlind> hmm looks like tmux has started segfaulting when starting at least on armv7, x86_64 is working
2020-08-12 07:58:11 <tmlind> oh it's not a segfault, the error is server exited unexpectedly
2020-08-12 08:09:23 <mps> it works quite fine on my armv7 servers and workstation
2020-08-12 08:25:30 <tmlind> was working for years for me.. works for you on edge?
2020-08-12 08:35:04 <mps> heh, yesterday I reformatted sd card on my testing arm32 SBC, need to test old release
2020-08-12 08:35:30 <mps> but in lxc edge it works fine
2020-08-12 08:36:33 <tmlind> ok weird, tmux broke for me yesterday or day before
2020-08-12 08:38:04 <mps> can't test now
2020-08-12 08:38:29 <mps> hmm qemu 5.1.0 got avr, >>> ERROR: qemu-img*: Please create a subpackage for qemu-system-avr
2020-08-12 08:39:20 <tmlind> mps: ok, does firefox and chromium work for you on armv7? those have been broken for me for a while now, with unacclerated xorg
2020-08-12 08:40:02 <tmlind> surf and netsurf have no issues :)
2020-08-12 08:41:44 <mps> tmlind: firefox works on armv7 stable
2020-08-12 08:42:03 <mps> didn't tried chromium
2020-08-12 08:42:51 <tmlind> mps: ok
2020-08-12 08:43:10 <mps> firefox and chromium don't work on edge even on other arches, afaik
2020-08-12 08:43:49 <tmlind> mps: they work for me on edge on x86_64
2020-08-12 08:44:55 <tmlind> i guess i need to try tmux in qemu armv7 when i can, bbl
2020-08-12 08:45:11 <mps> did you upgraded musl to 1.2.1
2020-08-12 08:45:27 <hc-hmk> ncopa you're the maintainer on packages busybox and busybox-extras. Is there a reason why it does not contain the patch applet? "busybox --list | grep patch" returns nothing.
2020-08-12 08:46:36 <tmlind> mps: need to check later, i did force reinstall all packages over armhf after armv7 was available few years ago.
2020-08-12 08:47:27 <tmlind> so certainly i might have still some weird issues :) anyways, later
2020-08-12 08:51:15 <mps> hc-hmk:
2020-08-12 08:51:15 <mps> #11817
2020-08-12 08:54:58 <hc-hmk> Aw crap, I was hoping there was no good reason for removing it, and you just kinda forgot to include it. Do you have any contact with the busybox maintainers? It should honestly be fixed at the source.
2020-08-12 08:55:54 <Cogitri> That'd be nice, but I think for that to work someone will have to invest the time it'll take to get fuzzing support into busybox
2020-08-12 08:56:04 <Cogitri> And I don't think that'll be too easy
2020-08-12 08:58:23 <hc-hmk> I'm not sure I agree with fuzzing being necessary to test if a patch is applied correctly, but it would be an improvement. I'll shoot them an email to ask their opinion on fixing it.
2020-08-12 08:59:24 <Ariadne> the problem is that it only supports very basic scenarios.
2020-08-12 08:59:28 <Ariadne> we will not be reenabling it
2020-08-12 09:00:24 <Cogitri> Yup, in its current state the patch applet is broken for most usecases
2020-08-12 09:00:32 <hc-hmk> I read your comment, and I understand that you wont be reenabling it as-is. If the maintainers improve the patch applet, that might change.
2020-08-12 09:00:56 <Ariadne> the applet will need to be improved to the point that it is on par with other patch implementations
2020-08-12 09:01:05 <Ariadne> i find the likelihood of this happening to be very minimal
2020-08-12 09:01:26 <hc-hmk> ¯\_(ツ)_/¯
2020-08-12 09:01:34 <Ariadne> some "minor" improvement will not be sufficient
2020-08-12 09:01:56 <Ariadne> it will need to be able to build all packages in alpine
2020-08-12 09:02:13 <Ariadne> now, if you show me a busybox patch that can do that, i will be fine with shipping it
2020-08-12 09:02:20 <Ariadne> because then nobody will ever complain
2020-08-12 09:03:21 <Ariadne> but in general, busybox is awful code and we are trying to reduce the amount of applets we ship in busybox
2020-08-12 09:03:30 <Ariadne> replacing them with higher quality (but still compact) implementations
2020-08-12 09:05:46 <Ariadne> o k
2020-08-12 09:06:01 <Ariadne> i see matrix is demonstrating that they suck yet again
2020-08-12 09:06:02 <hc-hmk> Honestly, any solution that provides /usr/bin/patch in alpine-base would be wonderful
2020-08-12 09:06:10 <ikke> ouch
2020-08-12 09:06:24 <Ariadne> i'm not wrong :D
2020-08-12 09:06:50 <mps> hc-hmk: apk add patch
2020-08-12 09:06:58 <Ariadne> hc-hmk: i find it unlikely to happen.  just `apk add patch` if you need it
2020-08-12 09:07:47 <Ariadne> we were not able to find consensus on making gnu patch a dependency of alpine-base
2020-08-12 09:08:04 <Ariadne> if you read the bug, the general vibe is that not enough people use patch to make it worthwhile
2020-08-12 09:08:14 <mps> it is ok in deps in alpine-sdk
2020-08-12 09:08:31 <mps> I think it is not needed in alpine-base
2020-08-12 09:08:31 <Ariadne> patch is already a dep of build-base anyway
2020-08-12 09:08:52 <hc-hmk> I did already, no worries. My general feeling about this is that you guys are kinda religious about this.
2020-08-12 09:09:12 <ikke> hc-hmk: It's a matter of trade-offs
2020-08-12 09:09:25 <ikke> and making choices
2020-08-12 09:09:51 <Ariadne> religious, no
2020-08-12 09:10:11 <Ariadne> just want to keep alpine-base minimalized to programs people typically use
2020-08-12 09:10:12 <hc-hmk> I get that. There's just a whole bunch of things downstream that needs patch. Anyways, I'm fine with stopping the discussion as I got my answer :)
2020-08-12 09:10:16 <Ariadne> patch didn't make the threshold
2020-08-12 09:10:29 <Ariadne> and busybox patch is too broken to ship to users
2020-08-12 09:10:51 <Ariadne> we used to get tons of complaints about it, most of which stopped when alpine-sdk started requiring real patch in 2015
2020-08-12 09:12:24 <mps> only not sure should I close issue report or keep it open for those who will come with same question as hc-hmk
2020-08-12 09:12:41 <Ariadne> i think we should keep it open until some docs are written
2020-08-12 09:12:47 <Ariadne> this is why we have not closed it yet
2020-08-12 09:14:51 <Ariadne> in other news, $dayjob is working on a livepatch service for alpine kernels
2020-08-12 09:17:10 <mps> good news, but I'm reading about livepatch for years. hope finally something will work
2020-08-12 10:39:36 <tmlind> mps: yes i have musl-1.2.1
2020-08-12 11:14:09 <mps> tmlind: ime, firefox with musl 1.2.1 doesn't play video/audio
2020-08-12 11:22:06 <tmlind> mps: my armv7 machine is too slow for video with no acceleration.. have not tried audio
2020-08-12 11:26:08 <mps> tmlind: hmm, looks like I was ambiguous, firefox works fine and play A/V on armv7 but not if musl 1.2.1 installed
2020-08-12 11:37:33 <tmlind> mps: for me firefox starts, but after typing some url it dies with illegal instruction
2020-08-12 11:38:06 <tmlind> mps: i'm pretty sure it worked for several months earlier this year
2020-08-12 11:43:06 <mps> tmlind: yes, it works fine with musl 1.2.0 and earlier
2020-08-12 11:45:19 <tmlind> mps: so i removed firefox, tried reinstalling it and now see libffi-3.3-r2 conflicts libffi-3.2.1-r6
2020-08-12 11:46:51 <mps> tmlind: try 'apk fix'
2020-08-12 11:48:07 <tmlind> mps: tried did not do anything, removed py-gobject and now a bunch of stuff is getting updated with apk upgrade
2020-08-12 11:48:56 <tmlind> mps: hmm maybe py-gobject has some python2 stuff left or something?
2020-08-12 11:52:17 <mps> tmlind: I don't know about current status of python pkgs in alpine
2020-08-12 11:54:10 <tmlind> mps: not sure what py-gobject was holding back.. but now with that gone, firefox works for me on edge on armv7 :)
2020-08-12 11:56:32 <tmlind> tmux still fails with SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x228b}
2020-08-12 11:56:55 <Cogitri> We'd need a backtrace to say anything useful about that
2020-08-12 11:59:30 <tmlind> Cogitri: #0  0xb6fa8618 in _dlstart () from /lib/ld-musl-armhf.so.1
2020-08-12 11:59:57 <tmlind> #1  0x00000000 in ?? ()
2020-08-12 12:00:00 <tmlind> that's it
2020-08-12 12:03:22 <Cogitri> Install musl-dbg please
2020-08-12 12:03:44 <Cogitri> And rebuild tmux, but add a `$pkgname-dbg` subpkg
2020-08-12 12:03:51 <Cogitri> And install that too (and the rebuilt tmux)
2020-08-12 12:03:56 <tmlind> ok
2020-08-12 12:03:57 <Cogitri> Then the backtrace should be useful
2020-08-12 12:15:03 <tmlind> Cogitri: hmm the rebuilt tmux works just fine
2020-08-12 12:15:19 <Cogitri> Huh
2020-08-12 12:16:43 <tmlind> Cogitri: also reinstalling tmux also works
2020-08-12 12:17:24 <tmlind> maybe file system corruption.. have not seen any other issues though
2020-08-12 12:17:55 <Cogitri> I guess it's impossible to tell if you have corruption unless you use btrFS or ZFS
2020-08-12 12:19:33 <tmlind> yeah on ext4 here
2020-08-12 12:22:17 <tmlind> Cogitri: reinstalling earlier tmux-3.1b-r0.648474d9.apk makes it fail again, installing tmux-3.1b-r0.77ad32cf.apk makes it work again
2020-08-12 12:25:06 <mps> huh, not sure how to reset BAD Signature on CI, https://gitlab.alpinelinux.org/mps/aports/-/jobs/184637#L287
2020-08-12 12:25:22 <ikke> curl -XPURGE <url>
2020-08-12 12:25:38 <mps> yes, but what is url?
2020-08-12 12:25:56 <mps> how to find url in CI log
2020-08-12 12:26:05 <ikke> it's the full url to the apk
2020-08-12 12:26:46 <mps> yes
2020-08-12 12:27:18 <ikke> https://dl-cdn.alpinelinux.org/alpine/edge/community/armv7/libpulse-mainloop-glib-13.0-r10.apk
2020-08-12 12:27:20 <mps> but where it is in log,fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/armv7
2020-08-12 12:28:10 <mps> looks like had to look at top of log
2020-08-12 12:28:19 <mps> ikke: thanks
2020-08-12 12:28:28 <ikke> I just look up the package name on the mirror
2020-08-12 12:28:33 <ikke> https://dl-cdn.alpinelinux.org/alpine/edge/community/armv7/
2020-08-12 12:29:33 <ncopa> \o/ finally, i think libvirtd is no longer deadlocking (unless qemu does)
2020-08-12 12:30:00 <ikke> ncopa: yea, I've heard people report here that it was fixed
2020-08-12 12:30:10 <ncopa> no, its not
2020-08-12 12:30:24 <ncopa> i have spent all day so far trying to fix it
2020-08-12 12:30:24 <mps> ncopa: as I wrote on #musl, qemu works on aarch64 with musl 1.2.1
2020-08-12 12:31:01 <mps> though I start it from CLI, don't use libvirt
2020-08-12 12:31:13 <ncopa> qemu is different story. i didnt try solve it. i once saw libvirt deadlock due to a qemu child deadlocked
2020-08-12 12:31:21 <ikke> ncopa: hmm, ok. They reported at least that they no longer had the problems they were facing
2020-08-12 12:31:42 <ncopa> fcolista tried to fix it with 740a5cf92a47b2ec90a429209f270426ed0fa28c
2020-08-12 12:31:53 <ikke> yes, based on the patch from dalias
2020-08-12 12:32:11 <ncopa> but it missed one point
2020-08-12 12:32:21 <ikke> aha, ok
2020-08-12 12:32:29 <ncopa> and it will leak fds potentially
2020-08-12 12:32:32 <fcolista> dalias, stated that it's an untested patch
2020-08-12 12:32:42 <ikke> yes, correct
2020-08-12 12:32:55 <fcolista> the issue is still open in gitlab on purpose
2020-08-12 12:33:13 <ikke> so we urged users to test it and give feedback
2020-08-12 12:33:29 <fcolista> right
2020-08-12 12:33:50 <fcolista> Especially because even if it's edge...is in main
2020-08-12 12:35:55 <tmlind> mps: looks like firefox keeps still crashing on armv7 for me, seems like if page is using javascript..
2020-08-12 12:41:11 <mps> how much RAM you have
2020-08-12 12:47:19 <ncopa> dalias: re libvirt, i could not find where virReportSystemError does malloc? I find it weird that system error reporting should do malloc. (how would you report out-of-memory if you need memory to report it?)
2020-08-12 13:00:48 <tmlind> mps: 1GB on this machine
2020-08-12 13:02:36 <mps> I think it is not enough for firefox, add more RAM or swap
2020-08-12 13:08:48 <tmlind> mps: not seeing anything oom related though
2020-08-12 13:18:24 <tmlind> mps: after nuking my old .mozilla firefox runs now
2020-08-12 13:29:39 <mps> tmlind: good you found cause. but I wouldn't run bloated software on low RAM machines
2020-08-12 13:42:44 <tmlind> mps: right, i mostly just use netsurf
2020-08-12 13:44:45 <wsinatra> fcolista: at least on my end the patch for libvirt seems to help
2020-08-12 13:45:07 <wsinatra> It might be a little rough but it moves the bar from inoperable -> functional again, which is huge
2020-08-12 13:46:27 <ikke> wsinatra: ncopa just pushed another fix
2020-08-12 13:51:04 <wsinatra> :D even more fixes? I love it
2020-08-12 13:51:45 <wsinatra> I need to do some testing on Win10 today, so I'll let you know if I see any issues post update. I imagine there's already been a decent bit of testing for this though
2020-08-12 13:51:55 <ikke> seems like ncopa replaced the first patch
2020-08-12 13:56:32 <fcolista> heh...qemu but is 1,5years old
2020-08-12 13:56:36 <fcolista> *bug
2020-08-12 13:56:42 <fcolista> https://bugs.launchpad.net/qemu/+bug/1813398
2020-08-12 13:59:10 <wsinatra> I like that it's "hard to reproduce" and then was decided to arbitrarily not be an issue anymore without any form of info verifying the fact
2020-08-12 14:02:56 <dalias> ncopa, its almost surely AS-unsafe
2020-08-12 14:03:11 <dalias> does it not use stdio?
2020-08-12 14:03:33 <dalias> also i removed the code that reset logging
2020-08-12 14:03:55 <dalias> so i figured trying to log with that removed could misbehave
2020-08-12 14:05:40 <ikke> current patch; https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/libvirt/libvirt-fork-exec-deadlock.patch
2020-08-12 14:24:25 <dalias> virBitmapNew looks unsafe
2020-08-12 14:25:07 <dalias> and the comment above is wrong
2020-08-12 14:25:38 <dalias> ah is this in the parent now?
2020-08-12 14:25:56 <dalias> i think it has a toctou if process changes its rlimit for fds
2020-08-12 14:26:14 <dalias> child should just use a safe method instead
2020-08-12 14:27:06 <dalias> also virCommandMassCloseGetFDsLinux itself would be toctou bug then
2020-08-12 14:59:52 <ncopa> yes, i moved the parsing of /proc and virBitmapNew to the parent
2020-08-12 15:01:03 <ncopa> the other idea I had was to simply loop over all fds and close those as a fallback for non glibc
2020-08-12 15:01:15 <ncopa> its slow but it should be safe
2020-08-12 15:01:37 <ncopa> i've tried to make something that can be upstreamable
2020-08-12 15:02:56 <ncopa> does musl stdio use malloc? as i understand its primarily malloc/free that causes problems for us
2020-08-12 15:03:34 <ncopa> i suppose the best thing would be to simply exec directly after the fork. I dont know why they need to do all the stuff they do before exec
2020-08-12 15:36:46 <wsinatra> anyone know a good way to deal with autoconf throwing bad substitution errors? I'm trying to build zangband, and have a patch to convert ${!FLAG} = yes into [[ $FLAG != yes ]], but it seems a bit cludgey
2020-08-12 15:46:16 <dalias> wsinatra, [[ is also a bashism
2020-08-12 15:46:48 <wsinatra> hmm that's frustrating. Any suggestions on a good substitution?
2020-08-12 15:47:57 <dalias> [ "$FLAG" != yes ]
2020-08-12 15:49:58 <wsinatra> +1 thanks dalias :)
2020-08-12 15:50:46 <dalias> ncopa, using malloc or not isn't the point
2020-08-12 15:50:55 <dalias> it's not AS-safe and thus you're not allowed to call it in this context
2020-08-12 15:51:08 <dalias> in particular stdio has locks and if the lock happens to be taken in the parent before the fork, the child will deadlock
2020-08-12 15:51:32 <dalias> <@ncopa> i suppose the best thing would be to simply exec directly after the fork. I dont know why they need to do all the stuff they do before exec
2020-08-12 15:51:56 <dalias> 99% of this is a senselessly NIH'd low-quality clone of posix_spawn and they should just be using posix_spawn
2020-08-12 15:52:20 <dalias> but they supposedly want to be able to put a hook (that's documented as only allowed to do AS-safe stuff) in the child before exec
2020-08-12 15:52:28 <dalias> and maybe a few other small things posix_spawn doesn't support
2020-08-12 15:52:40 <dalias> (especially if you're using selinux)
2020-08-12 15:53:16 <dalias> anyway the "enumerate the fds in the parent, close them in the child" has a major TOCTOU bug and does not work
2020-08-12 15:53:34 <dalias> there's an optimized way to loop over all the fds and close them
2020-08-12 15:54:20 <dalias> struct pollfd pfd[1024]; with events=0 for each fd, 0..1023, 0 timeout, look for POLLNVAL in revents
2020-08-12 15:54:33 <dalias> this tells you for 1024 fds at a time whether they're open
2020-08-12 15:54:45 <dalias> if limit is > 1024 just repeat for each 1024
2020-08-12 15:55:04 <dalias> you could do more but 1024 is a nice number that covers default fd limit in one syscall *and* easily fits on stack
2020-08-12 16:01:42 <ncopa> clever
2020-08-12 16:03:19 <dalias> it's basically ~1000x faster than just calling close on each
2020-08-12 16:03:37 <dalias> and has inconsequential total time unless the fd limit is astronomical
2020-08-12 16:04:09 <ncopa> other option i was thinking of was to parse /proc without using readdir
2020-08-12 16:04:40 <ncopa> sorry
2020-08-12 16:05:10 <ncopa> i meant without using opendir, or whatever does malloc
2020-08-12 16:13:18 <ncopa> looks like that is not possible to do in a portable way
2020-08-12 16:13:56 <dalias> yeah, it can be done linux-specific with getdents
2020-08-12 16:14:10 <dalias> but why depend on procfs anyway when you don't have to?
2020-08-12 16:14:15 <dalias> the poll approach is much better
2020-08-12 16:14:16 <Hello71> I don't think /proc/self/fd even exists elsewhere anyways
2020-08-12 16:16:20 <ncopa> i just wonder what happens if max open files are unlimited or similar
2020-08-12 16:16:40 <ncopa> MAX_UINT
2020-08-12 16:30:01 <ncopa> im looking at those qemu hooks
2020-08-12 16:30:26 <ncopa> i wonder how this can be properlyfixed without depending on pre-exec hooks
2020-08-12 16:30:55 <dalias> what do the hooks do?
2020-08-12 16:31:02 <dalias> iirc i patched this in qemu myself once..
2020-08-12 16:31:10 <dalias> but i may have just removed functionality
2020-08-12 16:32:25 <ncopa> there are only two hooks in the entire codebase as i can find, and they both are for qemu. one runs when qemu is execuded in its own namespace apparently
2020-08-12 16:32:35 <ncopa> src/qemu/qemu_process.c
2020-08-12 16:32:35 <ncopa> 2904:    virCommandSetPreExecHook(cmd, qemuProcessStartPRDaemonHook, vm);
2020-08-12 16:32:35 <ncopa> 6783:    virCommandSetPreExecHook(cmd, qemuProcessHook, &hookData);
2020-08-12 16:32:45 <ncopa> qemuProcessStartPRDaemonHook and qemuProcessHook
2020-08-12 16:32:49 <ncopa> let me find the source for you
2020-08-12 16:34:23 <ncopa> https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_process.c#L2831
2020-08-12 16:35:01 <ncopa> this seems to be the second: https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_process.c#L3129
2020-08-12 16:35:48 <dalias> uhg i was looking in qemu
2020-08-12 16:35:54 <dalias> libvirt imports all of qemu ?!
2020-08-12 16:37:53 <dalias> these hooks mostly dont look bad
2020-08-12 16:38:04 <ncopa> no, libvirt has drivers for differetn backends
2020-08-12 16:38:15 <ncopa> so you can manage lxc or xen or qemu etc
2020-08-12 16:38:20 <dalias> virProcessGetNamespaces is bogus and mallocs
2020-08-12 16:38:40 <ncopa> yes, it looks like it allocates a bitmap
2020-08-12 16:39:21 <ncopa> so i think what qemu driver wants to do is to set some namespace related attributes after fork but before exec
2020-08-12 16:39:33 <dalias> this model of "get complete bitmap, then use it" rather than direct iteration is just a broken idiom
2020-08-12 16:39:50 <dalias> it should iterate one at a time in O(1) space
2020-08-12 16:40:29 <dalias> this is what you get when python programmers try to do systems programming...
2020-08-12 16:40:34 <ncopa> :)
2020-08-12 16:40:37 <ncopa> lol
2020-08-12 16:40:39 <mps> :)
2020-08-12 16:40:44 <ncopa> spot on!
2020-08-12 16:41:52 <dalias> (not to dismiss python programmers, i'd probably write pretty shitty and anti-idiomatic python too. just that it's a very different skill and you need ppl who know what they're doing with resources to do systems programming)
2020-08-12 16:42:48 <mps> dalias: but your observation is ok, imo
2020-08-12 16:43:45 <ncopa> i understand perfectly what you mean. this is how you'd want implement it in python
2020-08-12 16:44:17 <Hello71> actually python has excellent generator support
2020-08-12 16:44:39 <dalias> yeah i suspect it can be done better in python too
2020-08-12 16:45:10 <ncopa> what i wonder is if this should be implemented as a wrapper binary that does the namespaces thing and then again posix_spawn qemu
2020-08-12 16:45:34 <dalias> but "make an object representing a set" or "make a gratuitous copy of data" is a very standard thing ppl do in python and usually fairly harmless as long as it's expected to be small
2020-08-12 16:45:46 <dalias> ncopa, yes, that's the real correct solution
2020-08-12 16:46:03 <dalias> rather, posix_spawn the wrapper binary and then it just execs qemu
2020-08-12 16:46:20 <ncopa> *nod*
2020-08-12 16:46:24 <dalias> no need to posix_spawn qemu, you want it in the same process
2020-08-12 16:46:41 <ncopa> makes sense
2020-08-12 16:46:42 <Hello71> compare https://stackoverflow.com/a/16974952 and ftw
2020-08-12 16:47:14 <dalias> hello71, :)
2020-08-12 16:47:35 <dalias> don't you love needing many GBs of ram to walk the filesystem? :)
2020-08-12 16:47:57 <Hello71> dalias: os.walk returns an iterator, it yields entries one at a time
2020-08-12 16:48:01 <dalias> in principle a good high level lang would optimize this not to need it
2020-08-12 16:48:03 <dalias> oh ok
2020-08-12 16:48:03 <Hello71> it doesn't buffer the whole tree
2020-08-12 16:48:04 <dalias> so it does
2020-08-12 16:48:06 <dalias> yay!
2020-08-12 16:48:15 <dalias> i figured it was a list
2020-08-12 16:48:48 <dalias> eew at os.sep, os.path.curdir
2020-08-12 16:49:39 <Hello71> and unlike in C or Java or even JS you don't need some while ((p = next_entry(iter)) or some ftw callback boilerplate
2020-08-12 16:49:45 <Hello71> yeah, ignore the rest of it :p
2020-08-12 16:50:10 <Hello71> I didn't say python programmers are good, I said python provides you the tools to create good code
2020-08-12 16:50:17 <dalias> i don't understand the game of pretending "." is not universal
2020-08-12 16:50:31 <dalias> at least path separator has some historical basis for not treating "/" as universal
2020-08-12 16:50:45 <Hello71> unicode, not universal
2020-08-12 16:50:53 <Hello71> not that either makes sense in this context
2020-08-12 16:52:45 <dalias> not talking about the u
2020-08-12 16:52:55 <mps> speaking of qemu, anyone know is it posible to 'clamp' qemu to specific cpu number on host
2020-08-12 16:53:24 <dalias> i mean about using a symbolic name/variable rather than literal "." or "/"
2020-08-12 17:10:39 <Hello71> oh
2020-08-12 17:15:44 <Cogitri> mps: Not sure how you'd do it with bare qemu, but it's certainly possible to do it with libvirt
2020-08-12 17:15:54 <Cogitri> So I guess Qemu has a setting for that too
2020-08-12 17:22:40 <mps> I looked what help says but didn't found anything, except for numa
2020-08-12 17:23:44 <Cogitri> https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#CPU_pinning for how to do it with libvirt
2020-08-12 17:28:30 <emp75> Does does one get a package prompted out of the testing repo?  Is there an actual process for this or is it less formal?
2020-08-12 17:28:36 <emp75> How
2020-08-12 17:29:53 <Cogitri> It's not really formal, TLDR; Make sure it has a maintainer (or become the maintainer) and that they are OK with moving it to community (that means maintaining it for at least 6 months for the next stable release, so backport security fixes etc.) and then make a MR to move the package from the testing to the community folder
2020-08-12 17:30:45 <Cogitri> Oh, and the package can't depend on stuff in testing/, so you might have to move dependencies from testing/ to community/ too with the same process (can be done in one MR)
2020-08-12 17:34:41 <emp75> ok in particular I am talking about the bird package, which I have contributed to in the past, but recently introduced a breaking change that is causing us some issues with it in production.  The change is good, but is breaking in that it changes bird to run under its own user instead of root, but I would have liked a bit more time to adapt to it (yeah I get its in testing and subject to breakage).
2020-08-12 17:37:45 <emp75> Another thing I noticed is that the pipeline seemed to pass for all architectures, but it only seems the apk has been pushed out for x86_64 and its still not in the armv7 or aarch64 repos.  Is that normal?
2020-08-12 17:38:31 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569#note_107795  <- how do  we best handle this?
2020-08-12 17:38:56 <Cogitri> emp75: Hm, how did it break for you?
2020-08-12 17:39:04 <ikke> Very good question
2020-08-12 17:39:59 <ikke> Seems to have a few fixup commits
2020-08-12 17:41:40 <Cogitri> The MR is far from ready overall, yes
2020-08-12 17:41:59 <emp75> Let me verify, but I believe that the config file was still owned by root, but the process was now running unber the bird user.
2020-08-12 17:42:16 <Cogitri> But not sure what to reply to that review comment: Chowning as nginx sucks but I don't think we have a better way to do that?
2020-08-12 17:42:42 <Cogitri> emp75: Ah, so the bird user can't read it?
2020-08-12 17:42:47 <emp75> right
2020-08-12 17:43:00 <Cogitri> That's something that should be fixed in the APKBUILD then
2020-08-12 17:43:06 <Cogitri> Sorry for the breakage
2020-08-12 17:43:10 <Cogitri> Could you open an issue about it?
2020-08-12 17:44:10 <emp75> Let me verify that we are not doing something outside of apk, and if not I will open an issue on it.
2020-08-12 17:45:42 <emp75> thanks
2020-08-12 17:52:52 <mps> Cogitri: sorry, server where my irssi running lost power just when I started to write answer and thanks
2020-08-12 17:53:12 <emp75> Yeah I don't see the permissions getting set on an existing file anywhere, adn the bird docs state that the config file gets read after the privs are dropped.
2020-08-12 17:58:56 <mps> ncopa: are you ok to merging !11349
2020-08-12 18:30:47 <mps> `sieve-ldap-db.c:1153:33: error: expected ')' before 'PRIuSIZE_T'`
2020-08-12 18:31:09 <mps> "Found script with length %"PRIuSIZE_T, size);
2020-08-12 18:31:31 <mps> what should be used insted of PRIuSIZE_T
2020-08-12 18:39:08 <Cogitri> I guess %zu doesn't work?
2020-08-12 18:43:34 <mps> hmm, looks like MR is not correct
2020-08-12 18:44:13 <dalias> %zu
2020-08-12 18:44:26 <dalias> no idea what PRIuSIZE_T is supposed to be but it's not part of the standard
2020-08-12 18:44:27 <mps> APKBUILDs are full of hacks
2020-08-12 18:44:41 <dalias> and it's completely useless because there's already a first-class size modifier for size_t (z)
2020-08-12 18:44:54 <mps> dalias: Cogitri: macro in new dovecot
2020-08-12 18:45:03 <dalias> i'm guessing this is some hell someone invented to be friendly to MSVCRT...
2020-08-12 18:45:37 <mps> yes, looks like i fixed MR
2020-08-12 18:46:39 <mps> dalias: Cogitri: ./src/dovecot-2.3.11.3/ChangeLog:    global: use %zu directly instead of PRIuSIZE_T
2020-08-12 18:48:12 <mps> but this APKBUILD full of hacks will drove me to full bottle of wine :)
2020-08-12 18:48:31 <mps> !11360
2020-08-12 18:48:52 <ncopa> mps: im ok with !11349
2020-08-12 18:48:56 <mps> could someone look and fix pigeonhole part
2020-08-12 18:49:32 <mps> it should be https://pigeonhole.dovecot.org/releases/$_pkgvermajor/$pkgname-2.3.11-pigeonhole-$_pigeonholever.tar.gz
2020-08-12 18:50:00 <mps> i.e. in MR upgrade for pigeonhole is not updated
2020-08-12 18:50:37 <mps> and I'm not so proficient with shell programming, and such number of hacks
2020-08-12 18:51:43 <mps> this must be set '_pigeonholever=0.5.11'
2020-08-12 18:52:35 <mps> but how to set pigeonhole source url is mystery for me
2020-08-12 18:53:04 <mps> ncopa: thank, will merge it, want to test it on edge
2020-08-12 18:53:12 <mps> thanks*
2020-08-12 18:54:00 <dalias> mps, is there any indication why upstream made the change in the opposite direction?
2020-08-12 18:54:08 <dalias> it would be nice to know if we could get them to revert it
2020-08-12 18:54:37 <mps> dalias: are you kidding
2020-08-12 18:56:27 <mps> hmm, imapc: %zu isn't standard, use PRIuSIZE_T instead. => 2016-11-18 14:10:02 +0200 Timo Sirainen <timo.sirainen@dovecot.fi> (2f26f7521)
2020-08-12 18:56:57 <dalias> %zu is standard
2020-08-12 18:57:11 <dalias> PRIuSIZE_T is not
2020-08-12 18:58:27 <dalias> see http://port70.net/~nsz/c/c11/n1570.html#7.8.1 and http://port70.net/~nsz/c/c11/n1570.html#7.21.6.1p7
2020-08-12 18:58:41 <mps> dalias: maybe reasoning could be found here https://github.com/dovecot/core
2020-08-12 18:59:06 <dalias> i'll comment on it
2020-08-12 18:59:32 <mps> looks like they reverted PRIuSIZE_T to %zu in latest release
2020-08-12 19:00:34 <dalias> ah ok
2020-08-12 19:01:37 <dalias> *sigh* no motivation documented for either
2020-08-12 19:01:46 <dalias> fixed in 0360044976
2020-08-12 19:03:41 <mps> huh, I can't find merges in new github interface
2020-08-12 19:04:02 <dalias> added comment on https://github.com/dovecot/core/commit/2f26f7521
2020-08-12 19:04:05 <mps> ahmm commits
2020-08-12 19:05:52 <mps> dalias: I see
2020-08-12 19:12:01 <mps> Cogitri: sorry I will not comment more about libdbus in issue report about FF to not 'polute' it with OT comment
2020-08-12 19:12:40 <mps> but want to say that FF without dbus is quite fine for me, and I'm far from A/V expert
2020-08-12 19:12:51 <Cogitri> I don't think it's OT and I'm open to disabling libdbus, I just think it's a good idea to know beforehand what this entails
2020-08-12 19:14:25 <ikke> Funny how OT can both mean off-topic and on-topic :P
2020-08-12 19:14:27 <mps> I think I read somewhere that the libdbus support from FF in some of next releases (or I read that in dream)
2020-08-12 19:14:51 <mps> huh
2020-08-12 19:14:57 <c705> you mean upstream is going to patch? sounds like a dream
2020-08-12 19:15:00 <dalias> ?
2020-08-12 19:15:07 <mps> libdbus support will be removed*
2020-08-12 19:15:12 <dalias> libdbus has the same bug as pulseaudio
2020-08-12 19:15:18 <dalias> it's easy to fix tho
2020-08-12 19:15:39 <c705> dalias: are we patching it then?
2020-08-12 19:15:48 <mps> yes, I removed both and FF works with musl 1.2.1
2020-08-12 19:15:56 <c705> fantastic
2020-08-12 19:16:20 <c705> vlc was having issues as well. i suppose if libdbus was patched, then the vlc issues will be fixed as well?
2020-08-12 19:16:23 <mps> c705: but didn't merged to repo
2020-08-12 19:17:52 <dalias> c705, yes, should be.
2020-08-12 19:18:08 <c705> lovely, thanks
2020-08-12 19:18:26 <c705> I never bothered with opening an issue since I was almost sure it was still related to dbus
2020-08-12 20:13:12 <wsinatra> Might be a little late to the party, but it looks like the last patch to qemu/libvirt re-broke remote connection.
2020-08-12 20:13:47 <c705> remote connection?
2020-08-12 20:14:07 <wsinatra> Local connections seem to work fine, but attempting to connect with qemu+ssh doesn't anymore
2020-08-12 20:15:33 <wsinatra> yeah using a libvirt uri like this -> qemu+ssh://wsinatra@ianus/system doesn't work with the last patch, was fine with the patches from earlier today
2020-08-12 20:18:19 <wsinatra> hmm or maybe it was a fluke, it seems to have come back up
2020-08-12 20:38:55 <mps> sorry to ask again, but how can I pull branch from someone other MR and update MR
2020-08-12 20:40:14 <mps> i.e. fetch MR, add my fixes and push to original MR
2020-08-12 20:45:48 <ikke> easiest if you add their repo as a remote
2020-08-12 20:47:04 <mps> I clicked Check out branch and got pop-up guide but that looks risky
2020-08-12 20:47:36 <mps> how can I add this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11360 as remote
2020-08-12 20:48:14 <ikke> git remote add J0WI https://gitlab.alpinelinux.org/J0WI/aports
2020-08-12 20:48:46 <ikke> git fetch J0WI dovecot-2.3.11
2020-08-12 20:50:25 <mps> ok, how to switch to her/his branch
2020-08-12 20:51:56 <ikke> git checkout -t J0WI/dovecot-2.3.11
2020-08-12 20:53:03 <mps> ikke: thanks, this worked
2020-08-12 20:53:25 <mps> and should go in my private guides about alpine dev
2020-08-12 20:54:21 <ikke> You can push back to that branch if they allowed it (which they did in this case)
2020-08-12 20:55:26 <mps> you guided me through that path some time ago but I didn't wrote in my local files
2020-08-12 20:55:32 <mps> sorry for that
2020-08-12 20:55:44 <ikke> no worry
2020-08-12 20:56:04 <ikke> this option is a bit easier because you use a remote, instead of using the url directly
2020-08-12 20:56:44 <mps> how can push changes back to MR?
2020-08-12 20:57:15 <mps> do I have to change remote url to git or https will work
2020-08-12 21:00:10 <mps> git push J0WI? or  git push J0WI/dovecot-2.3.11
2020-08-12 21:00:34 <ikke> hmm, http can work, but you would need to generate an app token
2020-08-12 21:00:41 <ikke> so switching it to ssh is easier
2020-08-12 21:01:16 <ikke> git remote set-url J0WI git@gitlab.alpinelinux.org:J0WI/aports.git
2020-08-12 21:02:59 <mps> git remote set-url --push J0WI git@gitlab.alpinelinux.org/J0WI/aports
2020-08-12 21:03:20 <ikke> that url is wrong
2020-08-12 21:03:38 <ikke> combines uri with scp / rsync syntax
2020-08-12 21:04:11 <ikke> and, there is no real reason to fetch over over http while pushing with ssh
2020-08-12 21:05:26 <mps> ok
2020-08-12 21:07:14 <mps> if you have little more time, what do you think about this crude hack https://tpaste.us/Jxza
2020-08-12 21:09:52 <mps> `git push J0WI` worked
2020-08-12 21:10:17 <ikke> The other option would be to chop of the patch part
2020-08-12 21:10:26 <mps> ikke: thank you again, I'm copy-paste above lines to notes about alpine dev
2020-08-12 21:10:57 <ikke> but I see there a 3 variants
2020-08-12 21:12:53 <mps> I think I don't understand you
2020-08-12 21:14:43 <ikke> pkgver=2.3.11.3
2020-08-12 21:14:45 <ikke> _pkgverminor=${pkgver%.*}
2020-08-12 21:14:47 <ikke> _pkgvermajor=${pkverminor%.*}
2020-08-12 21:14:59 <ikke> forgot one _ in the last one
2020-08-12 21:15:21 <ikke> Then you would not have to individually update each variable when upgrading
2020-08-12 21:16:21 <mps> hah, this is black (or white if preferred) magic for me
2020-08-12 21:17:24 <ikke> it's just chopping of one component
2020-08-12 21:17:33 <ikke> each time
2020-08-12 21:18:40 <mps> aha, now when you told looks understandable
2020-08-12 21:20:44 <mps> if you want fix it, if not maybe I will look tomorrow. I'm too tired now and going to bed
2020-08-12 21:20:49 <ikke> https://tpaste.us/8X1R
2020-08-12 21:21:16 <mps> nice
2020-08-12 21:21:30 <mps> will save it as example for future use
2020-08-12 21:22:59 <ikke> I think I've mostly learned shell programming in the last 4 years, really helpful to know what you can do with sh
2020-08-12 21:23:42 <ikke> without having to invoke subshells (executing other programs)
2020-08-12 21:24:25 <mps> I bought book but never found time to read it carefully and do exercises
2020-08-12 21:28:28 <mps> ikke: good night
2020-08-12 21:28:35 <ikke> nite
2020-08-12 21:28:41 <ikke> (it's too warm here to sleep atm :P)
2020-08-12 21:29:08 <mps> (here is not as much as it was last week)
2020-08-12 22:01:41 <ikke> Ariadne: would upgrading go to 1.15 be an issue? (There is a MR to do so)
2020-08-12 22:02:01 <Ariadne> ikke: seems reasonable to me.  i can try to rebootstrap 1.15 on mips and see if that fixes things
2020-08-12 22:02:28 <ikke> ok, fine
2020-08-12 22:02:35 <ikke> wanted to make sure it didn't make things a lot more difficult
2020-08-12 22:09:30 <Ariadne> i mean, it is already broken.  it can't get more broken.
2020-08-12 22:09:55 <ikke> hehe, true
2020-08-12 22:10:03 <ikke> though, it could be harder to unbreak it
2020-08-12 22:10:23 <Ariadne> i've heard that 1.15 actually works largely as expected on mips
2020-08-12 22:10:32 <Ariadne> but maybe not with this damn BSP kernel
2020-08-12 22:10:41 <ikke> right
2020-08-12 22:10:56 <Ariadne> which is a shame, we now have 30 of them and they are pretty useless to us :(
2020-08-12 22:11:15 <ikke> is reverse engineering the nic driver progressing?
2020-08-12 22:20:23 <Ariadne> ikke: we've discovered that the binary blob driver does not cover all errata
2020-08-12 22:20:26 <Ariadne> sooooo
2020-08-12 22:20:31 <Ariadne> yes, but also no :)
2020-08-13 04:26:20 <Ariadne> PureTryOut[m]: so one thing i've noticed on kwin_wayland now that i have a desktop with threads out the ass is
2020-08-13 04:26:32 <Ariadne> d-bus session bus stalls for several seconds at initial login
2020-08-13 04:26:48 <Ariadne> i wonder if what is happening is that kwin_wayland gives up on connecting to the session bus
2020-08-13 07:29:54 <ncopa> morning
2020-08-13 07:30:38 <Cogitri> 👋
2020-08-13 07:31:40 <ikke> hi
2020-08-13 07:34:10 <Ariadne> hi
2020-08-13 07:34:12 <fcolista> hi
2020-08-13 07:34:17 <ncopa> my new i9 computer hanged 60 am this morning. (3 hours ago)
2020-08-13 07:34:24 <Ariadne> :(
2020-08-13 07:34:39 <fcolista> silly querstion: can you please remember me if i need to bump pkgrel when i move a package from testing to community?
2020-08-13 07:34:40 <Cogitri> Oof
2020-08-13 07:34:44 <ncopa> the xfce clock was frozen, keyboard frozen, no mouse movements, not even ping responses
2020-08-13 07:34:54 <ncopa> fcolista: i think not
2020-08-13 07:34:55 <Ariadne> i'm chasing down a weird bug in xorg-xserver in GLAMOR right now
2020-08-13 07:34:55 <fcolista> ncopa, before or after breakfast?
2020-08-13 07:35:05 <Ariadne> have i mentioned that i hate X lately
2020-08-13 07:35:07 <ikke> We always say that it's not required
2020-08-13 07:35:10 <ncopa> before breakfat
2020-08-13 07:35:36 <fcolista> ncopa, ikke: ok good. I need to write down this that I always forget :)
2020-08-13 07:35:49 <fcolista> ncopa, if is before breakfast, must be because of that.
2020-08-13 07:36:18 <ncopa> lol
2020-08-13 07:36:27 <ncopa> i suspect its the GPU
2020-08-13 07:36:33 <ncopa> or maybe the wifi
2020-08-13 07:36:43 <ncopa> driver(s)
2020-08-13 07:37:32 <Ariadne> what gpu are you using
2020-08-13 07:38:19 <Cogitri> I think we had a bug with Intel iGPUs freezing on earlier mesa versions, didn't we?
2020-08-13 07:38:31 <ncopa> intel
2020-08-13 07:38:45 <ncopa> yes, thats why i suspect the gpu
2020-08-13 07:38:50 <Cogitri> Never had that on my laptop which also uses an intel iGPU though (but with hybrid AMD graphics, but those aren't used on the desktop)
2020-08-13 07:39:17 <Cogitri> I guess dmesg doesn't say anything useful either with a hard freeze?
2020-08-13 07:39:39 <ncopa> hard freeze does not allow me to run dmesg
2020-08-13 07:39:44 <ncopa> i dont know how to capture it
2020-08-13 07:42:14 <ncopa>  glamor X acceleration enabled on Mesa Intel(R) UHD Graphics 630 (CML GT2)
2020-08-13 07:42:39 <ncopa> thats the gpu
2020-08-13 07:43:03 <ncopa> 00:02.0 VGA compatible controller: Intel Corporation Device 9bc5 (rev 05)
2020-08-13 07:43:38 <ncopa> maybe should move this discussion to #alpine-offtopic
2020-08-13 07:43:51 <ikke> Isn
2020-08-13 07:43:58 <ikke> Isn't debugging driver issues on-topic?
2020-08-13 07:44:29 <mps> newer kernel have pstore where can kernel ops logged
2020-08-13 07:44:47 <Ariadne> yes, using efi variables i think
2020-08-13 07:44:50 <ikke> mps: yea, I was thinking of exactly that
2020-08-13 07:46:39 <mps> and in last few months a lot of bugs 'appeared' on intel chips
2020-08-13 07:47:01 <Ariadne> my current desktop is not even x86 sooo :P
2020-08-13 07:47:29 <mps> also my is not :)
2020-08-13 07:49:07 <Ariadne> mps: what are you using
2020-08-13 07:49:39 <mps> elm-oak and gru-kevin chromebooks
2020-08-13 07:50:28 <mps> aarch64, on oak is 3.12 stable and on gru-kevin is edge
2020-08-13 08:06:59 <Ariadne> mps: which kernel tree are you following for oak?
2020-08-13 08:07:49 <ncopa> i'd be happy to get a non-x86 desktop if there were any available with similar performance/price and silent
2020-08-13 08:07:59 <ncopa> i'd love to have an arm desktop
2020-08-13 08:10:46 <mps> Ariadne: didn't you read here when I posted info about it
2020-08-13 08:10:59 <Ariadne> ncopa: honeycomb
2020-08-13 08:11:20 <mps> Ariadne: https://gitlab.collabora.com/eballetbo/linux/-/tree/topic/chromeos/somewhat-stable-5.8
2020-08-13 08:11:28 <Ariadne> ncopa: 16 core cpu up to 64 gigs of RAM :)
2020-08-13 08:11:54 <Ariadne> mps: thanks
2020-08-13 08:11:56 <mps> yes, honeycomb looks tempting
2020-08-13 08:12:20 <Ariadne> in fairness the apple CPU stomps all over that thing
2020-08-13 08:12:41 <Ariadne> however you cannot buy apple CPUs yet :p
2020-08-13 08:12:44 <mps> Ariadne: if you want I can post you .config, kernel.its and my build script
2020-08-13 08:12:52 <Ariadne> yeah that would be helpful
2020-08-13 08:13:16 <Ariadne> I have to use a different dtb because Hana is wired slightly differently but
2020-08-13 08:13:24 <Ariadne> same SoC so it should otherwise work
2020-08-13 08:14:34 <mps> Ariadne: kernel.its is here https://tpaste.us/rezE
2020-08-13 08:15:37 <mps> Ariadne: kernel .config is here https://tpaste.us/PM4Y
2020-08-13 08:16:29 <Ariadne> I'm thinking about just porting edk2 to the chromebook
2020-08-13 08:16:34 <Ariadne> that would give efi
2020-08-13 08:16:51 <mps> Ariadne: my script (undocumented) is here https://tpaste.us/6Vbz
2020-08-13 08:17:35 <mps> it has to be run from top dir in unpacked/cloned tree
2020-08-13 08:18:06 <mps> Ariadne: only keep note that our current vboot-utils doesn't work
2020-08-13 08:18:21 <Ariadne> yeah
2020-08-13 08:18:26 <mps> you have to build it on native box, not in container
2020-08-13 08:19:29 <mps> or, I can put somewhere my local built apk which works, if you have trust in me, i.e. that I didn't put backdoor
2020-08-13 08:20:43 <mps> N.B. I can't conclude why native build produce working binaries and lxc produce non functional ones
2020-08-13 08:21:30 <mps> what's more interesting build in x86_64 lxc produce working binaries
2020-08-13 08:22:37 <ikke> isn't lxc native when it comes to producing binaries?
2020-08-13 08:22:47 <Ariadne> I can try your apk :)
2020-08-13 08:23:23 <mps> ok, I will put it on my local server and post url to you
2020-08-13 08:23:50 <Ariadne> looks like your kernel includes Hana DTB anyway
2020-08-13 08:24:26 <mps> this way you can build your local vboot-utils and check which backdoor I put :D
2020-08-13 08:24:42 <mps> yes, hana and some other also included
2020-08-13 08:25:19 <mps> don't know if they are needed for oak but they don't make any problem
2020-08-13 08:31:58 <ncopa> my nic driver is not enabled in or lts kernel config. im fixing that now
2020-08-13 08:34:42 <mps> Ariadne: here is vboot-utils apk http://arvanta.net/2x3d1kfg/vboot-utils-6310032-r3.apk
2020-08-13 10:49:03 <Cogitri> Nice, we just got >100k commits in aports now :)
2020-08-13 11:21:10 <ikke> oh wow
2020-08-13 11:55:12 <ikke> git.git has only 72k commits :)
2020-08-13 11:55:21 <ikke> though, commits in aports are generally more trivial
2020-08-13 11:59:21 <hc-hmk> What is the release cycle for alpine? When do we see a 3.13 release?
2020-08-13 11:59:40 <ikke> hc-hmk: twice per year
2020-08-13 11:59:47 <ikke> next one would be around november / december
2020-08-13 12:00:10 <ikke> hc-hmk: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-08-13 12:00:57 <hc-hmk> Thanks, forgot to check the wiki before asking.
2020-08-13 12:30:28 <hc-hmk> ncopa you're maintainer on the chromium package. What would I have to do to get a chromium-ozone package in repos? I can port the AUR build procedure to aports and submit a MR, but I'm not sure if you guys even want the package. It's a patchset that lets chromium use wayland natively instead of xorg-server-wayland
2020-08-13 12:30:58 <Cogitri> hc-hmk: We already had a patchset for that by @maribu
2020-08-13 12:31:05 <Cogitri> Ozone is very not ready yet though
2020-08-13 12:31:09 <Cogitri> And likes to crash a lot on Xorg
2020-08-13 12:31:15 <Cogitri> So we didn't switch yet
2020-08-13 12:31:33 <hc-hmk> Oh, if you already have something in the works for wayland-native chromium?
2020-08-13 12:31:58 <Cogitri> Offering two packages (one for Wayland and one for Xorg) isn't a great alternative either, we already tend to lag behind a worrying amount of time for updates
2020-08-13 12:32:17 <Cogitri> The only thing we have in the works is wait for upstream to fix Ozone to work properly on Xorg too
2020-08-13 12:33:19 <hc-hmk> When you say "lag behind a worrying amount of time", do you mean the actual buildtime for the packages, or for a maintainer to issue an updated version?
2020-08-13 12:33:44 <Cogitri> The latter
2020-08-13 12:34:01 <Cogitri> Bumping chromium takes a lot of time because we have many downstream patches and it takes ages to build it
2020-08-13 12:34:39 <hc-hmk> Oh, that's unfortunate.
2020-08-13 12:37:01 <hc-hmk> So the current plan is to wait for chromium issue 1085700 to go through, such that ozone layer is default on linux builds?
2020-08-13 12:41:03 <Cogitri> Not sure what issue that is, but the current plan is to wait until Ozone doesn't crash on most desktops, yes
2020-08-13 12:49:38 <hc-hmk> Fair.
2020-08-13 12:51:44 <ncopa> we need a volunteer with the needed skills that can take responsibility for it. i barely have time for chromium as it is
2020-08-13 12:52:09 <ncopa> upstreaming patches would be very helpful, but i think its non-trivial to upstream majority of the patches
2020-08-13 12:52:29 <ncopa> part of the problem is that upstream assumes OS_LINUX == glibc
2020-08-13 12:53:40 <hc-hmk> That's odd. I'd assume that tizen etc runs musl or µlibc along with chromium
2020-08-13 12:54:45 <hc-hmk> Unfortunately I have no experience with building chromium in particular, so I'm pretty sure I'm not the right person for the task.
2020-08-13 12:58:59 <ncopa> a dev that: has time / has the skills / want to do it for free. pick two.
2020-08-13 14:35:14 <emp75> In an MR I submitted I was asked to enable the contribution option on it, but that option is greyed out and I can't enable it.  Does anyone know why or how to fix it?
2020-08-13 14:35:58 <Cogitri> Hmm, is the branch you made MR from protected?
2020-08-13 14:36:07 <Cogitri> i.e. did you make the MR from the master branch?
2020-08-13 14:36:57 <emp75> I made it from the master branch of my aports fork to the master branch in aports.
2020-08-13 14:37:56 <Cogitri> Yeah, the master branch is protected by default, so no one but you can push on it (and there's no way to force push and a such rebase on that branch)
2020-08-13 14:38:15 <emp75> ok thanks.
2020-08-13 14:38:16 <ikke> So conclusion: use topic/feature branches for your merge request
2020-08-13 14:38:28 <Cogitri> See https://docs.gitlab.com/ee/user/project/protected_branches.html
2020-08-13 14:38:38 <Cogitri> But yes, use feature branches for your contributions
2020-08-13 14:38:48 <Cogitri> $pkgname is a good name for feature branches :)
2020-08-13 14:39:37 <emp75> thanks will do.
2020-08-13 17:02:17 <ollieparanoid[m]> is somebody skilled with gdb + qemu? I've spent the whole day trying to get a backtrace of an "apk add" segfault in aarch64 user-mode emulation, which only appears on builds.sr.ht: https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1958
2020-08-13 17:02:23 <ollieparanoid[m]> ddevault: ^ in case you want to take a look. I don't think it's related to builds.sr.ht though.
2020-08-13 17:03:26 <ollieparanoid[m]> (oh, he's not in the channel...)
2020-08-13 17:32:01 <mps> I'm lost with gitlab workflow :\
2020-08-13 17:34:28 <ikke> mps: how come?
2020-08-13 17:37:48 <Cogitri> ollieparanoid[m]: It's probably not possible running that on a local machine?
2020-08-13 17:37:55 <Cogitri> Debugging SEGFAULTs on CI is no fun
2020-08-13 17:38:56 <ikke> I thought that sourcehut allowed you to ssh into the build environment?
2020-08-13 17:39:32 <mps> ikke: uh, hard to explain
2020-08-13 17:41:11 <ikke> mps: hard to help then :)
2020-08-13 17:41:14 <Cogitri> ikke: Possibly, I've never used it because I dislike working with email for patches :)
2020-08-13 17:47:42 <mps> ikke: :)
2020-08-13 17:48:24 <mps> I have fix for dovecot on 32bit arches but MR is so bad state
2020-08-13 17:49:35 <mps> half of day worked with upstream to find cause and solution and now I'm 'stopped' by our complicated workflow
2020-08-13 17:49:56 <mps> and I don't want to be rude and simply supersede MR
2020-08-13 17:50:49 <mps> (which would be proper 'solution' because original poster didn't tried seriously to fix it)
2020-08-13 17:51:27 <mps> sometimes I want to have 'wtf' character ;P
2020-08-13 17:51:51 <mps> character == personality
2020-08-13 17:52:34 <insep_> <mps "sometimes I want to have 'wtf' c"> 🤨
2020-08-13 17:52:37 <insep_> here ya go
2020-08-13 18:10:08 <maxice8> @Cogitri https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54
2020-08-13 18:15:22 <Cogitri> Oh, I guess that got lost in my inbox, I can take a look in a bit
2020-08-13 20:22:23 <mps> ikke: do you know which musl version is on 3.12 CIs
2020-08-13 20:23:17 <ikke> It uses an edge docker image and downgrades that to 3.12
2020-08-13 20:23:24 <ikke> is it giving issues?
2020-08-13 20:23:59 <mps> could be, I'm not sure
2020-08-13 20:24:48 <mps> https://gitlab.alpinelinux.org/mps/aports/pipelines/39904
2020-08-13 20:26:35 <mps> if it uses musl 1.2.x then fails on 32bit arches is expected, but if 1.2.24 then it should pass
2020-08-13 20:27:42 <ikke> "(1/62) Downgrading musl (1.2.1-r0 -> 1.1.24-r9)"
2020-08-13 20:28:06 <mps> I'm blind (:
2020-08-13 20:29:13 <ollieparanoid[m]> Cogitri, ikke: yep, I can ssh into the builders, which is pretty awesome. can't reproduce it locally though
2020-08-13 20:45:28 <maxice8> Just noticed
2020-08-13 20:45:36 <maxice8> echo from coreutils needs libacl.so.1 and libattr.so.1
2020-08-13 20:59:37 <maxice8> Is there a reason the echo binary needs those ?
2020-08-13 21:01:47 <dne> the code doesn't seem to use them
2020-08-13 21:02:02 <maxice8> possible overlinking ?
2020-08-13 21:02:26 <[[sroracle]]> didn't alpine switch to coreutils single binary dist? so echo would be symlink to the mutlicall binary
2020-08-13 21:02:32 <dne> I'd guess - e.g on debian they're not needed
2020-08-13 21:02:47 <maxice8> oh, makes sense
2020-08-13 21:02:49 <dne> aah
2020-08-13 21:04:23 <mps> [[sroracle]]: yes, lrwxrwxrwx 1 root root 20 Mar 12 00:18 /bin/echo -> ../usr/bin/coreutil
2020-08-13 21:04:23 <ikke> yes, coreutils is a single binary
2020-08-13 21:04:51 <mps> huh, lrwxrwxrwx 1 root root 20 Mar 12 00:18 /bin/echo -> ../usr/bin/coreutils
2020-08-13 23:05:02 <chira> ls -l /bin/echo
2020-08-13 23:05:35 <chira> sorry
2020-08-14 01:17:51 <maxice8> /usr/lib/gcc/armv6-alpine-linux-musleabihf/9.3.0/../../../../armv6-alpine-linux-musleabihf/bin/ld: cannot find -ltalloc
2020-08-14 01:17:55 <maxice8> and talloc-dev is in the packages
2020-08-14 01:40:49 <maxice8> @PureTryOut can you take a look at libmlocale, there are still some functions that are used that are deprecated on qt5.15 and are causing the build to fail because of '-Werror=deprecated-declarations'
2020-08-14 02:22:13 <maxice8> algitbot: retry master
2020-08-14 03:06:23 <maxice8> https://git.sr.ht/~kennylevinsen/seatd
2020-08-14 03:06:27 <maxice8> algitbot: retry master
2020-08-14 05:50:46 <maxice8> algitbot: retry master
2020-08-14 06:23:09 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/libmdf/libmdf-1.0.23-r2.log
2020-08-14 06:23:22 <maxice8> libmdf is trying to fetch from distfiles.alpinelinux.org and getting wrong checksum
2020-08-14 07:17:42 <ncopa> morning
2020-08-14 07:19:23 <maxice8> morning
2020-08-14 07:19:40 <maxice8> x86_64 builder seems stuck on mopidy
2020-08-14 07:21:30 <Cogitri> Morning
2020-08-14 07:26:51 <maxice8> openlitespeed is magical
2020-08-14 07:26:55 <maxice8> and not in a good way
2020-08-14 07:27:43 <ncopa> also looks like build-edge-aarch64 is stuck on building libreoffice
2020-08-14 07:27:59 <ncopa> i suspect that openjdk is doing illegal things after fork
2020-08-14 07:28:03 <maxice8> It failed I think
2020-08-14 07:28:12 <maxice8> It just decided to stay there
2020-08-14 07:29:01 <ncopa> no, there are 4 java processes consuming 32G
2020-08-14 07:29:14 <ncopa> 7
2020-08-14 07:30:26 <ncopa> and im not allowed to strace it in this container
2020-08-14 07:31:28 <ncopa> build-edge-x86_64 moved to a new host yesterday
2020-08-14 07:33:41 <ncopa> >>> mopidy: Building community/mopidy 3.0.2-r4 (using abuild 3.6.0-r1) started Fri, 14 Aug 2020 03:13:15 +0000
2020-08-14 07:33:49 <ncopa> build-edge-x86_64:~# date
2020-08-14 07:33:49 <ncopa> Fri Aug 14 07:33:37 UTC 2020
2020-08-14 07:34:01 <ncopa> it has run for 4 hours
2020-08-14 07:34:50 <Cogitri> mopidy seems to be in rather not good shape on all arches right now
2020-08-14 07:35:01 <Cogitri> PureTryOut[m]: ^
2020-08-14 07:35:05 <ncopa> its the testsuite that gets stuck
2020-08-14 07:35:59 <ncopa> fwiw, the most common reason things deadlocks nowdays is because apps are doing illegal things after fork() and before exec(). with glibc it normally works, but with recent musl it deadlocks
2020-08-14 07:37:48 <ncopa> looking at the `ps xa` output on build-edge-x86_64 makes me think that the problem with mopidy is something else
2020-08-14 07:38:04 <Cogitri> Yeah, the test just fails on other arches
2020-08-14 07:38:37 <ncopa> mopidy buildlog: https://tpaste.us/dEew
2020-08-14 07:38:55 <ncopa> i dont have time to fix either libreoffice or mopidy today. im swamped
2020-08-14 07:39:16 <ncopa> i need to move distfiles to new host so i can poweroff the old bld2
2020-08-14 07:39:45 <mps> some pkgs fails on CI but pass on builders and some pass on CI and fails on builders
2020-08-14 07:39:49 <ncopa> which is kind of sentimental. I think its the first official dedicated build server for alpine
2020-08-14 07:40:19 <ncopa> may be race conditions, which triger deadlocks at random
2020-08-14 07:41:30 <ncopa> im killing the mopidy test suite on the builder
2020-08-14 07:41:40 <mps> not sure if it possible but would be nice to have CIs and builders nearly same
2020-08-14 07:41:52 <ncopa> +1
2020-08-14 07:44:34 <ncopa> weird. im not able to reproduce mopidy in my dev env
2020-08-14 07:44:46 <ncopa> which should be very similar to the build server
2020-08-14 07:46:49 <ncopa> huh
2020-08-14 07:47:02 <ncopa> not on my local machine either
2020-08-14 07:48:30 <ncopa> maybe its ipv6 related?
2020-08-14 08:06:02 <gjabell> I'm working on fixing someone else's MR that's currently not building
2020-08-14 08:06:18 <gjabell> is it better to just open a brand new MR or post the changes in a thread on that MR to get them merged?
2020-08-14 08:07:27 <Cogitri> Well, if the person making the MR it'd be best to post the changes there so the original author can amend them and can add you as co-author
2020-08-14 08:08:01 <Cogitri> It's not really motivating when your work gets superseded
2020-08-14 08:08:10 <gjabell> makes sense, thanks :)
2020-08-14 08:08:27 <Cogitri> But if the person who made the MR isn't responsive making a new MR is fine too
2020-08-14 08:09:27 <gjabell> oh just noticed they're on here, I'll just ask them directly haha
2020-08-14 08:10:06 <gjabell> afontain_: I have fixes for the pantalaimon MR, do you want them posted on the MR or via email, etc.?
2020-08-14 08:10:38 <afontain_> as a comment on the MR is fine for me
2020-08-14 08:11:12 <afontain_> by the way, the MR would be fine to merge almost as is, with an extra !check
2020-08-14 08:43:26 <mps> yes, or working on someones else MR is not thankful and simple job. always risk the MR author could be 'offended'
2020-08-14 08:43:53 <ikke> experience? ;)
2020-08-14 08:44:04 <mps> ikke: yes
2020-08-14 08:50:03 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/kcgi/kcgi-0.10.18-r0.log
2020-08-14 08:50:07 <maxice8> failure for checksum again
2020-08-14 08:50:24 <maxice8> the checksum is correct in the APKBUILD
2020-08-14 08:51:53 <ikke> ncopa: ^
2020-08-14 08:55:22 <ncopa> thats worrying
2020-08-14 08:55:32 <ncopa> i suspect filesystem corruption
2020-08-14 08:55:44 <ncopa> good its getting replaced today
2020-08-14 08:56:01 <ncopa> i will stop distfiles for a while now
2020-08-14 08:56:10 <ncopa> and build lots
2020-08-14 08:56:13 <ncopa> build logs
2020-08-14 08:56:18 <ncopa> and move to new host
2020-08-14 08:56:22 <ncopa> may take an hour
2020-08-14 08:56:35 <maxice8> happens on ppc64le as well
2020-08-14 08:56:55 <ikke> distfiles is just one server
2020-08-14 08:57:01 <ikke> where all arches poll from
2020-08-14 08:57:36 <maxice8> i see
2020-08-14 09:02:03 <ncopa> imstopping distfiles now for migration
2020-08-14 09:05:12 <maxice8> gl
2020-08-14 09:38:56 <afontain_> gjabell: how about upstreaming your keyring patch?
2020-08-14 09:42:58 <mps> I don't have time (sudden things happened) to finish MR for dovecot (one my and one J0WIs)
2020-08-14 09:43:30 <mps> and I will not have time in next 10 days
2020-08-14 09:44:08 <mps> so if someone are willing to look and continue on fixes I have no objections
2020-08-14 09:50:04 <mps> yesterday I talked with upstream on #dovecot channel (nick cmouse) and he is very responsive and ready to help
2020-08-14 09:50:29 <gjabell> afontain_: good idea, I'll open a PR
2020-08-14 09:50:54 <mps> hmm, don't see raised hands
2020-08-14 09:51:18 <afontain_> lemme know how it goes
2020-08-14 09:52:50 <mps> btw, MR with patch cmose created for edge pass tests on armv7 in lxc
2020-08-14 09:55:36 <gjabell> afontain_: https://github.com/matrix-org/pantalaimon/pull/65
2020-08-14 10:09:00 <afontain_> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/wuoTUxBATXTQOKmkoCApWsqd/message.txt >

2020-08-14 10:09:17 <afontain_> ^ what does usually cause these CI fails?
2020-08-14 10:10:03 <ikke> Hmm, that's not an error I have seen often before
2020-08-14 10:11:17 <afontain_> I've been seeing these from times to times
2020-08-14 10:11:22 <afontain_> maybe I'm unlucky
2020-08-14 10:28:02 <gjabell> I've been seeing those in almost all of my CI builds, it's a red herring though
2020-08-14 10:28:25 <gjabell> the py3-janus build failed because of a bad signature (been seeing a lot of those, too, particularly on x86)
2020-08-14 10:39:48 <PureTryOut[m]> maxice8: !11025 is ready for merging and approved by ollieparanoid
2020-08-14 11:20:48 <hc-hmk> Are there any plans to make cgroups2 the default?
2020-08-14 11:23:07 <hc-hmk> I'm thinking about rewriting /etc/init.d/cgroups to provide cgroups2. Is that something I should upstream to you?
2020-08-14 11:31:42 <hc-hmk> Oh, after reading the script I see that it already does that. The default is just cgroups instead of cgroups2 unified. Are there any compatibility issues since it's not the default?
2020-08-14 11:53:16 <Cogitri> hc-hmk: I think we use hybrid as standard where both cgroupsv1 and v2 is mounted
2020-08-14 11:54:41 <hc-hmk> Is there a reason for this, or is that just how it is? Because if there's a reason, I'm not even gonna bother changing it for our local builds.
2020-08-14 11:55:31 <Cogitri> I guess it's just because no one has seen the need to change it yet
2020-08-14 11:56:08 <Cogitri> And with hybrid mounting both v1 and v2 I don't see the advantages of moving to v2 only (but there may very well be advantages to it - I haven't really used cgroups much)
2020-08-14 11:59:51 <hc-hmk> I mean.. v2 is not an addition to v1, meant to be used in conjunction. It's a replacement. I'd assume hybrid is used right now to ease the transition from v1 to v2, but I'm honestly not sure.
2020-08-14 12:01:32 <ikke> hc-hmk: doesn't it mean it supports both v1 and  v2 users?
2020-08-14 12:02:33 <hc-hmk> Yes it does
2020-08-14 12:02:58 <hc-hmk> If I understand your question correctly, hybrid supports both v1 and v2 users.
2020-08-14 12:04:03 <ikke> ok, is there a specific reason then you are asking this question
2020-08-14 12:04:17 <ikke> https://unix.stackexchange.com/a/480748/10643
2020-08-14 13:12:17 <indy> hi all i have 3rd party binary without sources which i need to package to apk, is there any example of no-source package?
2020-08-14 13:14:22 <Cogitri> You can take a look at a normal APKBUILD and only override package ()
2020-08-14 13:14:43 <Cogitri> In package do `mkdir -p "$pkgdir"` and then move things to the right place in $pkgdir
2020-08-14 13:17:16 <ikke> indy: it's basically just skipping the build phase
2020-08-14 13:17:24 <ikke> and only include a package step
2020-08-14 13:42:31 <wsinatra> anyone mind checking over !11424 for me?
2020-08-14 13:56:12 <ikke> looks ok, one minor issue
2020-08-14 14:00:54 <wsinatra> doh, rookie move, I should double check when I push MRs late at night
2020-08-14 14:00:57 <wsinatra> thanks Ikke!
2020-08-14 14:06:43 <indy> Cogitri, ikke thanks
2020-08-14 14:40:45 <gjabell> afontain_: pantalaimon upstream merged the test patch
2020-08-14 14:40:59 <gjabell> next version I guess we can remove it from the apkbuild
2020-08-14 14:41:16 <afontain_> nice
2020-08-14 15:26:11 <cfengineuser> I am making my first alpine package and I am unclear on how the -dev and -doc pkg directories are created, any tips?
2020-08-14 15:28:18 <wsinatra> there's some default logic baked into it for most things
2020-08-14 15:28:41 <wsinatra> if you have a subpackages="$pkgname-doc $pkgname-dev" the rest of it should be handled automagically
2020-08-14 15:28:56 <cfengineuser> yes i am finding it is not
2020-08-14 15:29:06 <cfengineuser> unsure as to what i've done wrong
2020-08-14 15:29:40 <cfengineuser> i get an error about the directories not existing
2020-08-14 15:30:07 <cfengineuser> i do have the subpackages listed in APKBUILD
2020-08-14 15:33:13 <wsinatra> can you share the APKBUILD via tpaste? Or do you have it in a MR/git repo somewhere so that I could take a look?
2020-08-14 15:33:19 <wsinatra> I might be able to make some suggestions :)
2020-08-14 15:33:40 <cfengineuser> one min
2020-08-14 15:36:28 <cfengineuser> how do i use tpaste
2020-08-14 15:36:30 <cfengineuser> lol
2020-08-14 15:38:16 <cfengineuser> nvm
2020-08-14 15:38:51 <cfengineuser> https://tpaste.us/MbZv
2020-08-14 15:38:54 <wsinatra> pastebin is another suggestion, or you could make a github/gitlab snippet. Really just any way to share
2020-08-14 15:39:02 <cfengineuser> try that
2020-08-14 15:41:00 <wsinatra> one sec, checking it out now
2020-08-14 15:41:16 <cfengineuser> it builds but dies on the subpackaging
2020-08-14 15:43:11 <cfengineuser> thanks
2020-08-14 15:45:10 <wsinatra> takes a little bit to compile, but I'm testing on my end to see what happens. Had to remove the install and init/conf sources since I don't have them on hand
2020-08-14 15:45:29 <cfengineuser> want the error tpasted
2020-08-14 15:45:37 <cfengineuser> ?
2020-08-14 15:45:41 <wsinatra> sure that would probably be quicker
2020-08-14 15:45:51 <cfengineuser> well the compile isnt that long
2020-08-14 15:46:02 <cfengineuser> although my system is fast
2020-08-14 15:46:56 <wsinatra> It's not too long fortunately, I'm just eating up my resources at the moment
2020-08-14 15:47:13 <cfengineuser> i see one min
2020-08-14 15:48:43 <cfengineuser> https://tpaste.us/EOVe
2020-08-14 15:48:54 <nmeum> cfengineuser: is it possible that you defined a -doc or -dev subpackage for a software which doesn't install any headers / documentation files?
2020-08-14 15:49:39 <cfengineuser> maybe should i try without
2020-08-14 15:49:54 <cfengineuser> i'm noob just following tutorial
2020-08-14 15:50:19 <cfengineuser> ill try without
2020-08-14 15:50:24 <wsinatra> src/tor-0.4.3.6/doc/tor-resolve.1 <- from the source, it definitely has docs in it
2020-08-14 15:51:18 <cfengineuser> ya i figured as much
2020-08-14 15:51:21 <wsinatra> my guess is to add a doc function and set a new builddir
2020-08-14 15:51:31 <wsinatra> or make a cd call
2020-08-14 15:51:42 <nmeum> it's not the doc split function that's failing
2020-08-14 15:51:46 <nmeum> it's the dev split function
2020-08-14 15:52:09 <cfengineuser> running with no subpackages
2020-08-14 15:52:11 <wsinatra> ah right you are
2020-08-14 15:52:29 <nmeum> my best guess it that the package doesn't install any header files
2020-08-14 15:52:36 <cfengineuser> ok
2020-08-14 15:52:38 <wsinatra> nmeum, what files fall under the -dev category? any .h?
2020-08-14 15:52:59 <nmeum> not just that
2020-08-14 15:53:39 <nmeum> lots of things actually https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1851
2020-08-14 15:53:50 <nmeum> libraries, cmake stuff, pkg-config files, …
2020-08-14 15:54:00 <cfengineuser> without subpackages it fails, complains about putting things under /srv, /usr/local or /opt
2020-08-14 15:54:10 <nmeum> well, that's a different error message ;)
2020-08-14 15:54:16 <cfengineuser> progress
2020-08-14 15:54:18 <cfengineuser> !!!
2020-08-14 15:54:20 <cfengineuser> lol
2020-08-14 15:54:31 <cfengineuser> hmm how to fix
2020-08-14 15:54:58 <cfengineuser> wtf is wrong with putting things there
2020-08-14 15:55:02 <cfengineuser> new to alpine
2020-08-14 15:56:28 <cfengineuser> I don't follow
2020-08-14 15:57:09 <cfengineuser> the install certainly wants to put things there
2020-08-14 16:01:37 <cfengineuser> https://tpaste.us/0PQK
2020-08-14 16:01:46 <cfengineuser> ??
2020-08-14 16:02:05 <Hello71> you didn't specify --prefix=/usr
2020-08-14 16:02:19 <cfengineuser> ok
2020-08-14 16:02:38 <Hello71> obviously you shouldn't install system package to /usr/local
2020-08-14 16:02:45 <Hello71> that's the whole point of /usr/local
2020-08-14 16:02:45 <cfengineuser> ok blew that
2020-08-14 16:03:02 <Hello71> literally every linux distro
2020-08-14 16:03:19 <cfengineuser> true
2020-08-14 16:03:55 <cfengineuser> thanks
2020-08-14 16:05:26 <nmeum> see also: man 7 hier
2020-08-14 16:06:14 <cfengineuser> what makes this a system package? sorry for my ineptitude
2020-08-14 16:07:50 <nmeum> well, if you are just packaging this for yourself you can also add !fhs to $options
2020-08-14 16:08:02 <nmeum> see the APKBUILD(5) man page for more information on this option
2020-08-14 16:08:09 <cfengineuser> k thanks
2020-08-14 16:08:15 <cfengineuser> i would be happy to share it
2020-08-14 16:08:22 <cfengineuser> i just want it
2020-08-14 16:08:26 <cfengineuser> and a few other tools
2020-08-14 16:10:39 <ikke> nmeum: funny that 'hier' means 'here' in dutch
2020-08-14 16:11:07 <maxice8> and german
2020-08-14 16:11:09 <nmeum> yeah, same thing in german
2020-08-14 16:11:17 <maxice8> inb4 "basically the same language"
2020-08-14 16:11:31 <nmeum> haha
2020-08-14 16:11:40 <cfengineuser> woot! new erros
2020-08-14 16:11:59 <cfengineuser> looks like i need a doc
2020-08-14 16:12:22 <maxice8> algitbot: retry master
2020-08-14 16:16:11 <cfengineuser> hey I go tthis warning about OpenRC directory with name not ending in -openrc
2020-08-14 16:16:14 <cfengineuser> ?
2020-08-14 16:16:18 <cfengineuser> it built
2020-08-14 16:16:24 <maxice8> add $pkgname-openrc to subpackages=
2020-08-14 16:16:36 <cfengineuser> thnaks
2020-08-14 16:16:58 <ikke> It's a policy warning
2020-08-14 16:17:08 <cfengineuser> k
2020-08-14 16:17:43 <cfengineuser> crossing fingers
2020-08-14 16:19:12 <cfengineuser> woot!! no warning
2020-08-14 16:19:44 <cfengineuser> i wonder if it works now
2020-08-14 16:20:00 <cfengineuser> need start stop scripts
2020-08-14 16:23:37 <maxice8> is the distfiles moving process ongoing ?
2020-08-14 16:24:15 <maxice8> mopidy on x86_64 completed the tests and now just hanged :D
2020-08-14 16:24:26 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/mopidy/mopidy-3.0.2-r4.log
2020-08-14 16:24:35 <maxice8> harfbuzz fails on most arches (no logs though) after working on CI
2020-08-14 16:25:03 <nmeum> distfiles moving process?
2020-08-14 16:25:47 <maxice8> ncopa said may take an hour
2020-08-14 16:26:26 <ikke> He ran into some unrelated issues
2020-08-14 16:26:49 <maxice8> oh
2020-08-14 16:27:32 <ikke> checksum issue
2020-08-14 16:27:41 <ikke> :(
2020-08-14 16:27:45 <Hello71> isn't there already a tor package
2020-08-14 16:27:52 <nmeum> why where distfiles moved i mean
2020-08-14 16:27:53 <cfengineuser> ??
2020-08-14 16:28:00 <cfengineuser> i didn't see one
2020-08-14 16:28:09 <cfengineuser> i tried apk add tor
2020-08-14 16:28:11 <maxice8> community/tor/APKBUILD
2020-08-14 16:28:24 <nmeum> have you enabled the community repo?
2020-08-14 16:28:26 <maxice8> did you enable community repository ?
2020-08-14 16:28:34 <nmeum> (:
2020-08-14 16:28:38 <cfengineuser> i thought  id id
2020-08-14 16:29:01 <maxice8> did you run `apk update` after adding the community repo ?
2020-08-14 16:29:18 <cfengineuser> i thought i did
2020-08-14 16:29:29 <cfengineuser> its in /etc/apk/repositories
2020-08-14 16:32:33 <cfengineuser> i have it oh yeah its there
2020-08-14 16:32:50 <cfengineuser> didn't need to build it but i learned a lot
2020-08-14 16:32:59 <cfengineuser> thanks
2020-08-14 16:33:03 <cfengineuser> i have a few others
2020-08-14 16:36:22 <cfengineuser> well i was on the right track
2020-08-14 16:36:50 <cfengineuser> thanks again guys for being so welcoming
2020-08-14 16:38:58 <maxice8> welcome
2020-08-14 16:43:16 <nmeum> what's are current opinion on supervisor-daemon, do we like it? can I use it in busybox-initscripts?
2020-08-14 16:43:31 <nmeum> s/are/our/
2020-08-14 16:43:31 <alpine-meetbot> nmeum meant to say: what's our current opinion on supervisor-daemon, do we like it? can I use it in busybox-initscripts?
2020-08-14 16:43:33 <maxice8> ncopa asked to not add to busybox services as supervisor-daemon also consumes memory
2020-08-14 16:43:44 <maxice8> Let me see if I can dig the comment
2020-08-14 16:43:48 <nmeum> really? meh
2020-08-14 16:44:05 <nmeum> that would be nice :)
2020-08-14 16:44:28 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/1363#note_56289
2020-08-14 16:45:22 <nmeum> I will just leave a comment there, maybe it sparks a new discussion
2020-08-14 16:50:34 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/1363#note_108313
2020-08-14 16:50:38 <nmeum> my two cents on the matter
2020-08-14 16:56:26 <mps> nmeum: I don't like supervior
2020-08-14 16:56:30 <maxice8> I think it was around 75kB per instance
2020-08-14 16:57:15 <nmeum> mps: well, add a comment explaining your reasons to the thread so we discuss this in one place :p
2020-08-14 16:58:29 <mps> I'm out of normal net link, and till I come back I will probably forget
2020-08-14 16:58:42 <mps> normal net link*
2020-08-14 16:59:21 <nmeum> ok, what are your reasons then? I will just copy them to the thread
2020-08-14 17:00:11 <nmeum> puh, we need to fix this firefox-esr hang it's sooooo annoying
2020-08-14 17:00:56 <ikke> From memory: 'it should be the administrators choise to use supervisors, and you don't want to mask crashes and in that way help exploiting certain vulnerabilities'
2020-08-14 17:01:00 <ikke> mps: is that right?
2020-08-14 17:01:09 <mps> ikke: yes
2020-08-14 17:01:28 <mps> you have extra strong memory
2020-08-14 17:01:48 <nmeum> restart on crash is certainly debatable, from my perspective we can also configure it in a way that it doesn't restart on crash by default
2020-08-14 17:01:52 <mps> and big at the same time
2020-08-14 17:01:55 <nmeum> I am primarly intersted in getting rid of pidfiles
2020-08-14 17:04:12 <mps> nmeum: add one 'layer' to get rid of other (or fix problem) is not good solution, imo
2020-08-14 17:05:32 <nmeum> what layer? we are using a new program to solve on old problem (pid files)
2020-08-14 17:05:55 <nmeum> I think that's just a good example for unix philosophy
2020-08-14 17:06:48 <Cogitri> Getting rid of PID files seems super worth it
2020-08-14 17:10:19 <mps> yes, PID files removal is good idea
2020-08-14 17:15:56 <nmeum> well, we could probably patch openrc to add some global restart-on-crash configuration option for supervisor-daemon to /etc/rc.conf (if that doesn't exist already) and then only use it as an alternative to pidfiles by default or something along those lines
2020-08-14 17:21:55 <mps> well, this should be considered seriously and take into account possible problems, not just jump into it, imo ofc
2020-08-14 17:22:29 <nmeum> yes, of cause
2020-08-14 17:23:26 <nmeum> I can also send a mail to the ML, idk
2020-08-14 17:23:30 <nmeum> for further discussion that is
2020-08-14 17:24:20 <mps> good idea, (especially if we have ML which works as normal mailing lists)
2020-08-14 17:25:53 <nmeum> hm?
2020-08-14 17:30:19 <nmeum> mps: btw: how did you built firefox-esr without dbus?
2020-08-14 17:33:30 <mps> taking patch from kiss linux
2020-08-14 17:34:01 <mps> give me 5-10 minutes to install VPN and I will post you patch
2020-08-14 17:35:54 <nmeum> ok, thanks!
2020-08-14 17:37:08 <mps> nmeum: heh, old ssh over separate port works :) https://tpaste.us/adpm
2020-08-14 17:37:47 <mps> it is on firefox 79, not firefox-esr but it can be adapted easily I think
2020-08-14 17:41:29 <nmeum> ty
2020-08-14 17:43:34 <nmeum> only copied the dbus change, let's see if this fixes the annoying hang for me
2020-08-14 17:47:58 <c705> oh cool, so firefox is losing dbus?
2020-08-14 17:48:34 <maxice8> hopefully not, when I used to use gentoo compiling with dbus on musl increased responsiveness considerably
2020-08-14 17:48:47 <maxice8> In fact it was one of the performance tricks people thanked me for
2020-08-14 17:49:00 <dalias> how is dbus supposed to increase responsiveness?
2020-08-14 17:49:12 <maxice8> I don't know but it did
2020-08-14 17:49:35 <dalias> that sounds dubious, like maybe there was something else behind the change
2020-08-14 17:49:57 <maxice8> It was on Firefox 57 as far as I remember
2020-08-14 17:50:07 <maxice8> because it was long ago
2020-08-14 17:50:23 <dalias> but i dont see why "build without dbus" is being considered as a solution here
2020-08-14 17:50:36 <dalias> the bug in dbus is clear and known and needs to be fixed anyway because it will break other programs too
2020-08-14 17:50:47 <dalias> so just fix it and then the problem in firefox will go away
2020-08-14 17:51:30 <nmeum> I am only disabling dbus for my own firefox package
2020-08-14 17:52:24 <nmeum> regarding the firefox freeze: I think we are still unsure what exactly the root cause is
2020-08-14 17:53:50 <dalias> afaik, there are 2+ points where it's exactly the same cause: bad library code (dbus and pulseaudio) doing AS-unsafe stuff between fork and exec
2020-08-14 17:54:40 <dalias> if that doesn't seem to be the case for the hang you see now, please get a backtrace of everything at the time of hang
2020-08-14 17:54:56 <dalias> so we can see what code the deadlock is reached from
2020-08-14 18:11:39 <c705> dalias: it does cause other issues, I believe vlc is also affected (and probably any otehr prog using dbus)
2020-08-14 18:28:56 <Cogitri> Btw, what was the reason its (somewhat) safe on glibc and not musl?
2020-08-14 18:29:20 <Cogitri> I mean just so I can tell that upstreams that we aren't breaking their things because we feel like it
2020-08-14 19:20:42 <maxice8> status on the distfiles move ?
2020-08-14 19:21:13 <ikke> maxice8: status: weekend
2020-08-14 19:21:35 <ikke> I removed the harfbuz tar that causes issues, it's building now
2020-08-14 19:22:05 <maxice8> ty
2020-08-14 19:22:07 <ikke> distfiles have already been moved, so I guess we can say it's finished, but not sure if there were still things to do
2020-08-14 19:22:30 <ikke> buildlogs need to be adjusted though
2020-08-14 19:22:36 <maxice8> kcgi on armv7 also failing due to dists
2020-08-14 19:24:30 <ikke> I don't get it why suddenly these files are all corrupt
2020-08-14 19:25:59 <ncopa> im working on fixing the buildlogs
2020-08-14 19:26:04 <maxice8> ty
2020-08-14 19:27:26 <ikke> ncopa: are you sending to a dedicated domain now?
2020-08-14 19:27:29 <ikke> them*
2020-08-14 19:27:52 <ncopa> not yet
2020-08-14 19:27:54 <ikke> ok
2020-08-14 19:28:20 <ncopa> i figured that alpin.pw dns resolution does not seem to work from the builders
2020-08-14 19:28:27 <ncopa> and i dont ahve energy to troubleshoot
2020-08-14 19:28:51 <ncopa> previously all builders had .ssh/config entry for distfiles.alpinelinux.org
2020-08-14 19:28:51 <ikke> Yeah, noticed that as well, that internal dns is not completely functional yet everywhere
2020-08-14 19:29:01 <ncopa> pointing them to bld2 + special ssh port
2020-08-14 19:29:37 <ncopa> so i simply copied a new .ssh/config with hostname distfiles.alpinelinux.org + internal ip addr
2020-08-14 19:29:49 <ncopa> and have just finished adding the ip address to known hosts file
2020-08-14 19:29:53 <ncopa> on all builders
2020-08-14 19:29:59 <ncopa> so uploading buildlogs should work now
2020-08-14 19:30:00 <ikke> ah, right, that makes sense
2020-08-14 19:31:13 <ncopa> next step will be to fix internal dns, change aports-build default config to use buildlogs.alpin.pw, verify that config is updated on all builders and finally remove .ssh/config from all builders
2020-08-14 19:31:26 <ncopa> but i will not do that today
2020-08-14 19:31:34 <ncopa> now its weekend
2020-08-14 19:31:40 <ncopa> been a long day
2020-08-14 19:32:37 <ikke> thanks ncopa for all the work!
2020-08-14 19:32:45 <ncopa> libreoffice build hangs in my dev env on aarch64
2020-08-14 19:32:50 <ncopa> thank you for the patience
2020-08-14 19:33:39 <ncopa> i will try pop in here tomorrow and check the status. I would appreciate if someone could test if buildlogs appears on build.a.o/buildlogs on next git push(es)
2020-08-14 19:33:50 <ncopa> check all arches
2020-08-14 19:33:59 <ncopa> i see no reason why it shouldnt work, but you never know
2020-08-14 19:34:12 <ncopa> i'll try check how things goes tomorrow
2020-08-14 19:34:14 <ikke> ok
2020-08-14 19:34:36 <ncopa> we should probably also create a ticket for the bridge + arp issue
2020-08-14 19:34:50 <ncopa> it needs to be followed up. next reboot will make things stop
2020-08-14 19:36:28 <ikke> certainly
2020-08-14 19:43:06 <ncopa> are there any builders that complete at all at this point?
2020-08-14 19:43:14 <ncopa> edge builders
2020-08-14 19:43:43 <ncopa> looks like ppc64le, s390x and mips64 only
2020-08-14 19:44:01 <ncopa> the rest are either deadlocked or fails to complete
2020-08-14 19:44:13 <ncopa> we should try fix that next week
2020-08-14 19:44:39 <ikke> yup
2020-08-14 20:40:51 <maxice8> Did you know we were mispackaging py3-twisted ?
2020-08-14 20:42:27 <ikke> no
2020-08-14 20:42:29 <ikke> are we?
2020-08-14 20:42:34 <maxice8> yes
2020-08-14 20:42:40 <maxice8> the test in sitepackages is a legitimate module
2020-08-14 20:42:56 <maxice8> not an upstream error of packaging the testsuite (common mistake)
2020-08-14 20:45:37 <dalias> cogitri, glibc violates posix requirement that fork be AS-safe and makes it synchronize locks to give child a non-AS-restricted context
2020-08-14 20:45:47 <dalias> next issue of posix will drop this requirement
2020-08-14 20:47:01 <dalias> however there are fundamental limits that make it impossible for the child environment to be completely unrestricted
2020-08-14 20:47:31 <dalias> while you can do this for malloc locks and some other internal locks, you can't do it for stdio
2020-08-14 20:48:35 <dalias> the other ones are:
2020-08-14 20:50:07 <dalias> timezone, random, syslog, dlerror, gettext, pthread_atfork (held anyway at fork), sem_open, atexit, at_quick_exit, stdio open file list
2020-08-14 20:50:37 <dalias> i think all of those can be safely sync'd with fork if you drop the requirement for fork to be AS-safe
2020-08-14 20:52:56 <dalias> the issue of not being able to sync stdio FILE locks is amusing
2020-08-14 20:53:39 <dalias> if the child doesn't actually use any FILEs that other threads in the parent might have been accessing concurrently with fork, then it's *kinda* not-an-issue
2020-08-14 20:53:42 <dalias> however
2020-08-14 20:54:32 <dalias> (1) on glibc, attempt to read input from a line-buffered stream forces flush of all line-buffered output streams. this means it will deadlock if parent was using/blocked-on any FILEs at fork time
2020-08-14 20:54:59 <dalias> (2) exit() inherently syncs with all FILEs, so you cannot call exit() in the child if any FILE was in use in parent at moment of fork
2020-08-14 20:57:05 <c705> dalias: if posix is dropping this requirement, doen't that mean musl is screwed unless they handle that requirement?
2020-08-14 20:59:30 <dalias> no
2020-08-14 20:59:39 <Cogitri> dalias: Ok, thanks for the answer
2020-08-14 20:59:58 <dalias> posix is not removing the restriction on the application, that the child can only call AS-safe functions
2020-08-14 21:00:06 <dalias> only the requirement that fork be AS-safe
2020-08-14 21:00:15 <dalias> this allows but does not require an implementation with the glibc properties
2020-08-14 21:00:25 <c705> ah
2020-08-14 21:00:52 <dalias> if it's doing one perhaps it should do both (and not doing so might be an oversight)
2020-08-14 21:01:06 <dalias> however as described above it's hard to actually specify the reduced restriction
2020-08-14 21:01:16 <dalias> you fundamentally *can't* make it so the child can do unrestricted stuff
2020-08-14 21:01:43 <dalias> because of the stdio issue
2020-08-14 21:08:16 <z3ntu> Replying to GitLab emails seem broken
2020-08-14 21:08:20 <z3ntu> <gitlab@alpinelinux.org>: host mail.alpinelinux.org[147.75.101.119] said: 550
2020-08-14 21:08:20 <z3ntu>     virtual alias table (in reply to RCPT TO command)
2020-08-14 21:08:20 <z3ntu>     5.1.1 <gitlab@alpinelinux.org>: Recipient address rejected: User unknown in
2020-08-14 21:09:25 <z3ntu> Actually it seems like a bogus bounce, the reply arrived /shrug
2020-08-14 21:09:37 <maxice8> ty for the ok
2020-08-15 09:34:07 <gjabell> I think !11386 and !11383 are both ready for merge
2020-08-15 17:46:43 <ikke> Any idea how to disable '-Werror=deprecated-declarations'
2020-08-15 17:46:47 <ikke> on a QT project?
2020-08-15 17:47:08 <ikke> Gives a few deprecated errors, but I don't see that as our problem to fix
2020-08-15 17:47:28 <ikke> libmlocale in this case
2020-08-15 17:47:58 <dalias> grep -r for it and remove? :)
2020-08-15 17:48:30 <dalias> indeed this kind of developer-focused -Werror has no place in public build scripts
2020-08-15 17:48:45 <dalias> some -Werrors are legitimate errors and ok to have there
2020-08-15 17:48:45 <ikke> I tried that :)
2020-08-15 17:48:52 <ikke> but couldn't find it
2020-08-15 17:48:57 <dalias> really??
2020-08-15 17:49:06 <dalias> it's gotta be somewhere
2020-08-15 17:49:16 <dalias> grep -r deprecated-declarations .
2020-08-15 17:49:23 <dalias> at top level of source
2020-08-15 17:49:26 <ikke> Maybe some QT defaults
2020-08-15 17:49:31 <dalias> maybe?
2020-08-15 17:49:42 <ikke> QTDIR=/usr/lib/qt5 ./configure
2020-08-15 17:49:46 <dalias> but doesn't QT generate some sort of makefile or something?
2020-08-15 17:50:00 <dalias> ah if it's configure based then it should be in the output Makefile no?
2020-08-15 17:50:11 <ikke> /usr/lib/qt5/mkspecs/features/qt_common.prf
2020-08-15 17:51:36 <ikke> I tried passing -no-werror to configure, but that doesn't get rid of this
2020-08-15 17:52:22 <dalias> where are the bad declarations coming from?
2020-08-15 17:52:30 <dalias> also there's no such option to configure
2020-08-15 17:52:33 <dalias> it would be --disable-werror
2020-08-15 17:53:04 <ikke> it was in the --help output of the specific configure script in the project
2020-08-15 17:53:10 <dalias> eeew
2020-08-15 17:53:18 <dalias> so this is some nasty configure script not doing standard interface
2020-08-15 17:53:21 <dalias> i hate those
2020-08-15 17:53:28 <dalias> anyway it's not in the output makefile ?
2020-08-15 17:53:50 <dalias> strace and see what process opens that qt_common.prf
2020-08-15 17:53:55 <dalias> and look for ways to configure it
2020-08-15 17:54:03 <ikke> no
2020-08-15 17:54:17 <dalias> ?
2020-08-15 17:55:27 <ikke> It's not part of the Makefile
2020-08-15 18:23:04 <Ariadne> qmake unfortunately declares a ton of -Werror
2020-08-15 18:23:18 <Ariadne> if you build it as a 'production' build i think it disables that stuff
2020-08-15 18:23:54 <ikke> Ariadne: -release?
2020-08-15 18:24:06 <Ariadne> yes
2020-08-15 18:24:10 <Ariadne> that
2020-08-15 18:24:41 <maxice8> <ikke "Gives a few deprecated errors, b"> sed -i 's|-Werror||g' $path_to_pro
2020-08-15 18:24:44 <ikke> doesn't make a difference
2020-08-15 18:24:56 <maxice8> huh, it was what I saw arch doing
2020-08-15 18:25:15 <ikke> that was regarding what Ariadne proposed
2020-08-15 18:25:48 <ikke> so just disable warning as errors
2020-08-15 18:26:10 <ikke> ok, that can work
2020-08-15 18:26:40 <Ariadne> weird -release should be doing that, too.
2020-08-15 18:26:52 <ikke> and apparent -no-werror as well
2020-08-15 18:26:55 <Ariadne> oh well, this is why i hate qmake
2020-08-15 18:29:47 <ikke> hmm, there is another Makefile in src/ that contains -Werror
2020-08-15 18:29:51 <Cogitri> Better than qbs I guess :D
2020-08-15 18:30:33 <ikke> removing -Werror from there helps
2020-08-15 18:31:31 <Ariadne> honestly, qbs is crap too, as is cmake
2020-08-15 18:31:43 <Ariadne> it would be nice if these people would standardise on meson
2020-08-15 18:31:54 <Ariadne> meson.build files are actually readable
2020-08-15 18:31:57 <maxice8> I like your words
2020-08-15 18:44:38 <maxice8> I think x86_64 builder is still stuck in mopidy
2020-08-15 18:45:08 <ikke> maxice8: will take al ook
2020-08-15 18:45:13 <ikke> a look as well
2020-08-15 18:45:13 <maxice8> thanks
2020-08-15 18:51:30 <ikke> libreoffice on aarch64 was stuck as well
2020-08-15 18:57:46 <ikke> looking at py3-sikit-optimize
2020-08-15 19:06:08 <Cogitri> Ariadne: +1, meson's nice
2020-08-15 19:29:12 <ikke> I have one failure left for scikit-optimizez
2020-08-15 19:29:43 <ikke> https://tpaste.us/yZMe
2020-08-15 20:18:22 <ikke> chez-scheme: sizeof(time_t) * 8 [8] != time_t_bits [32]
2020-08-15 20:18:49 <ikke> that's obviously wrong with a 64 bits time_t
2020-08-15 20:50:14 <dalias> why does it expect 32 ?
2020-08-15 20:53:06 <ikke> I have no idea
2020-08-15 20:53:33 <ikke> it's in a function called idiot_checks()
2020-08-15 20:56:01 <ikke> seems like there are some static defines per platform or something like that
2020-08-15 20:56:50 <dalias> eew
2020-08-15 20:56:56 <dalias> so i guess they need to be fixed
2020-08-15 20:58:12 <ikke> #define time_t_bits 0x40
2020-08-15 20:58:59 <ikke> in files like boot/ta6le/equates.h
2020-08-15 20:59:09 <dalias> if they're going to probe that it matches why don't they just probe to get the right value?
2020-08-15 21:00:19 <ikke> I have no clue :)
2020-08-15 21:00:52 <ikke> Probably they want to make sure the world matches their assumptions
2020-08-15 21:01:42 <dalias> i can't find time_t_bits searching the repo on github
2020-08-15 21:02:35 <ikke> https://github.com/cisco/ChezScheme/blob/master/boot/ta6le/equates.h#L634
2020-08-15 21:02:58 <ikke> https://github.com/cisco/ChezScheme/blob/master/c/scheme.c#L221
2020-08-15 21:12:03 <ikke> I created a ticket for the maintainer of that package btw
2020-08-15 21:24:46 <ikke> https://github.com/cisco/ChezScheme/issues/297 doesn't give much hope from upstream
2020-08-15 21:57:04 <maxice8> hooray, harfbuzz-2.7.1 was finally built
2020-08-16 00:26:28 <dalias> 0x40 is the right value tho (64)
2020-08-16 00:26:34 <dalias> albeit wrongly being hard-coded
2020-08-16 00:26:38 <dalias> so why is it breaking?
2020-08-16 00:27:17 <dalias> ah there are other files
2020-08-16 00:27:52 <dalias> apparently they have some broken platform files called "i3le", "i3nt", "i3osx" etc.
2020-08-16 00:27:57 <dalias> i3 = intel 32bit ?
2020-08-16 00:29:50 <dalias> eew this whole codebase looks like utter shit
2020-08-16 00:31:16 <dalias> afaict it supports nothing but i386, x86_64, arm, and ppc
2020-08-16 00:32:23 <dalias> i would just patch it, but eew
2020-08-16 00:32:38 <dalias> le = linux elf i guess
2020-08-16 00:32:43 <dalias> their naming convention is so awful
2020-08-16 00:33:11 <dalias> nb=netbsd, ob=obsd, osx=osx, s2=solaris, nt=windows
2020-08-16 00:33:59 <dalias> the cisco/ should be all you need to know about why this is crap..
2020-08-16 00:36:33 <dalias> it may actually be harder -- they may be defining an ABI for binaries in this awful scheme for each of these names
2020-08-16 00:36:44 <dalias> in which case you just can't change it, but have to trash their old abi and make a new one
2020-08-16 00:36:57 <dalias> and will be unable to use their shipped binaries
2020-08-16 00:40:15 <dalias> it seems they actually have some awful FFI stuff going on
2020-08-16 08:52:00 <gjabell> Cogitri: thanks for the feedback on khard, should be ready to merge now
2020-08-16 18:23:08 <Cogitri> Do we have a guide for setting up a cross env?
2020-08-16 18:23:21 <Cogitri> Wanted to look into Ariadne's request of making Rust cross-able
2020-08-16 18:23:37 <dalias> crossable = ?
2020-08-16 18:23:53 <dalias> do you mean able to cross-compile rust itself, or just able to use rust as a cross-compiler?
2020-08-16 18:24:57 <Cogitri> To bootstrap Rust for new arches
2020-08-16 18:25:59 <dalias> :) :) :)
2020-08-16 20:43:44 <Ariadne> Cogitri: yes let's look into that this week :)
2020-08-16 20:44:34 <Cogitri> 👍
2020-08-16 20:47:36 <Cogitri> Ariadne: Also, someone posted to the ML about porting Alpine to longsoon mips, maybe you want to take a look at that
2020-08-16 20:50:16 <ikke> 3 times (:
2020-08-16 21:12:30 <Hello71> but did you see that email about porting Alpine to loongson mips
2020-08-16 21:13:16 <ikke> I think I've missed it
2020-08-16 21:21:01 <Ariadne> Cogitri: yes, unfortunately i am not certain that we want to do a mips64el port yet
2020-08-16 21:21:19 <Ariadne> i would like to get mips64 port into healthier state before pursuing one for loongson
2020-08-16 21:23:11 <Ariadne> Cogitri: planning to reply on monday.  the requirements have not changed, we need somebody (this could be loongson) to sponsor a builder, and maintain it.  they offered to send me a builder, but current US policies make it impossible for me to accept their builder.
2020-08-16 21:23:45 <Ariadne> Cogitri: i am planning to move to netherlands later this year, so when that happens i could accept their builder and colo it with the other mips64 builder.
2020-08-16 23:41:14 <maxice8> Another distfiles fetch failure
2020-08-16 23:41:36 <maxice8> affecting armhf armv7 ppc64le x86, any ETA for fix ?
2020-08-17 00:50:37 <terror> System is in a weird state, where it has python 3 but says world is broken python missing
2020-08-17 00:50:45 <terror> Doesn't python3
2020-08-17 00:50:52 <terror> provides python?
2020-08-17 04:15:48 <maxice8> no, you must explicitly pick which python you want
2020-08-17 05:40:58 <ikke> maxice8: I suspect these are remnants
2020-08-17 05:42:18 <maxice8> <ikke "maxice8: I suspect these are rem"> Anything I can do?
2020-08-17 05:51:56 <ikke> maxice8: keep reporting them
2020-08-17 05:52:06 <ikke> Which package?
2020-08-17 05:52:18 <maxice8> Hiredis
2020-08-17 05:52:28 <maxice8> Build.a.o should show it failing
2020-08-17 05:52:37 <ikke> yes, I see it
2020-08-17 05:52:49 <ikke> note that distfiles is arch-independant, so it will fail for all arches
2020-08-17 05:54:09 <ikke> algitbot: retry master
2020-08-17 05:56:14 <ikke> I'm still puzzled why this even happened in the first place though
2020-08-17 05:57:05 <ikke> hmm, hiredis was just pushed, so that could not have been a remnant
2020-08-17 05:57:28 <ikke> ncopa: ^
2020-08-17 06:41:26 <maxice8> mopidy is hanging on x86_64 yet again
2020-08-17 06:41:28 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/mopidy/mopidy-3.0.2-r4.log
2020-08-17 06:41:32 <maxice8> it finishes tests, prints OK
2020-08-17 06:41:34 <maxice8> then does nothing
2020-08-17 06:42:07 <ikke> ugh
2020-08-17 06:43:27 <ikke> Seems like a deadlock, all processes are waiting on a futex
2020-08-17 06:44:14 <ikke> https://tpaste.us/Qnp4
2020-08-17 06:45:09 <ikke> Is this again some non-as safe functions after fork?
2020-08-17 07:36:34 <maxice8> libmdf failing on armv7 due to distfiles
2020-08-17 08:39:57 <Ariadne> ikke: yes, likely.
2020-08-17 08:48:32 <Ariadne> anyway, we have had a lot of success testing ifupdown-ng with customers and it is already default in our downstream distribution
2020-08-17 09:18:03 <Thermi> Cogitri: Please take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569 again, I had some questions regarding your criticism.
2020-08-17 09:19:05 <dne> I'm seeing https://gitlab.alpinelinux.org/alpine/aports/-/issues/11345 on current edge (when PAGER=less but less is not installed)
2020-08-17 09:19:42 <dne> the merged fix looks ok though
2020-08-17 09:28:20 <Cogitri> Thermi: I can try taking a look later
2020-08-17 09:28:27 <Thermi> Cogitri: ty
2020-08-17 09:33:02 <maxice8> Guess who's back
2020-08-17 09:33:07 <maxice8> back again, mopidy is back
2020-08-17 09:33:17 <maxice8> x86_64 stuck because of it
2020-08-17 09:34:47 <Cogitri> I guess we should just disable it for now
2020-08-17 09:39:09 <ncopa> hi
2020-08-17 09:39:26 <Cogitri> Morning
2020-08-17 09:41:07 <ncopa> Ariadne: i think i have a usecase i'd like to test for ifupdown-ng: more than one ipv6 address
2020-08-17 09:42:34 <ncopa> a friend had a problem with busybox ifupdown with a static ipv6 + a secondary ipv6 address. ifdown would not flush the ipv6 address and exit state is non-zero (fail) so ifupdown think interface is still up
2020-08-17 09:50:39 <Ariadne> that is a good one.  we have a couple of scenarios like that in the testsuite already
2020-08-17 09:55:00 <ncopa> is it in a release already?
2020-08-17 09:55:14 <Ariadne> yeah 0.7
2020-08-17 09:55:23 <ncopa> i was thinking that if that scenario works, we could even backport it to 3.12
2020-08-17 09:56:20 <Ariadne> well the testsuite verifies the commands are emitted in right order.  I can manually test the scenario in a container
2020-08-17 10:37:49 <ncopa> how would you do a dhcp ipv4 address with a secondary static ip?'
2020-08-17 10:37:57 <ncopa> in the interfaces file
2020-08-17 10:40:00 <ncopa> i think currently the way to do it is:
2020-08-17 10:40:03 <ncopa> iface eth0 inet dhcp
2020-08-17 10:40:03 <ncopa> 3
2020-08-17 10:40:03 <ncopa>     up ip addr add 192.168.8.5/24 dev $IFACE
2020-08-17 11:42:10 <Ariadne> iface eth0
2020-08-17 11:42:12 <Ariadne> use dhcp
2020-08-17 11:42:16 <Ariadne> address ...
2020-08-17 11:42:19 <Ariadne> :)
2020-08-17 11:42:50 <Ariadne> address there can be either v4 or v6
2020-08-17 11:43:05 <Ariadne> and you can have as many as you want
2020-08-17 11:43:30 <Ariadne> I'll write some docs about that later this week
2020-08-17 11:45:22 <ncopa> sounds great. exactly what i hoped for. a simple README doc should be enough i guess
2020-08-17 11:46:38 <ncopa> Ariadne: did you look into fix libvirtd? There are other cases of close all fds after fork that deadlocks
2020-08-17 11:47:18 <ncopa> i started with an implementation using poll for libvirtd some days ago but never finished
2020-08-17 11:47:27 <Ariadne> I did a little, I can finish this week
2020-08-17 11:47:43 <Ariadne> I wish we had closefrom(2) on Linux.  that is the obvious way.
2020-08-17 11:47:49 <ncopa> do you have a poll based implementation done?
2020-08-17 11:48:06 <ncopa> yeah, closefrom is what we'd need
2020-08-17 11:48:31 <Ariadne> not yet.  but will work on it this week.
2020-08-17 11:48:46 <Ariadne> did talk to some RH virt contacts about it tho
2020-08-17 11:51:05 <ncopa> i think we need to come up with a general closefrom() like implementation. bumped into exact same issue in openjdk: https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/childproc.c#L82
2020-08-17 11:51:18 <ncopa> the opendir will do malloc which deadlocks
2020-08-17 11:51:32 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11861
2020-08-17 11:56:58 <ikke> I think libreoffice deadlocked again on aarch64
2020-08-17 11:57:33 <ncopa> it is due to #11861
2020-08-17 11:57:37 <ikke> yes
2020-08-17 12:53:25 <dne> re: closefrom(2): https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-Close-Range
2020-08-17 12:57:22 <ncopa> oh, thats interesting!
2020-08-17 13:05:05 <dne> merged here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.9-rc1&id=4f30a60aa78410496e5ffe632a371c00f0d83a8d
2020-08-17 13:38:56 <PureTryOut[m]> `configure: error: cannot guess build type; you must specify one`
2020-08-17 13:38:57 <PureTryOut[m]> Any clue what I can do about that?
2020-08-17 13:38:57 <PureTryOut[m]> It's an autotools build system and only happens on ppc64le
2020-08-17 13:39:40 <maxice8> I left a message
2020-08-17 13:39:50 <maxice8> update_sub_guess
2020-08-17 13:40:28 <PureTryOut[m]> You said update_config_guess though, which only worsened things 😛
2020-08-17 13:44:12 <maxice8> then I guess autoreconf -fi will fix it
2020-08-17 13:57:09 <mps> Cogitri: I see you your mails related to me, but I will be 'on work' in about 10 days
2020-08-17 14:01:25 <Cogitri> Okie 👍
2020-08-17 14:05:29 <PureTryOut[m]> maxice8: that last one does seem to do the trick indeed, thanks!
2020-08-17 14:23:33 <ikke> mono build is failing on x86, due to some files missing / not generated?
2020-08-17 14:53:37 <ikke> clandmeter: do you mind emby being disabled on x86 for the time being? mono does not build atm
2020-08-17 14:55:06 <ncopa> Ariadne: i do have a close_fds(from_fd, max_fd) function done now. Will test performance on rpi3
2020-08-17 15:03:33 <ncopa> interesting. my pc engines apu2b4 was slower than rpi3 with ulimit -n 1M
2020-08-17 15:04:01 <ncopa> took ~ half second to loop over 1M filehandles
2020-08-17 15:08:20 <detha> Sounds like a test where syscall overhead becomes significant
2020-08-17 15:08:45 <ncopa> https://gist.github.com/ncopa/b4f0dcb52eb992d0edda14d0fabf33a4
2020-08-17 15:17:51 <Hello71> mitigations=off?
2020-08-17 15:19:29 <PureTryOut[m]> Wait, we have emby in the repos? Didn't that go proprietary a while ago? Jellyfin is the FOSS fork
2020-08-17 15:19:44 <maxice8> x86_64 and x86 on testing
2020-08-17 15:19:48 <maxice8> 3.0.5911
2020-08-17 15:25:15 <PureTryOut[m]> Oh wait that's a really old version, I guess that is FOSS still then
2020-08-17 15:25:25 <PureTryOut[m]> Still, maybe some effort should be put into replacing it with Jellyfin
2020-08-17 15:25:44 <PureTryOut[m]> (it's a TIL for me that there is mono stuff at all on Alpine)
2020-08-17 15:25:46 <PureTryOut[m]> Do we have .NET Core available actually?
2020-08-17 15:28:27 <Ariadne> ncopa: sounds good
2020-08-17 15:29:07 <Ariadne> PureTryOut[m]: there is some interest in having it, but the .net core guys prefer to ship their own repo for alpine
2020-08-17 15:29:34 <PureTryOut[m]> Ah, darn
2020-08-17 15:30:42 <Ariadne> PureTryOut[m]: maybe have a new conversation about it I guess
2020-08-17 15:31:51 <Ariadne> this telegram group is trying to claim to be officially related to alpine and is posting qanon crap.  what do?
2020-08-17 15:32:14 <Ariadne> I've already asked them to clarify that they are NOT officially affiliated with us
2020-08-17 15:33:00 <PureTryOut[m]> Maybe you can report it to Telegram?
2020-08-17 15:35:12 <Ariadne> at present, i am just requesting they do so in a friendly way, but i have mentioned that would be the next step for us if they do not clarify their (lack of) relationship with the project and stop using our marks in an official way
2020-08-17 15:35:38 <Ariadne> there are people joining it who think it is official too, it is quite frustrating :(
2020-08-17 15:36:09 <ncopa> how do i join?
2020-08-17 15:36:15 <maxice8> I think it is best to report it to telegram and hope they do it
2020-08-17 15:36:33 <Ariadne> it is that PICCORO person who runs it
2020-08-17 15:36:43 <ncopa> ugh..
2020-08-17 15:36:44 <ikke> fun
2020-08-17 15:36:46 <Cogitri> Oof
2020-08-17 15:36:47 <maxice8> Oh lol
2020-08-17 15:36:57 <ikke> I don't think this is it, right? https://t.me/alpinelinux
2020-08-17 15:37:01 <Ariadne> https://t.me/alpine_linux_english
2020-08-17 15:37:08 <Ariadne> it is this one, but that one is related too
2020-08-17 15:38:04 <Ariadne> the discord, on the other hand, has always made it clear that it is unofficial.  i was hoping that we could have the situation here
2020-08-17 15:38:59 <ncopa> Ariadne: i can try send an email to piccoro. do you have screenshot or something?
2020-08-17 15:39:09 <ncopa> should I ask him to not use our logo?
2020-08-17 15:39:39 <Ariadne> this person is on the irc as mckaygarhard
2020-08-17 15:40:42 <Ariadne> he has requested that we tell him in our IRC to "verify" the request
2020-08-17 15:42:56 <Ariadne> it is kind of ridiculous honestly.
2020-08-17 15:43:51 <Ariadne> all i asked, one time, was to simply clarify that the groups he created were not officially run by the project, because he runs them in a way that we would likely find problematic
2020-08-17 15:44:06 <ncopa> do we know who is behind the https://t.me/alpinelinux?
2020-08-17 15:44:16 <ncopa> i guess we better set up an official group
2020-08-17 15:44:19 <Ariadne> and now he has spent the day throwing a tantrum and messaging me :)
2020-08-17 15:44:52 <Ariadne> i think that is a telegram reserved group
2020-08-17 15:45:06 <ncopa> can we request it somehow?
2020-08-17 15:45:17 <Ariadne> they reserved a lot of group names when they launched groups, to prevent this kind of impersonation
2020-08-17 15:45:47 <Ariadne> i guess contact telegram support
2020-08-17 15:46:10 <clandmeter> ikke: I think you can just disable it
2020-08-17 15:46:26 <clandmeter> It's old and I'm not sure it's still maintained
2020-08-17 15:47:22 <PureTryOut[m]> > i guess we better set up an official group
2020-08-17 15:47:41 <PureTryOut[m]> Do we want to support Telegram?
2020-08-17 15:47:51 <PureTryOut[m]> A chat application with a proprietary backend?
2020-08-17 15:48:08 <PureTryOut[m]> Having a FOSS client for it in the repositories is something entirely different than promoting it's use by having an official support chat in it
2020-08-17 15:48:44 <Cogitri> And I don't think having multiple means of communication is good, it just splits the community
2020-08-17 15:49:01 <Ariadne> traditionally, we have not wanted to do so.  however, this has resulted in other people filling the void
2020-08-17 15:49:08 <Ariadne> so, i don't know
2020-08-17 15:49:18 <Ariadne> i'll let ikke deal with it <3
2020-08-17 15:49:26 <ikke> :D
2020-08-17 15:50:01 <maxice8> -1 for supporting telegram and considering anything proprietary
2020-08-17 15:50:16 <Ariadne> all i know is i got some blast from that group to my phone about tiktok and some qanon conspiracy shite
2020-08-17 15:50:27 <Ariadne> and i am like wow this has fuck all to do with alpine
2020-08-17 15:53:50 <Ariadne> haha he did it as soon as ikke joined
2020-08-17 15:54:48 <ncopa> let me put it this way, i'd rather have someone i trust to manage a (semi) official group
2020-08-17 15:55:03 <ncopa> than someone untrusted that claims it to be official
2020-08-17 15:55:18 <ncopa> i asekd him in private irc as well
2020-08-17 15:57:01 <Ariadne> right, i think that is a reasonable position
2020-08-17 15:57:15 <Ariadne> (i'm not interested in running any such things, don't ask me :()
2020-08-17 15:57:36 <ncopa> thats totally fine
2020-08-17 15:58:14 <PureTryOut[m]> Ugh I have a x86 CI job that just keeps segfaulting...
2020-08-17 16:02:06 <Cogitri> https://gitlab-test.alpinelinux.org/alpine/aports/-/merge_requests/7310#note_108006 <- This is the new message that's posted to stale MRs after 4 weeks (if they don't have the status:mr-hold label) the gitlab bot currently uses,  do you think that's OK?
2020-08-17 16:02:36 <Cogitri> (Of course it'll be posted by a separate bot user and not me in the final thing=
2020-08-17 16:04:49 <ncopa> Cogitri: will it be marked as stale when we (maintainers) are unresponsive, or only when the contributor is
2020-08-17 16:06:07 <Cogitri> Right now it just marks it after 4 weeks of inactivity (no comments/commits/new labels), doesn't matter who is inactive.
2020-08-17 16:06:36 <Cogitri> Then coredevs can see it because of the status:mr-stale label (and maybe take another look/close it) and users get an email so maybe they remember the MR and work on it again
2020-08-17 16:06:52 <Cogitri> Or if no one reviewed it yet they can ping @developers, as mentioned in the message
2020-08-17 16:07:01 <ncopa> ok. i just find it a bit rude to close it as stale if its *our* fault, that we are unresponsive
2020-08-17 16:07:03 <Cogitri> At least that's my thinking here, maybe we should do something else :)
2020-08-17 16:07:15 <ncopa> we had something simliar in github
2020-08-17 16:07:36 <Cogitri> Yup, that might be a bit demotivating when the user isn't the one responsible for the MR being stale, but I'm not sure what we should do then
2020-08-17 16:07:44 <ncopa> i think the message in gihub was more of an apology
2020-08-17 16:08:48 <ncopa> ah, we still have it, in .github/stale.yaml
2020-08-17 16:09:26 <Cogitri> Ah, I'll take a look at that, thanks :)
2020-08-17 16:09:50 <Cogitri> Another thing: Do we want the status:mr-stale label to also be auto-removed?
2020-08-17 16:10:07 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/.github/stale.yml#L15
2020-08-17 16:10:08 <Cogitri> If a MR is stale for that long it might be best if a dev takes another look at it and then closes the MR/gives tips & remove the label
2020-08-17 16:10:59 <ncopa> i think a rebase can autoremove  a stale label
2020-08-17 16:11:50 <Cogitri> Ok 👍️
2020-08-17 16:12:37 <ncopa> thank you for working on that. appreciate
2020-08-17 16:13:09 <Cogitri> :)
2020-08-17 17:01:48 <ncopa> maxice8: do you mind if I move paxctl back to main (or community) https://github.com/alpinelinux/docker-alpine/issues/106
2020-08-17 18:00:51 <ikke> fyi: I'm going to upgrade gitlab to 13.1, it will be unavailable for a brief moment
2020-08-17 18:03:02 <Cogitri> 👍
2020-08-17 18:05:39 <ikke> And it's up again
2020-08-17 18:05:59 <ikke> Let us know if anything is not working properly
2020-08-17 18:32:12 <ikke> "string sub-command REGEX, mode MATCH needs at least 5 arguments total to
2020-08-17 18:32:17 <ikke> command.
2020-08-17 18:32:19 <ikke> "
2020-08-17 18:34:39 <ikke> Anyone know enough cmake?
2020-08-17 18:34:54 <ikke> string(REGEX MATCH "^[0-9]+" LIBZIP_VERSION_MAJOR ${libzip_VERSION})
2020-08-17 18:36:48 <ikke> I suspect that libzip_VERSION is not defined
2020-08-17 19:31:39 <ikke> Ok, it required quotes
2020-08-17 19:31:48 <ikke> string(REGEX MATCH "^[0-9]+" LIBZIP_VERSION_MAJOR "${libzip_VERSION}") works
2020-08-17 19:33:09 <ikke> ugh
2020-08-17 19:33:13 <ikke> now linking errors :-/
2020-08-17 19:33:18 <Cogitri> I think that should only make a difference if the var isn't defined
2020-08-17 19:33:24 <ikke> it was defined..
2020-08-17 19:33:59 <Cogitri> Huh
2020-08-17 19:34:08 <ikke> maybe in a different scope/
2020-08-17 19:34:09 <ikke> ?
2020-08-17 19:35:37 <ikke> I've added variable_watch(libzip_VERSION) near the top of CMakeLists.txt, and I saw that it had a value
2020-08-17 19:36:11 <Cogitri> Ah, I'd just put a message(ERROR libzip_VERSION) above the regex thingie
2020-08-17 19:36:48 <ikke> ok, will try
2020-08-17 19:37:51 <ikke> Should I use ${libzip_VERSION} there?
2020-08-17 19:38:20 <ikke> yeah, it's empty indeed
2020-08-17 19:38:58 <Cogitri> CMake is great fun :^)
2020-08-17 19:39:18 <ikke> wheej
2020-08-17 19:41:27 <ikke> https://tpaste.us/DDyX
2020-08-17 19:42:00 <ikke> I'll just disable the package
2020-08-17 21:02:40 <maxice8> @ncopa preferably community
2020-08-17 21:06:25 <Cogitri> Oh heh, was for a sec confused that we have the new fancy reviewing tools now on Gitlab
2020-08-17 21:06:39 <Cogitri> Thanks for the upgrade, ikke & clandmeter :)
2020-08-17 21:08:31 <ikke> yw :)
2020-08-17 21:19:18 <ikke> mps: dovecot is failing on 3.12 (test with NTLM fails)
2020-08-17 21:55:21 <mps> ikke: yes, I know. I told here that before I left.
2020-08-17 21:56:30 <mps> though it pass in lxc with patch added on edge
2020-08-17 21:57:03 <mps> with patch for 3.12, I mean
2020-08-17 21:57:55 <mps> as you know I can't  do anything about this problem till next week
2020-08-18 01:25:15 <maxice8> @Ikke https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/fwup/fwup-1.8.1-r0.log
2020-08-18 05:25:14 <ikke> maxice8: hmm, I see what's on distfiles has the same hash as what I download from github
2020-08-18 05:26:16 <ikke> https://tpaste.us/BjNk
2020-08-18 05:36:52 <ncopa> morning
2020-08-18 05:37:07 <ikke> morning
2020-08-18 05:37:31 <ikke> I consistently get the same sha512sum for fwup
2020-08-18 05:38:13 <ikke> which matches what's in the APKBUILD
2020-08-18 05:38:55 <ikke> ok, fwup passed the build
2020-08-18 05:39:01 <ikke> maxice8: what were you refering to?
2020-08-18 05:40:07 <[[sroracle]]> log may have been replaced in the meantime
2020-08-18 05:40:28 <ikke> yes
2020-08-18 05:48:03 <ncopa> i am hoping that i finally solved the deadlock in libreoffice build
2020-08-18 05:57:59 <ikke> 
ACTION hopes with ncopa

2020-08-18 06:15:15 <ikke> sslscan fails on armv7 with 'undefined reference to `ENGINE_load_gost'
2020-08-18 06:15:35 <ikke> but it succeeds on x86_64
2020-08-18 06:16:25 <dalias> some library not updated?
2020-08-18 06:24:41 <ikke> hmm, it fails in my armv7 build container with message about unsupported cpu instructions
2020-08-18 06:26:19 <ikke> arm64cpuid.S:4: Error: unknown architecture `armv8-a+crypto'
2020-08-18 06:37:10 <ikke> package has no maintainer, I just disabled it
2020-08-18 06:37:13 <ikke> on armv7
2020-08-18 06:39:09 <dalias> :/
2020-08-18 06:39:48 <dalias> why does sslscan have its own (crypto?) asm ?
2020-08-18 06:40:11 <ikke> I have no clue
2020-08-18 06:40:22 <ikke> Hmm
2020-08-18 06:40:25 <ikke> I think it's building openssl
2020-08-18 06:40:39 <ikke> there is a bundled (submodule) openssl as well
2020-08-18 06:42:19 <dalias> ....
2020-08-18 06:42:21 <dalias> uhg
2020-08-18 06:42:41 <dalias> so the solution is just to disable that
2020-08-18 06:43:11 <ikke> and add openssl-dev as a depedency
2020-08-18 06:43:27 <dalias> -dev as build dep, yes
2020-08-18 06:44:00 <ikke> hmm, I think it's done deliberaly
2020-08-18 06:44:03 <ikke> deliberately
2020-08-18 06:44:10 <ikke> "ld: ../libcrypto.a(eng_all.o): in function `ENGINE_load_builtin_engines':
2020-08-18 06:44:12 <ikke> arg
2020-08-18 06:44:27 <ikke> "# To compile against the openssl lib with insecure protocols enabled"
2020-08-18 06:47:40 <ikke> they statically link against a modified openssl
2020-08-18 06:51:19 <dalias> ahh..
2020-08-18 06:51:33 <dalias> then it should be built with --disable-asm or whatever
2020-08-18 06:51:58 <dalias> since the arch-specific/asm build machinery is always broken and unreliable to build on targets the developer has not personally tested on
2020-08-18 06:53:47 <ikke> it did work at some point though
2020-08-18 06:54:06 <ikke> but as no one is maintainging the package, and it's in testing, I don't want to spend too much time on it
2020-08-18 06:55:40 <dalias> *nod*
2020-08-18 09:11:35 <ikke> maxice8: synapse is failing (modules missing during tests)
2020-08-18 09:14:24 <maxice8> Dammit
2020-08-18 09:48:16 <ncopa> any ideas how to solve the dovecot issue that is blocking 3.12 builders?
2020-08-18 09:48:38 <ncopa> it seems that the MR for edge is different than what was pushed to 3.12-stable
2020-08-18 09:49:18 <ncopa>  !11360 vs cd32bb7c9ac2d8af16970953f142ac37b57932b9
2020-08-18 09:54:08 <ikke> That may explain why it succeeded on CI but not on the builders?
2020-08-18 10:03:04 <ncopa> no idea
2020-08-18 10:31:58 <mps> huh, who merged it without checking first
2020-08-18 10:32:24 <ncopa> py3-fsspec checksum error is due to this: https://tpaste.us/7K9o
2020-08-18 10:33:01 <mps> I wrote here few days ago that dovecot is not ready for merge
2020-08-18 10:33:28 <ikke> maxice8 did
2020-08-18 10:34:06 <mps> huh, I forgot to add WIP tag, sorry
2020-08-18 10:35:32 <mps> if someone have time and will to fix problem, cmouse (upstream) on #dovecot is resopsive to talk with
2020-08-18 10:36:49 <mps> other option is to disable it (though it is security related) temporary
2020-08-18 10:38:45 <ikke> seems to only fail on 32-bits arches
2020-08-18 10:39:00 <ncopa> looks like the commit that was pushed to 3.12-stable works on git master
2020-08-18 10:39:28 <ncopa> i tried to build it without the time64 patch on 3.12-stable but it didnt seem to make any difference
2020-08-18 10:39:34 <mps> btw, mpv with dbus and musl 1.2.1 is also problematic, same or similar as firefox, vlc
2020-08-18 10:40:19 <ncopa> what ws the fix with firefox vlc?
2020-08-18 10:41:05 <mps> ncopa: ikke: yes, I checked before leaving that with dovecot in edge and 3.12
2020-08-18 10:41:09 <Cogitri> The proposed fix it to build FF w/o dbus
2020-08-18 10:41:24 <Cogitri> But the underlying problem is in dbus and we should fix that instead imho
2020-08-18 10:41:34 <mps> better will be to fix dbus if posible
2020-08-18 10:41:41 <ncopa> +1
2020-08-18 10:41:47 <ncopa> what is the problem with dbus?
2020-08-18 10:41:47 <mps> Cogitri: yes, :)
2020-08-18 10:42:08 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=dbus
2020-08-18 10:43:02 <Cogitri> Not sure, dalias talked about dbus doing something AS unsafe too I think
2020-08-18 10:43:52 <mps> I have to go, only want to add that I don't have time till next week to look on dovecot issues
2020-08-18 10:44:24 <ikke> o/
2020-08-18 10:44:27 <ncopa> would be nice to have an issue with the details so i dont need to re-read weeks of irc logs
2020-08-18 10:44:36 <ncopa> have a nice day mps!
2020-08-18 10:44:51 <mps> thank you all
2020-08-18 10:44:53 <ncopa> mps: dont stress with dovecot. we'll take care of it
2020-08-18 11:09:23 <Cogitri> ncopa: Yes, would be nice if we had an issue for it, but I think only Ariadne and dalias know the details
2020-08-18 11:10:48 <Ariadne> I haven't opened an issue yet, but dbus session bus stalls when kwin-wayland is launched.
2020-08-18 11:17:10 <ncopa> an issue with a simple reproducer would be nice
2020-08-18 11:24:56 <Ariadne> yeah I haven't gotten that far down the rabbit hole yet
2020-08-18 11:32:19 <Ariadne> actually.  I am pretty sure what happens is kwin_wayland spawns a qdbusconnection to connect to the kde config stuff
2020-08-18 11:32:48 <Ariadne> and this stalls out, and then that process eventually times out, and other processes doing similar things also time out
2020-08-18 11:33:04 <Ariadne> and so this results in half the world disconnected from dbus
2020-08-18 11:35:00 <Ariadne> afaik libdbus itself handles the autolaunch feature
2020-08-18 11:35:09 <Ariadne> not dbus-daemon
2020-08-18 11:37:50 <Ariadne> so the use case is likely "do something that invokes an autolaunch"
2020-08-18 11:38:00 <PureTryOut[m]> If anybody wants to keep the builders busy, !11405 is good to merge
2020-08-18 11:53:46 <ncopa> how do i apply this patch https://tpaste.us/1OrV into this MR !11360
2020-08-18 11:55:33 <ncopa> i tried to git push git@gitlab.alpinelinux.org:J0WI/aports master:dovecot-2.3.11 but i get an error
2020-08-18 11:55:50 <ikke> What error?
2020-08-18 11:57:49 <ncopa> that was the clue... it said (fetch first)
2020-08-18 11:58:00 <ncopa> i had to fetch the branch locally first and then i was able to push it
2020-08-18 12:25:07 <ncopa> syncthing does not build with go-11.15
2020-08-18 12:25:15 <ncopa> s/11.15/1.15/
2020-08-18 12:25:15 <alpine-meetbot> ncopa meant to say: syncthing does not build with go-1.15
2020-08-18 13:15:57 <ikke> ncopa: Probably already found this, but for reference: https://github.com/syncthing/syncthing/issues/6889
2020-08-18 13:16:24 <ikke> "You have to pass -tags noquic to avoid building with the quic package that doesn't support go 1.15."
2020-08-18 14:41:45 <maxice8> Can we send HTML to the mailing list?
2020-08-18 14:42:12 <clandmeter> depends on the list
2020-08-18 14:42:19 <clandmeter> i think its not allowed for devel
2020-08-18 14:42:26 <maxice8> Oof
2020-08-18 14:42:32 <ikke> It will be stripped
2020-08-18 14:42:57 <maxice8> Größe oof
2020-08-18 14:43:12 <clandmeter> stipped or just blocked?
2020-08-18 14:43:53 <ikke> It used to be blocked
2020-08-18 14:44:59 <ikke> which made people unhappy
2020-08-18 14:45:07 <ikke> so it was changed to just stripped if it contained html
2020-08-18 14:45:37 <ikke> I think if it's only html, it will still be bounced, but not sure
2020-08-18 14:54:19 <Ganwell> it says the mail was not sent, but it is sent stripped, since you don't get the email you sent from the mailinglist, you tend to believe that and you resend it. If you go to archives you learn that you sent two email.
2020-08-18 16:03:32 <ncopa> thats sort of annoying behavior
2020-08-18 16:14:50 <Ganwell> I don't know if it has been fixed, I never heard back from the admin (26 of Feb). That's how it looks like: https://git.io/JJNOm
2020-08-18 16:29:01 <ikke> Wohooo
2020-08-18 16:29:05 <ikke> armv7 edge is finished!!!!
2020-08-18 16:29:13 <ikke> 17:46:46  algitbot │ edge/testing/armv7: uploaded
2020-08-18 16:29:18 <wsinatra> Yay!!
2020-08-18 16:29:29 <Cogitri> Nice
2020-08-18 16:29:32 <wsinatra> finally time to update my Nokia :D
2020-08-18 16:30:48 <maxice8> Nice
2020-08-18 16:38:47 <ikke> ncopa: do you mind building syncthing without quic support?
2020-08-18 16:59:58 <Ganwell> this code is executed between vfork and exec https://git.io/JJNsL, is that ok?
2020-08-18 17:57:56 <ikke> 19:04:24  algitbot │ edge/testing/x86: uploaded
2020-08-18 17:58:08 <ikke> \o/ \o/ \o/
2020-08-18 18:02:37 <mps> ikke: ncopa: to fix !11360 fix-oauth2-jwt.c.patch from !11404 should be added
2020-08-18 18:03:59 <mps> also, APKBUILD _pkgverminor variable and added/changed where it is used
2020-08-18 18:34:07 <ikke> And the final anouncement
2020-08-18 18:34:11 <ikke> 20:27:08  algitbot │ edge/testing/armhf: uploaded
2020-08-18 18:34:29 <ikke> So all 32-bits arches reached the end of the rebuild
2020-08-18 18:49:22 <Cogitri> Nice :)
2020-08-18 22:20:14 <timlegge> depends for !11519 finally made it to the community repo so its ready to merge
2020-08-18 22:29:45 <timlegge> !11556 is also ready
2020-08-19 03:01:28 <Ariadne> Ganwell: yes, should be fine.
2020-08-19 06:51:40 <ikke> morning
2020-08-19 06:52:01 <Cogitri> Morning
2020-08-19 09:42:26 <ncopa> morning
2020-08-19 09:43:47 <PureTryOut[m]> morning, just about
2020-08-19 09:44:21 <ncopa> Ariadne: i have 2 patches that i think is suitable for upstreaming for libvirt
2020-08-19 09:44:45 <ncopa> https://tpaste.us/pKvx
2020-08-19 09:51:55 <Ariadne> ncopa: looks ok to me
2020-08-19 09:52:19 <Cogitri> ncopa/Ariadne: Do you happen to know the free() semantics of apk_blob_t? Some functions in apk_tools take apk_blob_t as argument by value and then don't free the ptr member of the blob
2020-08-19 09:52:41 <Cogitri> Seems like generally apk_blob_t's ptr is only free'd in a handful of places?
2020-08-19 09:53:07 <Ariadne> yeah the pointer is shared
2020-08-19 09:53:19 <Ariadne> it frees at exit
2020-08-19 09:53:56 <Cogitri> Ah, okay
2020-08-19 09:54:30 <Cogitri> Hm, not that nice for my daemon thingie that uses libapk but I can see why libapk decided to do it that way
2020-08-19 10:06:14 <ncopa> I think it has a design problem. apk was not designed as a lib from the beginning and libapk was added on afterwards. the original intention was that you run each command and then exit the process
2020-08-19 10:06:38 <ncopa> libapk also does not have a stable API/ABI or anything
2020-08-19 10:07:47 <Cogitri> Yup, I currently statically link a certain version
2020-08-19 10:07:58 <ncopa> 👍
2020-08-19 10:08:31 <ncopa> i think the original deal was that any bindings to other languages (like lua) should be maintained in the apk-tools git repository
2020-08-19 10:08:46 <ncopa> that is one of the things i wanted to fix in apk3
2020-08-19 10:10:00 <Cogitri> A higher level API would be great too, but the current API is bearable as well :)
2020-08-19 10:10:23 <Cogitri> I just generated Rust bindings with rust-bindgen and that's serviceable
2020-08-19 10:14:10 <insep_> <ncopa "that is one of the things i want"> is there list of planned features for apk3?
2020-08-19 10:16:08 <ncopa> i guess there exist some list somewhere.... not sure if its public at this point though
2020-08-19 10:16:33 <ikke> fabled sent an e-mail, right?
2020-08-19 10:17:11 <ikke> Oh, it was Ariadne
2020-08-19 10:17:16 <ikke> https://lists.alpinelinux.org/~alpine/apk-tools/%3C43397dfce7287c7ea51d04ba0d47d81c%40dereferenced.org%3E
2020-08-19 10:17:36 <ikke> Hmm, that's more a follow-up
2020-08-19 10:19:06 <ikke> https://lists.alpinelinux.org/~alpine/devel/%3C20191203180717.0016af8a%40vostro%3E#%3C20191203180717.0016af8a@vostro%3E
2020-08-19 10:19:26 <Ariadne> i'll see about assembling a todo list
2020-08-19 10:19:33 <Ariadne> its mostly in fabled's head with me badgering him
2020-08-19 10:19:34 <Ariadne> lol
2020-08-19 10:25:13 <ncopa> sigh, i sent the patches to libvirt list and i found a typo after send. __GLIBC_ instead of __GLIBC__ (which does not make any diff on my machine)
2020-08-19 11:48:59 <maxice8> @PureTryOut I won't be able to answer for the next few days
2020-08-19 11:49:13 <maxice8> If anyone wants to upgrade my stuff feel free
2020-08-19 11:51:12 <PureTryOut[m]> Sure. The last ping I did was just enabling man pages on elogind, not a package upgrade
2020-08-19 11:53:05 <maxice8> Anything, I'm in hospital so I only have phone
2020-08-19 12:26:02 <Ariadne> are you ok ?
2020-08-19 12:39:32 <maxice8> Not really but I don't want to divulge my condition
2020-08-19 12:39:56 <ikke> Wish you well then
2020-08-19 12:44:11 <PureTryOut[m]> Good luck!
2020-08-19 12:46:20 <maxice8> Thanks!
2020-08-19 14:50:03 <clandmeter> maxice8: get well soon!
2020-08-19 15:33:13 <ncopa> maxice8: wow :-( really sorry to hear about that. please please don't stress with the alpine stuff. we we take care of it. take care of yourself!
2020-08-19 18:23:59 <PureTryOut[m]> Why is the aarch64 builder so far behind?
2020-08-19 18:49:43 <ikke> How far?
2020-08-19 18:49:50 <ikke> I wouldn't think it should be that far behind
2020-08-19 18:49:58 <ikke> but syncthing and now minio are holding it back
2020-08-19 19:53:18 <PureTryOut[m]> Well for one a fix I've done to kitinerary a few days ago still hasn't got through to the repos
2020-08-19 19:53:38 <PureTryOut[m]> We've been getting bug reports from pmOS users for a few days and the answer is every time "we already fixed it but the repos are behind" 😛
2020-08-19 19:54:31 <PureTryOut[m]> Actually, that seems to be updated already. Huh, how strange
2020-08-19 19:57:16 <PureTryOut[m]> Oh, seems I forgot to do the same fix to another package 😒 Never mind lol
2020-08-19 21:47:46 <Ariadne> i'm thinking disable syncthing/minio :)
2020-08-20 01:39:17 <maxice8> Surgery successful didn't even need a drainer placed
2020-08-20 02:17:38 <crosbymichael> is anyone using apks for configuration on their own infra?  i as thinking that it could be an pretty simple way to get versions and signing for pushing configs to nodes
2020-08-20 04:43:18 <ikke> maxice8: nice, glad to hear
2020-08-20 04:43:48 <ikke> crosbymichael: In a limited fashion, we do
2020-08-20 05:36:52 <mps> maxice8: nice to hear that it went ok
2020-08-20 10:50:30 <ncopa> maxice8: glad to hear things went well. i have been worried for you
2020-08-20 10:51:40 <ncopa> crosbymichael: i have seen apk been used for push out configs and policies in fairly large setup
2020-08-20 10:52:56 <PureTryOut[m]> maxice8: awesome to hear!
2020-08-20 12:16:29 <crashoverride> The URL for the ntfs-3g package leads to a 404.
2020-08-20 12:16:52 <crashoverride> the correct URL is https://www.tuxera.com/company/open-source/
2020-08-20 12:18:18 <ikke> crashoverride: if you feel comfortable, feel free to make a merge request against aports
2020-08-20 13:28:41 <ikke> apparently it *is* possible to separate debugging symbols from go binaries with objdump
2020-08-20 13:29:42 <Hello71> iirc it was added recently
2020-08-20 13:29:56 <ikke> what was?
2020-08-20 13:31:35 <ikke> I found this mailing list thread: https://www.mail-archive.com/golang-nuts@googlegroups.com/msg38449.html
2020-08-20 13:31:55 <ikke> https://www.mail-archive.com/golang-nuts@googlegroups.com/msg38436.html
2020-08-20 13:36:23 <Hello71> I vaguely recall some go+binutils debug symbols weirdness being resolved recently
2020-08-20 13:36:27 <Hello71> probably wrong though
2020-08-20 17:05:08 <nmeum> mps: FYI https://lists.alpinelinux.org/~alpine/devel/%3C3LLUI2KOULSYM.359WA6HATX45B%408pit.net%3E
2020-08-20 17:05:15 <nmeum> (hope this doesn't turn into a init system bikeshed)
2020-08-20 17:57:19 <Cogitri> nmeum: +1 on that, let's get rid of PID files! :D
2020-08-20 18:01:16 <insep_> "Cogitri" (https://matrix.to/#/@freenode_Cogitri:matrix.org): for security implications?
2020-08-20 18:01:50 <TBB> that'll place an enormous demand on the stability and the security of the supervise daemon
2020-08-20 18:04:18 <Hello71> ... security?
2020-08-20 18:04:48 <Hello71> by that logic start-stop-daemon also has "an enormous demand on stability and security"
2020-08-20 19:27:46 <mps> nmeum: I'm out of 'work' this week
2020-08-20 19:28:48 <ikke> mps: are you enjoying it?
2020-08-20 19:29:00 <mps> but I read mail, and I will write comment next week. short answer: I'm still against
2020-08-20 19:30:16 <mps> ikke: yes, nice place, I don't have to use nonsense of protection, like normal life :)
2020-08-20 19:30:33 <c705> mps: hi. can we bump linux-edge to 5.8.2?
2020-08-20 19:31:12 <mps> even found really nice cellar :)
2020-08-20 19:31:53 <mps> c705: yes, but must be careful about STACK_PROTECTOR
2020-08-20 19:43:18 <ncopa> tmhoang2: i wonder if you could help me get testing/kubernetes built for s390x? https://tpaste.us/wnb9
2020-08-20 19:43:50 <ncopa> i noticed that there are precompiled binaries of kubernetes for s390x so i guess it is possible
2020-08-21 07:14:57 <Ariadne> >>> gcc: Building main/gcc 10.2.0-r0 (using abuild 3.6.0-r1) started Fri, 21 Aug 2020 01:14:44 -0600
2020-08-21 07:14:59 <Ariadne> scary scary
2020-08-21 07:18:50 <Ariadne> going to smoke test gcc, and if all is well, open an MR :)
2020-08-21 07:20:39 <ncopa> awesome
2020-08-21 07:21:56 <Ariadne> i have also converted our gcc patchset to git
2020-08-21 07:27:09 <Ariadne> wow, this honeycomb is fast
2020-08-21 07:27:15 <Ariadne> it already finished building gcc
2020-08-21 07:44:52 <Ariadne> i successfully built gcc-10.2 with gcc-10.2
2020-08-21 07:44:59 <Ariadne> thats a pretty good sanity test i think
2020-08-21 07:45:42 <Cogitri> Yup
2020-08-21 07:51:50 <Ariadne> opening MR, we will want to configure the builders for -fcommon before merging i think
2020-08-21 07:52:40 <Ariadne> or maybe not.  -fcommon fallout does not seem too bad anymore.
2020-08-21 07:59:39 <Ariadne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11638
2020-08-21 08:03:08 <Cogitri> Yup, I think most upstreams got things fixed by now
2020-08-21 08:03:27 <Cogitri> (Or patches are readily available at least)
2020-08-21 08:08:34 <Ariadne> ncopa: what do you think?  do we want to do -fcommon on CFLAGS or just patch broken packages as they appear
2020-08-21 08:08:49 <Ariadne> if we don't see the point in -fcommon on builders, i'll just go ahead and merge it
2020-08-21 08:12:04 <insep_> will there also be gcc8 package like there's gcc4 and gcc6?
2020-08-21 08:12:32 <Ariadne> no
2020-08-21 08:12:57 <Ariadne> gcc6 is for bootstrapping java
2020-08-21 08:13:07 <Ariadne> only reason its a thing
2020-08-21 08:29:20 <Ariadne> Cogitri: i have no objection to pushing it.  if you think -fcommon isn't a concern, i guess, lets just do it
2020-08-21 08:29:55 <ikke> fyi, there was a netsplit, so people might have missed some messages
2020-08-21 08:30:07 <Ariadne> yolooooooo
2020-08-21 08:35:18 <Cogitri> Do we want to do another rebuild of everything or do we wait for 3.13 for potential fallout
2020-08-21 08:35:35 <ikke> Another full rebuild doesn't sound like fun
2020-08-21 08:35:39 <Ariadne> lets wait for 3.13
2020-08-21 08:35:44 <Ariadne> i don't think it is that severe
2020-08-21 08:35:50 <Ariadne> and, worst case we just -fcommon on CFLAGS
2020-08-21 08:45:25 <Cogitri> Okie
2020-08-21 08:45:58 <Ariadne> with the new approach to gcc maintenance (maintaining our patchset in git), we should be able to have gcc 11 in testing on release day
2020-08-21 08:49:45 <ncopa> Ariadne: i thikn we can do the -fcommon as they appear
2020-08-21 08:49:57 <Ariadne> yeah
2020-08-21 08:49:57 <ncopa> also, i think we should build gcc itself with -O2 while at it
2020-08-21 08:50:01 <Ariadne> agree
2020-08-21 08:50:04 <Ariadne> damn
2020-08-21 08:50:10 <Ariadne> i forgot about -O2
2020-08-21 08:50:18 <Ariadne> guess we will be rebuilding gcc 10.2 again :)
2020-08-21 08:50:26 <ncopa> you have a fast machine i heard :)
2020-08-21 08:50:53 <Ariadne> yes, can build gcc in about 15 minutes
2020-08-21 10:23:26 <ncopa> Ariadne: thanks for doing gcc 10. its good we did that early, not too close to the 3.13 release
2020-08-21 10:23:45 <ikke> nod
2020-08-21 11:18:48 <ncopa> Ariadne on my new i9 machine, gcc build time is: real	12m 29.52s
2020-08-21 11:19:02 <Ariadne> yeah
2020-08-21 11:19:05 <Ariadne> about the same here
2020-08-21 11:19:15 <ncopa> and honeycomb is arm based?
2020-08-21 11:19:19 <Ariadne> yeah
2020-08-21 11:19:33 <Ariadne> unfortunately gcc 10 is crashing on mips
2020-08-21 11:20:01 <Ariadne> i feel like mips is just bitrotting since wave technology went bankrupt
2020-08-21 11:20:14 <ncopa> :-(
2020-08-21 11:20:43 <ncopa> 16 cores arm based alsmost keeps up with i9. thats pretty impressive
2020-08-21 11:20:54 <ncopa> i9 10 cores
2020-08-21 11:21:07 <Ariadne> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734
2020-08-21 11:21:12 <ncopa> i also have nvme and lots of ram here
2020-08-21 11:21:20 <Ariadne> yes, same.  64gb and nvme
2020-08-21 11:21:58 <ncopa> i guess intel wins on the gcc build workload due to the configure scripts
2020-08-21 11:22:06 <ncopa> which are not parallelized
2020-08-21 11:22:52 <Ariadne> faster turbo yeah
2020-08-21 11:22:53 <ncopa> so mips gcc fails during build
2020-08-21 11:23:00 <ncopa> not after its built
2020-08-21 11:23:03 <Ariadne> yes, stage 3 build crashes
2020-08-21 11:23:06 <ncopa> ok good
2020-08-21 11:23:18 <Ariadne> it will just sit there failing to build gcc until i hear back
2020-08-21 11:23:21 <Ariadne> no biggie
2020-08-21 11:23:29 <ncopa> it would been bad if it successfully build a broken gcc
2020-08-21 11:23:36 <Ariadne> it will probably get fixed soon, it seems to be just a simple bug in optimizer
2020-08-21 11:23:57 <Ariadne> but gcc internals is a rabbit hole i don't want to jump down right now :)
2020-08-21 11:24:16 <ncopa> understandable :)
2020-08-21 11:33:31 <Ariadne> that method.ii crashes on x86 too
2020-08-21 11:33:35 <Ariadne> soooo
2020-08-21 11:35:23 <Ariadne> huh
2020-08-21 11:35:27 <Ariadne> i wonder if this has to do with PCH
2020-08-21 11:38:24 <Ariadne> i was able to successfully compile that method.ii by hand and slip it into the gcc build directory
2020-08-21 11:38:34 <Ariadne> i htink this may be a PCH bug.
2020-08-21 11:38:44 <Ariadne> precompiled headers are the invention of satan
2020-08-21 11:39:34 <Ariadne> and the stage3 compiler compiles fine o_O
2020-08-21 11:39:40 <Ariadne> yeah this is smelling of PCH
2020-08-21 11:49:53 <Ariadne> and the compiler i built successfully built itself over again
2020-08-21 11:50:03 <Ariadne> whatever
2020-08-21 11:50:10 <Ariadne> i don't like heisenbugs
2020-08-21 11:54:26 <Ariadne> i'm now manually compiling main/gcc with the main/gcc i just built to make sure everything is kosher
2020-08-21 12:13:04 <Ariadne> ok
2020-08-21 12:13:06 <Ariadne> well
2020-08-21 12:13:07 <Ariadne> that built
2020-08-21 12:13:08 <Ariadne> soooooo
2020-08-21 12:13:20 <Ariadne> or at least, it has gotten past the part where it was crashing
2020-08-21 12:13:24 <Ariadne> sooooooo :)
2020-08-21 12:28:30 <indy> hi all, i was able to convince abuild to download 'source' with url from site, which is secured by httpauth using ~/.curlrc and ~/.netrc, but problem is that apk can't download from "httpauth-ed" site
2020-08-21 12:33:51 <indy> response is "ERROR: https://userid:password@some.url/artifactory/test: No such file or directory"
2020-08-21 12:37:56 <indy> https://www.shellhacks.com/jfrog-artifactory-download-artifact-using-curl/
2020-08-21 12:40:26 <indy> i can't use userid:password as password contains "@" sign and escaping does not work
2020-08-21 12:42:40 <indy> i was able to download from jfrog using unmodified openwrt's opkg, which uses busybox's wget applet and it is using .netrc
2020-08-21 12:46:28 <Ariadne> yes, apk-tools does not presently support http auth, sorry.
2020-08-21 13:30:32 <tmhoang2> ncopa: I'm looking in k8s, thanks
2020-08-21 13:37:45 <Ariadne> ah yes, the kubler-ross model
2020-08-21 13:48:39 <tmhoang> anyone running multipath disk on Alpine ? I have not seen any multipath code in mkinitfs, guessing it does not wokr
2020-08-21 13:50:29 <tmhoang> given that there is multipath apk package, I guess it works for somebody running a multipath data disk, but not a root disk (requiring mkinitfs )
2020-08-21 13:57:38 <Ariadne> when i was using multipath, it was data only
2020-08-21 13:59:03 <ikke> We have I think one host that uses a multi-path disk, but that's not the boot disk
2020-08-21 14:07:08 <Ariadne> Hello71: anyway, gcc is -O2 now
2020-08-21 14:07:16 <Hello71> alright
2020-08-21 14:07:19 <Ariadne> mips gcc is still fucked, but hacked for now
2020-08-21 14:07:33 <Ariadne> when gcc devs fix it for real, i'll uhh, figure out how to fix what i did then
2020-08-21 14:08:03 <Hello71> i thought you turned off pch
2020-08-21 14:08:30 <Ariadne> yes, but that requires manual intervention every time
2020-08-21 14:09:23 <Hello71> oh, the gentoo gcc USE=pch is misleading
2020-08-21 14:09:32 <Ariadne> so what i wound up doing instead was
2020-08-21 14:09:51 <Hello71> it does --disable-libstdcxx-pch
2020-08-21 14:09:57 <Ariadne> cross-compiling gcc
2020-08-21 14:10:06 <Ariadne> from mips64 to mips64
2020-08-21 14:10:18 <Ariadne> using a hacked APKBUILD
2020-08-21 14:10:30 <Ariadne> but it still has the bug
2020-08-21 15:34:50 <tmhoang> anyone actually use gcompat apk package ?
2020-08-21 15:47:19 <Ariadne> yes
2020-08-21 15:47:30 <Ariadne> i use it for zoom and other crap like that
2020-08-21 15:55:44 <insep_> on what arch are you using it? some people tried using it on aarch64 and it didn't really work
2020-08-21 15:56:15 <Ariadne> x86_64
2020-08-21 15:56:23 <Ariadne> why would i want to run binary blobs on arm
2020-08-21 15:56:46 <Ariadne> like, what binary blobs *are* there to run on arm
2020-08-21 15:58:18 <Ariadne> petrie:~$ /lib/libgcompat.so.0
2020-08-21 15:58:19 <Ariadne> Segmentation fault
2020-08-21 15:58:21 <Ariadne> interesting
2020-08-21 15:58:34 <Ariadne> so, the loader is broken on aarch64
2020-08-21 16:00:13 <Ariadne> o
2020-08-21 16:00:40 <Ariadne> insep_: how are you using gcompat, exactly.
2020-08-21 16:05:40 <Ariadne> Program received signal SIGBUS, Bus error.
2020-08-21 16:05:40 <Ariadne> 0x0000fffff7f3d57c in ?? ()
2020-08-21 16:05:45 <Ariadne> hmm, seems to SIGBUS inside the loader.
2020-08-21 16:05:52 <Ariadne> i wrote the loader, so i'll debug it
2020-08-21 16:13:15 <Ariadne> hmm, loader itself is fine
2020-08-21 16:13:20 <Ariadne> it crashes after the execve
2020-08-21 16:17:00 <Ariadne> insep_: seems to be a musl 1.2.1 regression
2020-08-21 16:23:22 <Cogitri> Ariadne: Are Go things OK on mips? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11611/diffs#6c161146004a8a49f0ba842a8a7bbcc1dfc01521_12_12
2020-08-21 16:23:42 <Ariadne> no
2020-08-21 16:24:43 <Cogitri> Hm, ok. Mind commenting on the MR then? I don't know the specifics of go x mips
2020-08-21 16:35:02 <tmhoang> ncopa: would you mind sheding some light on this ? https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in#n339
2020-08-21 16:35:15 <tmhoang> Ariadne: Thanks.
2020-08-21 16:35:47 <ikke> tmhoang: what part is inclear?
2020-08-21 16:35:55 <tmhoang> opt variable
2020-08-21 16:36:29 <ikke> In shell, for <var>; do means iterate over each argument supplied to the script
2020-08-21 16:36:30 <tmhoang> Ariadne: I'd really appreciate you have done the s390x asm for libucontext.
2020-08-21 16:36:44 <ncopa> its equivalent to: for opt in "$@"; do ...
2020-08-21 16:36:58 <Ariadne> tmhoang: hmm?
2020-08-21 16:37:13 <Ariadne> tmhoang: oh, yes, libucontext already supports s390x
2020-08-21 16:37:59 <insep_> <Ariadne "like, what binary blobs *are* th"> none, but npm and others compile against glibc
2020-08-21 16:38:00 <insep_> <Ariadne "insep: how are you using gcompat"> i dunno how they were using it, but i guess apk add gcompat and trying to launch stuff ¯\_(ツ)_/¯
2020-08-21 16:38:01 <insep_> sadly that person isn't there :(
2020-08-21 16:38:05 <tmhoang> ikke, ncopa: right, it's $@ . Thanks !
2020-08-21 16:39:50 <tmhoang> iiuc, our initramfs does not support multiple instance of a karg, like : alpine_repo=111 alpine_repo=222
2020-08-21 16:39:59 <tmhoang> specifically that for block
2020-08-21 16:40:19 <ncopa> yes, i think thats correct
2020-08-21 16:40:27 <ncopa> which is a bit stupid
2020-08-21 16:41:04 <tmhoang> maybe just simply appending KOPT_${i} to itself is enough
2020-08-21 16:41:25 <Ariadne> insep_: yes.  was able to reproduce.  seems to be a musl issue on aarch64.  we will dig into it more
2020-08-21 16:41:26 <ikke> Yeah, was thinking the same
2020-08-21 16:42:19 <tmhoang> not all KOPT_${i} in later code understand multiple instance of ${i} in kargs, but whichever ${i} wanted to do multiple instances should be fixed for each case
2020-08-21 16:42:59 <tmhoang> dracut people also solved this for each case too
2020-08-21 16:47:48 <Ariadne> insep_: also gcompat has some limitations.  it can launch programs but it has to be patched into shared libs that don't have programs
2020-08-21 16:48:24 <ncopa> tmhoang: i kinda think that if there is a known number multiple args, maybe better to scan the cmdline again
2020-08-21 16:48:49 <ncopa> otherwise there are options like: alpine_repo=repo1,repo2,repo3
2020-08-21 16:49:15 <tmhoang> yep, I made dasd=opt1,opt2,opt3 atm, for example
2020-08-21 16:49:28 <tmhoang> that's also a good way out, without changing more code
2020-08-21 17:07:06 <ncopa> have a nice weekend everyone!
2020-08-21 17:08:37 <Cogitri> You too :) 👋
2020-08-21 17:41:26 <tmhoang> o/
2020-08-21 17:46:00 <cfengineuser> hey guys
2020-08-21 17:46:09 <cfengineuser> i am having a problem with musl i think its a bug
2020-08-21 17:46:20 <cfengineuser> anyone around?
2020-08-21 17:47:25 <Cogitri> Just state your problem, then someone can answer to the actual problem you have
2020-08-21 17:47:47 <Cogitri> Probably best to make a gitlab issue at https://gitlab.alpinelinux.org/alpine/aports/issues/new though
2020-08-21 17:48:03 <cfengineuser> ok i think the newet version of musl is rejecting non-authoritative dns
2020-08-21 17:48:10 <cfengineuser> not sure if that is desired
2020-08-21 17:49:34 <cfengineuser> I have 3 systems, one is a server running alpine the other two are postmarketOS
2020-08-21 17:50:01 <cfengineuser> the server and one of the pmOS devices is running musl 1.1.24-r9
2020-08-21 17:50:18 <cfengineuser> the other pm OS device is running newest musl
2020-08-21 17:50:28 <cfengineuser> the latter is rejecting non-authoritative dns
2020-08-21 17:50:37 <cfengineuser> i looked at the code and i see changes were made
2020-08-21 17:51:05 <cfengineuser> in name_from_dns
2020-08-21 17:52:17 <cfengineuser> i wil have to spend some more time to figure out exactly what is happening but I am fairly convinced
2020-08-21 17:53:04 <cfengineuser> musl-1.2.1-r0 seems to have an issue
2020-08-21 17:53:44 <wsinatra> cfengineuser: out of curiosity, how're you checking?
2020-08-21 17:53:50 <cfengineuser> checking what
2020-08-21 17:54:06 <cfengineuser> ??
2020-08-21 17:54:19 <wsinatra> how are you testing the rejection? What are the steps to reproduce your issue?
2020-08-21 17:54:48 <cfengineuser> well the problem first arose after i flashed a pmOS device with stable channel and then one with edge
2020-08-21 17:55:04 <cfengineuser> the edge version gave dns errors and stable did not
2020-08-21 17:55:09 <cfengineuser> so i straced
2020-08-21 17:55:32 <cfengineuser> i found that although the dns server respnded the same to eah device they behaved differently
2020-08-21 17:55:46 <cfengineuser> so i grepped and grepped
2020-08-21 17:55:53 <cfengineuser> and i came to that function
2020-08-21 17:56:05 <cfengineuser> i see tha changes that were made and i think they introduced a bug
2020-08-21 17:56:27 <cfengineuser> all non-authoritative dns fails on 1.2.1-r0 for me
2020-08-21 17:56:34 <cfengineuser> while it works on 1.1.24-r9
2020-08-21 17:56:38 <ikke> cfengineuser: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11879 ?
2020-08-21 17:56:46 <cfengineuser> lemm see
2020-08-21 17:57:02 <ikke> That one is when using docker on mac
2020-08-21 17:57:57 <cfengineuser> similar
2020-08-21 17:58:01 <cfengineuser> same response
2020-08-21 17:58:08 <cfengineuser> i think its related
2020-08-21 17:58:10 <cfengineuser> sam bug
2020-08-21 17:58:28 <cfengineuser> it only works if your dns is authoritative
2020-08-21 17:58:46 <cfengineuser> i send mine through cache and so i got dinged
2020-08-21 17:59:25 <cfengineuser> name_from_dns borked it somehow
2020-08-21 18:00:36 <cfengineuser> so to recap 1.1.24-r9 works for me for non-authoritative dns response but 1.2.1-r0 does not
2020-08-21 18:00:51 <cfengineuser> pretty please help me fix it
2020-08-21 18:01:25 <cfengineuser> thanks for listening
2020-08-21 18:01:28 <cfengineuser> bbiab
2020-08-21 18:05:28 <ikke> cfengineuser: Well, it needs to be fixed upstream (or patched by us in the mean-time)
2020-08-21 18:05:50 <cfengineuser> i have not actually found the bug yet
2020-08-21 18:05:57 <cfengineuser> i do program in C
2020-08-21 18:06:24 <cfengineuser> who does musl
2020-08-21 18:06:25 <cfengineuser> ?
2020-08-21 18:06:46 <cfengineuser> i just suspect this name_from_dns change
2020-08-21 18:06:58 <cfengineuser> i would have to go through with a fine toothed comb
2020-08-21 18:07:00 <ikke> there is a #musl irc channel
2020-08-21 18:07:06 <cfengineuser> oooh
2020-08-21 18:07:10 <cfengineuser> they might be interested
2020-08-21 18:07:19 <ikke> I just asked about it there
2020-08-21 18:07:22 <cfengineuser> k
2020-08-21 18:07:27 <cfengineuser> ill leave it in your capable hands
2020-08-21 18:08:02 <cfengineuser> if edg becomes stable i think some people ill complain
2020-08-21 18:08:24 <ikke> That's not until november / december
2020-08-21 18:08:46 <ikke> And that's why we have edge, to find and fix these kinds of issues before we release it
2020-08-21 18:08:52 <cfengineuser> yep
2020-08-21 18:08:53 <ikke> So thank you for reporting :)
2020-08-21 18:09:05 <cfengineuser> trying to do my part, i get so much out of linux
2020-08-21 18:09:34 <cfengineuser> cheers
2020-08-21 18:25:00 <tmhoang> ncopa: https://tpaste.us/wnb9 : this seems to be fixed in latest 1.18.8-r1
2020-08-21 18:38:10 <ikke> cfengineuser: Do you have a test-case or a way to reproduce what you are seeing? (ie, what is the actual issue you are facing)
2020-08-22 05:06:49 <Ariadne> insep_: well, it is fixed now :P
2020-08-22 05:30:06 <insep_> cool, now this person should have one less reason to switch to debian :D
2020-08-22 05:30:25 <insep_> is it pushed to alpine repos?
2020-08-22 05:33:11 <insep_> seems like pushed to repos
2020-08-22 08:54:21 <wener[m]> andypost:  hi, there is more problem about the k3s build, crictl not help. but if this is not merged https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11646, how can I add more fixes ?
2020-08-22 09:26:45 <fcolista> what woudl be the best way to add an openrc-supervised init as subpackage? Consider that they might live togheter, that conf.d (might/should?) be shared?
2020-08-22 09:27:32 <fcolista> perhaps a symlink from the /etc/init.d/daemon to the supervised one
2020-08-22 09:28:06 <fcolista> but this means that we need triggers that when we add/remove openrc-supervised or openrc package, the symlink needs to be adjusted
2020-08-22 09:28:53 <fcolista> or we can avoid that they live together, so in the subpackage jsut put depends="!$package-openrc"
2020-08-22 09:29:54 <fcolista> but this means that the conf.d should be shipped along with the subpackage supervised openrc
2020-08-22 09:34:56 <ikke> fcolista: maybe have 2 services with different names?
2020-08-22 09:35:05 <ikke> foo, foo-supervised?
2020-08-22 09:36:53 <fcolista> and have different conf.d
2020-08-22 09:37:19 <fcolista> conf.d/foo and conf.d/foo-supservised
2020-08-22 09:37:40 <fcolista> even if the two files are equals
2020-08-22 09:45:14 <fcolista> ikke, so you mean something like this: http://dpaste.com/7XFT42896.txt
2020-08-22 13:16:21 <PureTryOut[m]> Hmmpf, I pushed updates to a branch but the MR related to it doesn't seem to notice the update. No new pipeline is being ran, and the commit doesn't represent the actual one
2020-08-22 13:39:36 <ikke> link?
2020-08-22 13:41:29 <PureTryOut[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11405
2020-08-22 13:41:49 <PureTryOut[m]> If I push locally it says the remote branch is already up-to-date, but either it is not or it is and Gitlab doesn't realize
2020-08-22 14:18:30 <Hello71> are you pushing to the wrong branch
2020-08-22 14:33:19 <PureTryOut[m]> No
2020-08-22 15:17:24 <PureTryOut[m]> Oh it seems half an hour ago it finally realized something had changed
2020-08-22 15:51:15 <nmeum> fcolista: there is no need for two services
2020-08-22 15:51:43 <nmeum> if supervise-deamon usage should be configurable that could just be done using /etc/conf.d or maybe through a global setting in /etc/rc.confs
2020-08-22 15:51:43 <nmeum> *?
2020-08-22 15:53:01 <ikke> But isn't the issue that with supervisor-daemon it needs to run in the foreground, and without, it needs to run in the background, requiring different openrc options?
2020-08-22 15:55:40 <nmeum> yes, there is $command_args_foreground specfically for this purpose. I would assume that it is being ignored unless $supervisor is set too
2020-08-22 16:04:02 <ikke> hmm, true
2020-08-22 16:32:13 <minimal> Ariadne: just noticed that ifupdown-ng added a install_if="alpine-base" a couple of days ago, so making it default. My cloud-init package currently depends on ifupdown (as Busybox's ifupdown caused issues). Luckily it appears cloud-init is the only package with a dep on ifupdown.
2020-08-22 16:33:32 <minimal> I was planning to test cloud-init with ifupdown-ng in the future (been busy the past couple of weeks getting Alpine stuff upstreamed into cloud-init). Guess I'll have to test it out now due to this change.
2020-08-22 16:34:40 <ikke> Alpine 3.13 is due to november/december, so it's better to have it in edge sooner rather than later to get enough feedback in time before the release
2020-08-22 16:36:10 <minimal> yeah, it just that it caught me by surprise today when a VM build failed due to the ifupdown / ifupdown-ng conflict
2020-08-22 16:37:14 <minimal> didn't realise 3.13 timescale had slipped that far out...
2020-08-22 16:38:08 <ikke> hmm?
2020-08-22 16:38:39 <ikke> it's always may/june and november/december
2020-08-22 16:39:38 <minimal> oh? for some reason I thought it was Sept
2020-08-22 16:39:48 <ikke> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-08-22 16:40:33 <minimal> hopefully cloud-init will work with ifupdown-ng with no changes as the change window has closed for the new cloud-init release
2020-08-22 17:06:34 <nmeum> minimal: we can always backport stuff
2020-08-22 17:40:45 <nmeum> Ariadne: do we want to remove main/ifupdown in favor of ifupdown-ng or is there any way to prevent a conflict between the two? I wouldn't mind simply removing main/ifupdown
2020-08-22 17:43:36 <minimal> nmeum: I guess its a question of whether ifupdown-ng is a drop-in replacement for ifupdown or whether there's any missing functionality
2020-08-22 17:44:57 <nmeum> it's supposed to be a drop-in replacement (at least that's my current understanding)
2020-08-22 18:01:42 <minimal> nmeum: yeah I realise it, my question was whether its a 100% drop-in replacement
2020-08-22 18:02:28 <minimal> I'm testing some various cloud-init network configs currently, so far no sign of any problems
2020-08-22 18:03:47 <nmeum> see https://lists.alpinelinux.org/~alpine/devel/%3C12372156.q0HFhEdf7Z%40localhost%3E
2020-08-22 18:03:48 <nmeum> > ifupdown-ng is 100% backwards compatible with ifupdown
2020-08-22 18:04:02 <nmeum> though not sure if that statement only refers to busybox ifupdown
2020-08-22 18:07:02 <minimal> minimal: don't get me wrong, I'm not against the addition of ifupdown-ng, I'm just trying to determine if there's subtle changes in behaviour
2020-08-22 18:07:40 <nmeum> sure, it's good that you test it with cloud-init! :)
2020-08-22 18:08:43 <nmeum> testing is very much appreciated
2020-08-22 18:13:56 <minimal> nmeum: just hit a compatibity problem with vlans, will need to dig further to see what's going on. That /etc/networking/interfaces config worked fine with ifupdown
2020-08-22 18:23:14 <minimal> Ariadne: had a look at the ifupdown-ng source code regardig vlans, it doesn't handle "vlan-raw-device" or "vlan_id" keywords in /etc/network/interfaces which I've been using up to now with ifupdown2
2020-08-22 18:47:44 <minimal> Raised an Issue for the vlan problem: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11885
2020-08-22 18:49:32 <couchkitten[m]> it was suggested to me to point out here that squeekboard and the gcompat fix might be useful for backporting to stable
2020-08-22 18:50:39 <couchkitten[m]> squeekboard because the stable variant's terminal layout is quite a potential usability and accessibility problem while upstream/edge has this fixed, and gcompat because the stable variant seems from my own tests  to just crash with SIGBUS which kind of renders it useless
2020-08-22 18:50:53 <insep_> Ariadne: ^ this is a person who was using gcompat on arm
2020-08-22 18:51:10 <insep_> on aarch64, to be eхact
2020-08-22 18:51:28 <couchkitten[m]> I'm a developer and I use a pinephone, so I use things like npm and pip. both of these pull in prebuilt binaries which are always built with shared glibc
2020-08-22 18:51:40 <couchkitten[m]> so something like gcompat is essential for developers using these tools IMHO
2020-08-22 19:08:59 <couchkitten[m]> for what it's worth there was at least one other person in the postmarketOS channel arguing the perceived lack of glibc compatibility (which would be addressed by gcompat working, assuming it actually allows most complex glibc programs to run correctly) was a dealbreaker for them. so while I didn't do a survey I don't seem to be the only one
2020-08-22 19:09:15 <couchkitten[m]> (and postmarketOS is largely used on aarch64)
2020-08-22 19:14:32 <insep_> they, i just asked if it works on anything other than amd64 and aarch64 >:(
2020-08-22 19:14:43 <insep_> no point in shipping something broken
2020-08-22 19:17:34 <insep_> s/they/hey/g
2020-08-22 19:17:34 <alpine-meetbot> insep_ meant to say: hey, i just asked if it works on anything other than amd64 and aarch64 >:(
2020-08-22 19:18:26 <insep_> this bot is awesome
2020-08-22 19:33:33 <couchkitten[m]> are devices other than amd64 AND aarch64 common?
2020-08-22 19:34:05 <couchkitten[m]> or maybe I misunderstood your remark
2020-08-22 19:34:41 <couchkitten[m]> I just attempted to explain why it'd be useful to me and 1+ other people on aarch64, I have no knowledge of where gcompat works right now or doesn't
2020-08-22 19:36:00 <insep_> adding it to postmarketos-base means installing it for everyone, including people with armv7/armhf
2020-08-22 19:36:49 <couchkitten[m]> insep ah, maybe let's discuss that in postmarketOS-devel?
2020-08-22 19:36:51 <insep_> regarding question about arches, i'm pretty sure that most of our devices are either armv7 or armhf
2020-08-22 19:38:36 <Cogitri> I think armv7 is also somewhat common still
2020-08-22 19:39:06 <Cogitri> Ah, riot didn't load the last 5 messages :)
2020-08-22 19:39:10 <couchkitten[m]> it is but it may no longer be in 5ish years. so I personally would be very happy if gcompat just worked right on aarch64
2020-08-22 19:39:19 <insep_> most of my devices are armv7 :D
2020-08-22 19:39:46 <couchkitten[m]> which right now it doesn't seem to in alpine stable @ aarch64, hence me asking for the backport of the fix
2020-08-22 19:40:01 <insep_> there are also kaios devices, which are armv7 too
2020-08-22 19:42:38 <couchkitten[m]> I think I just confused insep  and then myself by asking two different things about gcompat in two places and some of that spilling over to here 😂 I apologize
2020-08-22 19:42:57 <couchkitten[m]> the only thing I intended to bring up here is that it'd be great to backport gcompat aarch64 fixes from edge to stable if there are any
2020-08-22 19:53:10 <ikke> cfengineuser: What is your non-authorative nameserver? The musl maintainer says it returns an invalid response (NXDOMAIN when only AAAA is missing)
2020-08-22 19:55:12 <dalias> "non-authoritative nameserver" is a confusing way to ask it
2020-08-22 19:55:18 <dalias> just what's in your resolv.conf?
2020-08-22 19:56:06 <ikke> I was just refering to what cfengineuser mentioned
2020-08-22 19:56:17 <dalias> ok
2020-08-22 19:56:18 <ikke> "so to recap 1.1.24-r9 works for me for non-authoritative dns response but 1.2.1-r0 does not
2020-08-22 19:57:34 <dalias> right. i just mean "authoritative vs non-authoritative" isn't a thing here. all queries/answers in this context are non-authoritative
2020-08-22 20:00:56 <minimal> wasn't there something related to this mentioned in a php7 issue? Let me check.....
2020-08-22 20:01:32 <minimal> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11879
2020-08-22 20:04:00 <minimal> ikke: not php but seems to be the issue you mentioned
2020-08-22 20:04:36 <dalias> yes, we just need to figure out what this broken nameserver that's forging nxdomain is
2020-08-22 20:04:56 <dalias> and then alpine needs to make a decision on carrying a workaround for a while or telling ppl to fix their broken shit
2020-08-22 20:06:06 <insep_> iirc he can't switch nameservers, probably isp forces it but don't quote me on that
2020-08-22 20:06:54 <ikke> minimal: yes, I'm aware of that issue (I replied to it)
2020-08-22 20:08:59 <dalias> you can always switch nameservers
2020-08-22 20:09:22 <Ariadne> minimal: will release a fix for it on Monday.  thanks for testing.
2020-08-22 20:10:09 <minimal> DNS is always a messy area - layers upon layers of implemention assumptions and misconfigurations
2020-08-22 20:11:40 <minimal> Ariadne: thanks. I guess having named vlan interfaces (rather than i.e. eth0.5) might be considered 'weird' by some people ;-)
2020-08-22 20:12:11 <Ariadne> minimal: in this case it's because ifupdown-ng sees it as a physical link instead of a vlan yes.
2020-08-22 20:12:40 <Ariadne> we will rework it so that if the vlan executor is referenced it will drop the link executor :)
2020-08-22 20:13:15 <Ariadne> the ifupdown-ng core doesn't actually configure anything, it just figures out what programs to run :)
2020-08-22 20:14:37 <minimal> haven't looked through the ifupdown-ng code in much detail. Good thing cloud-init is the only package to have a dependancy on ifupdown. It may have been vlan handling (don't remember) that let me to use it originally rather than Busybox's ifupdown
2020-08-22 20:18:26 <Ariadne> well this is why I gated it the way I did.
2020-08-22 20:21:54 <PureTryOut[m]> !11405 is ready for merging. 2 arches are re-doing CI because they had some packages failing to install due to BAD signature which caused 1 package for both of them to fail to build, but otherwise everything succeeded
2020-08-22 20:22:00 <PureTryOut[m]> If somebody wants to keep the builders busy 😜
2020-08-22 20:29:20 <minimal> dalias: "telling ppl to fix their broken shit" - used to work in an ISP, its crazy the amount of fundamentally-broken DNS-related stuff that's out there - like having to explain to the hosting company that their firewall was blocking Internet access to their authoritative nameservers so none of their customer domains could be looked up.
2020-08-22 20:30:50 <dalias> :-p
2020-08-22 22:19:43 <couchkitten[m]> hmmmm is it only me always wondering why there is no .apk download button on pages like this one? https://pkgs.alpinelinux.org/package/edge/community/aarch64/gcompat
2020-08-22 22:20:08 <couchkitten[m]> like sure it is helpful to also browse the contents online, but sometimes I am just looking for the .apk
2020-08-22 22:20:20 <couchkitten[m]> I usually end up browsing the mirror directly but it's a bit cumbersome
2020-08-22 22:26:16 <TBB> probably because a single button download won't bring you the dependencies with it
2020-08-22 22:27:06 <Hello71> but debian has it, and so does arch
2020-08-22 22:27:27 <Hello71> my guess is that nobody wanted to set a "default mirror"
2020-08-22 22:35:23 <couchkitten[m]> TBB yeah but it's still useful
2020-08-22 22:35:35 <couchkitten[m]> sometimes I just don't need any deps or I don't care to download them manually
2020-08-22 22:35:56 <couchkitten[m]> e.g. right now I just wanted to test gcompat from edge on non-edge to see if it fixes things on aarch64 (it does)
2020-08-23 00:05:50 <couchkitten[m]> is there a cross-compiler to glibc aarch64 in the alpine repos?
2020-08-23 00:06:23 <couchkitten[m]> (for use on aarch64, but for spitting out the more common glibc-via-dynamic-link binaries)
2020-08-23 00:06:34 <couchkitten[m]>  * (for use on alpine aarch64, but for spitting out the more common glibc-via-dynamic-link binaries)
2020-08-23 02:02:53 <Ariadne> no
2020-08-23 02:10:59 <couchkitten[m]> dunno if I'm the only person but I would consider that quite useful
2020-08-23 02:11:14 <couchkitten[m]> like especially now that gcompat seems to work to also run the stuff
2020-08-23 09:25:45 <nmeum> does anybody mind if I merge !11654 today? actually a very straight forward change and gcc does the same so I don't really see potential problems
2020-08-23 09:26:55 <Cogitri> Do you also happen to know if there are other flags we pass by default with gcc but not with CLang?
2020-08-23 09:27:54 <Cogitri> I mean that certainly doesn't have to be included in that MR, but would be good to add those too
2020-08-23 09:28:07 <nmeum> yes, pie for instance :)
2020-08-23 09:28:11 <nmeum> yep, working on that
2020-08-23 09:34:28 <Cogitri> Nice 👍️
2020-08-23 09:36:03 <nmeum> ah, actually PIE is enabled by default for musl an clang
2020-08-23 09:36:45 <nmeum> > bool Linux::isPIEDefault() const { return (… || getTriple().isMusl() || …); }
2020-08-23 09:38:08 <ikke> That MR is failing in x86_64 and ppc64le?
2020-08-23 09:38:20 <nmeum> timeouts
2020-08-23 09:39:04 <nmeum> at least that was my assumption
2020-08-23 09:39:12 <ikke> g++: fatal error: Killed signal terminated program cc1plus
2020-08-23 09:40:06 <ikke> ppc64le is a timeout indeed, due to sometimes slow upload of artifacts
2020-08-23 09:40:14 <ikke> x86_64 looks like OOM perhaps
2020-08-23 09:40:18 <nmeum> or that
2020-08-23 09:40:21 <nmeum> it passed locally on x86_64
2020-08-23 09:41:19 <ikke> ok
2020-08-23 09:44:52 <nmeum> hm, I might still need to add /usr/include/fortify to the default include path though
2020-08-23 09:47:03 <Cogitri> `ERROR: libndp-1.7-r0: BAD signature` on armv7 CI, forgot what the command to purge it from the CDN was
2020-08-23 09:47:43 <ikke> curl -XPURGE <url>
2020-08-23 09:49:58 <Cogitri> Thanks
2020-08-23 10:08:22 <Cogitri> Hm, I ran that but seems like the signature still fails the check
2020-08-23 10:08:23 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/191325
2020-08-23 10:18:37 <ikke> Purged those packages and they are accepted..
2020-08-23 10:18:49 <ikke> curl -XPURGE https://dl-cdn.alpinelinux.org/alpine/edge/community/armv7/clutter-gtk-1.8.4-r1.apk
2020-08-23 10:21:31 <Cogitri> Huh, I did `curl -XPURGE https://alpine.global.ssl.fastly.net/alpine/edge/community/armv7/clutter-gtk-1.8.4-r1.apk` and that didn't change anything
2020-08-23 10:23:40 <ikke> I guess you need to use the exact url that is cached
2020-08-23 10:24:10 <ikke> note that it's no longer necessary to use alpine.global.ss.fastly.net
2020-08-23 10:25:42 <Cogitri> Maybe mirrors.a.o can be updated then? I took the URL from there
2020-08-23 15:20:50 <PureTryOut[m]> Anyone willing to merge !11405? Passes CI on all arches except for a few BAD signatures while installing deps on 2 arches
2020-08-23 16:08:07 <Cogitri> PureTryOut[m]: Merged
2020-08-23 16:08:46 <PureTryOut[m]> Awesome, thanks! Good luck to the builders lol
2020-08-23 17:03:29 <andypost[m]> Is there a way to minimize a size of .debug files? https://pkgs.alpinelinux.org/package/edge/community/x86_64/php7-dbg
2020-08-23 17:05:56 <Hello71> https://lists.alpinelinux.org/~alpine/devel/%3C1593702164.2nw55qdomr.none%40localhost%3E
2020-08-23 19:27:48 <mps> linux-edge 5.8.3 failed on armv7 builder but worked fine on my lxc armv7 container
2020-08-23 19:36:43 <mps> hmm, I see that I didn't upgraded gcc on 'my' lxc
2020-08-23 20:10:13 <mps> yes, linux-edge build failed with gcc-10.2.0
2020-08-24 08:44:02 <gjabell> Cogitri: can you or someone else take another look at !11388? I think it should be ready for merge
2020-08-24 08:46:11 <gjabell> that was fast, thanks :)
2020-08-24 08:46:43 <Cogitri> 👍
2020-08-24 10:14:03 <oliv3r[m]> Hi, If I want to have 2 binaries to a package (due to compile flags); how is that usually done? Do we have any examples?
2020-08-24 10:14:10 <oliv3r[m]> My use case, is I want to package libwebsockets but with glib support, so we end up with libwebsockets and libwebsockets-glib, having 2 APKBUILDs is a bit nasty :) and having libwebsockets and libwebsockets-glib sounds a bit weird (as libwebsockets would be depending on the glib variant?)
2020-08-24 10:16:16 <Cogitri> We usually just opt for one of the two variants, I think in this case it's fine to depend on glib since you probably won't get around pulling that in somehow anyway
2020-08-24 10:16:33 <Ariadne> it is possible to avoid glib on server :)
2020-08-24 10:16:52 <Ariadne> if possible, you can use multiple build directories and individual make installs for each subpkg
2020-08-24 10:20:15 <ikke> zabbix builds 3 variants in the same package
2020-08-24 11:32:19 <tmhoang> anyone tried jit with ocaml on x86_64 ?
2020-08-24 11:32:26 <tmhoang> *ocaml with jit
2020-08-24 11:33:04 <tmhoang> couldn't find much information on the net
2020-08-24 11:39:01 <oliv3r[m]> zabbix, nice, i'll look into that for some examples :)
2020-08-24 15:03:24 <Ariadne> minimal: hi.  ifupdown-ng 0.8.1-r1 should solve your vlan issue.
2020-08-24 15:19:34 <minimal> Ariadne: r1? When's that out? pkg.alpinelinux.org only shows r0
2020-08-24 15:19:40 <Ariadne> erf
2020-08-24 15:19:42 <Ariadne> 0.8.1-r0
2020-08-24 15:19:43 <Ariadne> sorry :)
2020-08-24 15:19:48 <minimal> yes that's what I'm using
2020-08-24 15:20:02 <minimal> I reopened the Issue a few minutes ago and its not working
2020-08-24 15:20:26 <Ariadne> yeah, already replied.  going to set up a VM and investigate.
2020-08-24 15:21:08 <minimal> strange that manually running "ifup -a" sets thing up right. Some sort of race condition during boot?
2020-08-24 15:21:52 <Ariadne> yes.  that is what i think.
2020-08-24 15:21:53 <Ariadne> qemu-system-aarch64: KVM is not supported for this guest CPU type
2020-08-24 15:21:55 <Ariadne> weh.
2020-08-24 15:22:49 <Ariadne> oh i see.
2020-08-24 15:22:51 <Ariadne> -cpu host is needed
2020-08-24 15:24:18 <minimal> Ariadne: I don't think the issue is specific to VMs, it just happens that I'm using VMs to test my stuff
2020-08-24 15:24:26 <Ariadne> yes
2020-08-24 15:24:27 <Ariadne> but
2020-08-24 15:24:33 <Ariadne> i do not wish to break my production config
2020-08-24 15:59:56 <Ariadne> localhost:~# ifup -n -v servers
2020-08-24 15:59:56 <Ariadne> ifup: changing state of interface servers to 'up'
2020-08-24 15:59:57 <Ariadne> harumph
2020-08-24 16:00:03 <Ariadne> it should bring up the dependency first
2020-08-24 16:00:11 <Ariadne> let me figure out why this is fubar
2020-08-24 16:01:49 <Ariadne> going to write some tests
2020-08-24 16:10:20 <Ariadne> o
2020-08-24 16:30:06 <Ariadne> minimal: heh.  the problem is that ifupdown suppresses failures
2020-08-24 16:33:14 <Ariadne> actually
2020-08-24 16:33:22 <Ariadne> your /e/n/i fails to run on ifupdown too
2020-08-24 16:38:19 <minimal> Ariadne: it was appearing to work with ifupdown previously. Think the last time I used the VLAN VMs was about 1 week ago
2020-08-24 16:38:32 <Ariadne> yes.  it appears to work, but silently fails.
2020-08-24 16:38:45 <Ariadne> and leaves you in a state where it "mostly" works
2020-08-24 16:38:53 <minimal> so what bit didn't work?
2020-08-24 16:39:17 <Ariadne> ipv6
2020-08-24 16:39:23 <Ariadne> those ip errors are about ipv6
2020-08-24 16:39:52 <minimal> NDP?
2020-08-24 16:40:19 <Ariadne> ya
2020-08-24 16:40:26 <Ariadne> it conflicts with the static route
2020-08-24 16:40:41 <Ariadne> anyway, i am working on a solution
2020-08-24 16:42:39 <minimal> Ariadne: removing the IPv6 address and gateway config eliminated the "Host in unreachable" but not the "Network unreachable" during boot
2020-08-24 16:43:09 <maxice8> I am released from hospital, will catch up tomorrow
2020-08-24 16:43:27 <Ariadne> minimal: yes, also we need bring the vlan device itself up
2020-08-24 16:44:50 <minimal> Ariadne: ok, let me know when you've got a new version to test
2020-08-24 16:45:23 <minimal> I'll sit here and invent some more esoteric network configs to plague you with ;-)
2020-08-24 16:46:29 <Ariadne> the other thing is, we need to iterate backwards over the list of executors when taking interfaces down
2020-08-24 16:46:42 <Ariadne> (and also over the dependency tree)
2020-08-24 16:47:04 <Ariadne> the latter is not a must have, but it is more correct
2020-08-24 16:47:41 <minimal> Ariadne: side question, does ifupdown-ng support the "source" directive to include other files?
2020-08-24 16:47:50 <Ariadne> yes, but not yet source-directory
2020-08-24 16:48:55 <minimal> ah, ok. It was actually source-directory that was at the back of my mind - useful for automating the config of things like VPNs rather than having to modify /e/n/i all the time
2020-08-24 16:54:23 <Ariadne> ok, have fixed up the scripts
2020-08-24 16:54:26 <Ariadne> now to fix up ifdown
2020-08-24 17:07:35 <mps> maxice8: good news, hope you are fine
2020-08-24 17:28:41 <Ariadne> minimal: give 0.8.2 a go
2020-08-24 18:12:17 <minimal> @Ariadne: that looks better, tested VM with mgmt (renamed eth0) and servers (VLAN) interfaces and "ip a" output looks as expected. During boot did see a "ifupdown: skipping dependent interface mgmt (of servers)" message
2020-08-24 18:13:06 <Ariadne> yeah that will be fixed in 0.8.3
2020-08-24 18:13:38 <Ariadne> or 0.9 if there is no other regressions to fix
2020-08-24 18:17:43 <minimal> and for other VM with eth0 and servers (vlan) interface again appears ok with message "ifupdown: skipping dependent interface eth0 (of servers)
2020-08-24 18:39:02 <oliv3r[m]> ikke: one downside of course to the 'split packages' thing is that it's not very sustainable, and upstream should resolve this in an upstream manner. As the variants are mutually exclusive, having 2 different users of the library breaks things. I did open an upstream ticket to see if they can resolve this upstream, so that this isusable without variants.
2020-08-24 18:47:04 <ikke> nod, it just shows how it could be done
2020-08-24 18:58:59 <maxice8> I'm back
2020-08-24 18:59:03 <maxice8> What did I miss ?
2020-08-24 19:29:30 <oliv3r[m]> Covid-19 invaded the world
2020-08-24 19:29:41 <maxice8> I wasn't away for that long
2020-08-24 19:29:45 <maxice8> I left germany just as it was ramping up
2020-08-24 19:29:52 <maxice8> and  I mean, in Alpine
2020-08-24 19:34:52 <oliv3r[m]> ikke: it did, and it was very useful :) just waiting for !11679 to be merged so that I can open up the splitting one, but maxice8 was already even faster then that :)
2020-08-24 19:35:43 <maxice8> I left a comment
2020-08-24 19:42:01 <ikke> ifupdown-ng is default now
2020-08-24 19:42:08 <ikke> gcc-10 has been pushed
2020-08-24 19:43:45 <maxice8> gcc-10, nice
2020-08-24 19:50:41 <oliv3r[m]> maxice8: how to handle the 'does this need any rebuilds? find all dependants and trigger a bump in the same MR?
2020-08-24 19:50:56 <oliv3r[m]> (that part is new to me :) )
2020-08-24 19:52:11 <ikke> oliv3r[m]: the output of checkapk (run at the end in CI) will show you
2020-08-24 19:52:20 <ikke>  -usr/lib/libwebsockets.so.15
2020-08-24 19:52:22 <ikke> +usr/lib/libwebsockets.so.16
2020-08-24 19:52:42 <ikke> So everything depending on so:libwebsockets.so.15 needs to be rebuilt
2020-08-24 19:53:37 <oliv3r[m]> which would be everything listed under: https://pkgs.alpinelinux.org/package/edge/main/x86_64/libwebsockets -> required by; right?
2020-08-24 19:53:43 <oliv3r[m]> and those bumps should be part of the same MR?
2020-08-24 19:55:50 <ikke> https://tpaste.us/XgJe
2020-08-24 19:56:15 <oliv3r[m]> those are the ones I found :)
2020-08-24 19:56:40 <ikke> I used ap revdep libwebsockets-dev for that
2020-08-24 19:57:37 <ikke> oliv3r[m]: You want to rebuild those packages at least soon after the main package has been rebuilt, so doing it in the same MR is usually the easiest
2020-08-24 19:58:08 <ikke> It also allows you to get feedback from CI to see if there are any packages that don't build for some reason
2020-08-24 19:59:07 <oliv3r[m]> ok added them as individual commits to the same MR
2020-08-24 19:59:41 <maxice8> If possible add them by repo
2020-08-24 19:59:53 <maxice8> It is up to the maintainer (there is no convention)
2020-08-24 20:00:12 <ikke> the number is small enough, so they can just be individual commits
2020-08-24 20:00:31 <ikke> grouping them per repo is mostly done when there are lots of packages
2020-08-24 20:00:35 <oliv3r[m]> fair nuff, i was going to say, it's 5 packages over 3 repo's :)
2020-08-24 20:00:54 <oliv3r[m]> ok, but next time i'll group them by repo, wasn't sure that was 'ok' as I see mostly individual commits the the git log
2020-08-24 20:02:51 <oliv3r[m]> but how do you deal with incompatible changes? e.g. 1 or 2 packages break from the testing repo, it can't be fixed until the new version is merged, but you can't merge until rdeps are fixed ... that's confusing :)
2020-08-24 20:04:21 <maxice8> The person that did the upgrade tries to fix it, if not possible we see if it is more important to upgrade the package and break or hold it and not break
2020-08-24 20:04:54 <oliv3r[m]> so if x86_64 is 'ok' and 'x86' fails ... :)
2020-08-24 20:05:50 <oliv3r[m]> ah nvm:  fatal: unable to access 'https://gitlab.alpinelinux.org/oliver/aports.git/': Failed to connect to gitlab.alpinelinux.org port 443: Operation timed out
2020-08-24 20:12:45 <oliv3r[m]> hmm, again, x86 fails on a timeout, but x86_64 is good; so that's positive news :)
2020-08-24 20:12:53 <ikke> strange
2020-08-24 20:13:30 <oliv3r[m]> s390x and aarch64 is also good; the other 2 are still building, also indicating no 443
2020-08-24 20:14:31 <oliv3r[m]> retry of that job fixed it, so only that one left, then all is green :)
2020-08-24 20:14:52 <ikke> trying it on the x86 host, and curl seems also to not be able to reach it :/
2020-08-24 20:15:40 <ikke> Now zabbix is also reporting it :/
2020-08-24 20:15:44 <oliv3r[m]> i was typing 'maybe gitlab is having some performance issues' but as it's self-hosted, that's not applicable ...
2020-08-24 20:16:05 <oliv3r[m]> server overload; maxice8 is back, commenting like crazy :)
2020-08-24 20:16:26 <ikke> The webinterface is snappy
2020-08-24 20:16:32 <maxice8> I'm mostly busy trying to get some Homecare from UNIMED
2020-08-24 20:17:37 <ikke> How is it possible that I can ping a host, https is timing out, but I can reach https from somewhere else
2020-08-24 20:17:50 <maxice8> Voodoo Witchcraft
2020-08-24 20:28:14 <oliv3r[m]> but after the 'rebuild' !11679 is now all green :) and on that note, it's time to head to bed
2020-08-24 20:32:33 <detha> ikke: generally that's mtu problems
2020-08-24 20:35:52 <ikke> mtu looks 1500
2020-08-24 20:37:40 <detha> if there's something in the path with <1500, and something that drops ICMP, PMTUD stops working
2020-08-24 20:38:10 <detha> ping with small packets works, SSL negotiation bombs out
2020-08-24 20:38:16 <ikke> I can send 1500 byte packets with do-no-fragment
2020-08-24 20:39:12 <ikke> I do need to set -s to 1472 though
2020-08-24 20:39:32 <ikke> Otherwise I get "ping: local error: message too long, mtu=1500"
2020-08-24 20:40:23 <detha> sounds about right
2020-08-24 20:41:04 <detha> only way to find out is tcpdump, both sides, and see
2020-08-24 20:41:12 <ikke> And some requests succeed, while others time out
2020-08-24 20:41:24 <ikke> I already did from the source, I just see packets sent, non returned
2020-08-24 20:42:30 <ikke> Already fails at the tcp handshake
2020-08-24 20:42:35 <ikke> so nothing ssl related
2020-08-24 20:43:25 <detha> that was the next question. something network/loadbalancer, can be many things
2020-08-25 08:09:47 <mps> ncopa: !10937
2020-08-25 08:10:27 <mps> only one config parameter is removed from previous version in 3.12
2020-08-25 08:11:16 <mps> it works more than 3 weeks on two 3.12 stable without problem
2020-08-25 09:43:59 <ncopa> hum. what happens if a user has that config parameter?
2020-08-25 09:59:21 <mps> that is 'million dollar' question ;)
2020-08-25 09:59:57 <mps> my answer is: I don't know
2020-08-25 10:01:36 <mps> not sure what we should do: use old unsupported and unmaintained version in 3.12 and backport potential secfixes or break users config
2020-08-25 10:19:20 <ikke> Breaking user config is never nice
2020-08-25 10:26:49 <mps> backporting secfixes also is not nice
2020-08-25 10:27:20 <mps> or having sec issues on stable
2020-08-25 13:06:28 <kunkku> does ifupdown-ng support bridges with no configured ports?
2020-08-25 13:07:44 <kunkku> the script in the bridge package allowed specifying "bridge-ports none"
2020-08-25 13:08:11 <kunkku> now this results in a complaint on a non-existent interface (none)
2020-08-25 13:28:33 <maxice8> gcc-10 upgrade needs all D stuff to build due to changes in libphobos
2020-08-25 13:29:07 <Cogitri> All D stuff that builds against gdc's libphobos that is
2020-08-25 13:29:18 <Cogitri> We build most things against ldc I think
2020-08-25 13:29:55 <Cogitri> I think rebuilding ldc and corecollector should do the trick
2020-08-25 13:44:13 <maxice8> made an MR to rebuild them
2020-08-25 13:44:17 <maxice8> thanks
2020-08-25 14:04:47 <Ariadne> kunkku: that is because we use a stub executor to color the dependency graph for bridges.  i can fix the stub to allow `bridge-ports none`.
2020-08-25 14:05:50 <Ariadne> kunkku: ifupdown-ng otherwise still makes use of the pre-existing `bridge` package for now.
2020-08-25 14:05:51 <Ariadne> :)
2020-08-25 14:06:13 <kunkku> another remark: the link executor attempts to put the bridge to the UP state before it is created
2020-08-25 14:06:58 <kunkku> causing a visible error message from /sbin/ip
2020-08-25 14:07:29 <Ariadne> hmm
2020-08-25 14:07:49 <Ariadne> that's because i moved link to pre-up/post-down
2020-08-25 14:07:51 <Ariadne> from up/down
2020-08-25 14:08:37 <Ariadne> but in reality, i don't think we needed to do that.
2020-08-25 14:17:10 <Ariadne> yeah, we don't.  just tested it :)
2020-08-25 14:22:01 <Ariadne> kunkku: i am interested in integrating ifupdown-ng and awall by the way
2020-08-25 14:25:56 <ikke> To automatically add rules when interfaces go up?
2020-08-25 14:26:23 <Ariadne> yes.  consider VRFs, for example.
2020-08-25 14:26:32 <Ariadne> you might want to apply a specific awall configuration to a VRF.
2020-08-25 14:27:28 <Ariadne> i need to work on adding refcounting to the dependency graph
2020-08-25 14:32:26 <kunkku> makes sense
2020-08-25 14:33:21 <kunkku> how about static routes?
2020-08-25 14:36:05 <kunkku> as in https://git.alpinelinux.org/aports/tree/main/static-routing/static-routing
2020-08-25 14:40:04 <Ariadne> yeah we should write an executor for this
2020-08-25 14:40:35 <Ariadne> if you use `ifquery -p route $IFACE` you can get the all matches for route property
2020-08-25 14:40:49 <Ariadne> which is cleaner than
2020-08-25 14:41:28 <Ariadne> route 1.2.3.4,5.6.7.8
2020-08-25 14:41:44 <Ariadne> which i guess is how your addon works :)
2020-08-25 14:43:27 <Ariadne> but your addon will work already with ifupdown-ng in the interim
2020-08-25 14:43:57 <Ariadne> i just think it is cleaner to make use of the fact that ifupdown-ng can support interfaces with multiple properties
2020-08-25 14:48:36 <Ariadne> kunkku: https://github.com/ifupdown-ng/ifupdown-ng/issues/42
2020-08-25 14:49:15 <ikke> Ariadne: Would it make sense to host it on gitlab.a.o? Or do you want to keep it on github?
2020-08-25 14:49:42 <Ariadne> i'm not picky, but non-alpine users are contributing to the project (such as debian developers)
2020-08-25 14:49:49 <Ariadne> so i think github makes most sense
2020-08-25 14:49:50 <Ariadne> :)
2020-08-25 14:49:54 <ikke> alright
2020-08-25 14:50:07 <ikke> They can use their github accounts to log in to gitlab :)
2020-08-25 14:50:12 <ikke> but it's your choice
2020-08-25 14:50:38 <Ariadne> yeah but you know how people can be
2020-08-25 14:51:08 <Ariadne> i think the cat herding is simpler if we use github for upstream ifupdown-ng and normal alpine bug reporting process for alpine user bugs
2020-08-25 14:51:23 <ikke> nod
2020-08-25 14:51:45 <Ariadne> if we say 'why not gitlab.a.o', they will say 'why not salsa.debian.org'
2020-08-25 14:51:46 <Ariadne> ;)
2020-08-25 14:53:09 <ikke> Yeah, if this project is shared with debian, it might make more sense
2020-08-25 14:53:39 <ikke> At that point, real federation would be nice
2020-08-25 14:53:50 <maxice8> federate all the things
2020-08-25 14:54:05 <mps> isn't there gitlab free service like github?
2020-08-25 14:54:27 <Ariadne> yes, but that's just trading one master for another
2020-08-25 14:54:41 <Ariadne> i'm weary of centralized forges at large
2020-08-25 14:54:47 <Ariadne> gitlab is just another centralized forge
2020-08-25 14:54:53 <mps> yes, agree
2020-08-25 14:54:53 <Ariadne> gitlab.com, that is
2020-08-25 14:55:06 <Ariadne> so, may as well use the forge with all the eyeballs
2020-08-25 14:55:07 <mps> but github master is microsoft
2020-08-25 14:55:18 <ikke> network effect is a thing
2020-08-25 14:55:28 <Ariadne> gitlab runs on micros~1 azure
2020-08-25 14:55:35 <Ariadne> kinda of six of one, half dozen of the other
2020-08-25 14:55:36 <mps> I see more and more projects and developers move to gitlab
2020-08-25 14:55:50 <ikke> Ariadne: didn't they move? (though forgot which direction)
2020-08-25 14:56:12 <Ariadne> did they?  i dont pay much attention
2020-08-25 14:56:53 <ikke> either from azure to gcp, or the other way around
2020-08-25 14:57:26 <Ariadne> i could make everyone involved miserable and use sourcehut
2020-08-25 14:57:34 <ikke> haha :D
2020-08-25 14:57:48 <ikke> https://about.gitlab.com/blog/2019/05/02/gitlab-journey-from-azure-to-gcp/
2020-08-25 14:57:50 <ikke> yes, to gcp
2020-08-25 14:57:57 <Ariadne> (which reminds me, i should start working on srht-lists to mailman3 migration someday)
2020-08-25 14:58:18 <Ariadne> there has just been... much more important things to deal with first
2020-08-25 14:58:52 <ikke> and at least for now, it's still working, so nothing pressing
2020-08-25 14:59:28 <mps> yes, in last few days I started to think we should do something about ML
2020-08-25 15:00:20 <mps> I wanted to write about supervision but when thinking of our ML I step back
2020-08-25 15:00:52 <Ariadne> well, we already decided to use mailman3
2020-08-25 15:00:59 <Ariadne> it's just that everyone is busy
2020-08-25 15:01:01 <Ariadne> and the plague hit
2020-08-25 15:01:06 <Ariadne> which made everyone more busy
2020-08-25 15:01:18 <mps> Ariadne: and I'm not assured anymore that we need mailman, maybe something simple wil be ok
2020-08-25 15:01:40 <Ariadne> mps: one of the requirements was the ability to interact with the mailing list from the web
2020-08-25 15:01:51 <Ariadne> mm3 + hyperkitty is only thing i know of that allows that
2020-08-25 15:02:06 <mps> yes, I remember everything
2020-08-25 15:02:09 <ikke> Interact in what kind of way?
2020-08-25 15:02:14 <Ariadne> in fact, that promised ability (which never happened), is why sourcehut was attractive
2020-08-25 15:02:23 <mps> even tested installation in lxc with devuan
2020-08-25 15:02:28 <ikke> Send posts?
2020-08-25 15:02:34 <Ariadne> yes, and manage subscriptions
2020-08-25 15:03:56 <mps> but I can't help much with making mailman3 batteries for Alpine, never programmed in python
2020-08-25 15:04:30 <ikke> I can help with python
2020-08-25 15:04:43 <mps> 
ACTION feels happy

2020-08-25 15:05:26 <ikke> Maybe first step would be creating a migrator from sourcehutdb to mdir
2020-08-25 15:05:37 <Ariadne> yes
2020-08-25 15:05:49 <Ariadne> was going to work on it, just haven't gotten to it yet.
2020-08-25 15:06:02 <Ariadne> i also have a halfway-done packaging of mm3 and hyperkitty
2020-08-25 15:06:05 <ikke> Ok, if I find some time, I can give it a go
2020-08-25 15:06:10 <mps> ikke: mdir? or Maildir?
2020-08-25 15:06:22 <ikke> isn't that the same?
2020-08-25 15:06:34 <ikke> ah, maybe I'm confusing mbox
2020-08-25 15:06:34 <Ariadne> also, there is the matter of the aports list
2020-08-25 15:06:41 <Ariadne> we have not yet terminated it
2020-08-25 15:06:41 <ikke> Ariadne: yup
2020-08-25 15:06:48 <ikke> it still sees some activity
2020-08-25 15:06:52 <Ariadne> even though the conclusion was to do so
2020-08-25 15:06:54 <mps> first time hear for mdir
2020-08-25 15:07:08 <ikke> mps: I meant maildir at least
2020-08-25 15:07:18 <mps> ikke: ok ;)
2020-08-25 15:07:45 <mps> aports ML should be shutdown, there is no much traffic
2020-08-25 17:50:16 <mps> having gtk3 only in makedepends pulls 145 pkgs when building
2020-08-25 17:58:40 <afontain_> the -dev one?
2020-08-25 17:58:59 <mps> yes, ofc
2020-08-25 17:58:59 <Cogitri> The dependency graph will be bigger with gtk4 because that also provides media playback widgets and as such needs gstreamer
2020-08-25 18:11:10 <mps> will someone review for obvious error !11757 I'm excited to push it
2020-08-25 18:11:39 <mps> gtk3 fronted for iwd
2020-08-25 18:11:54 <Cogitri> Gonna take a look
2020-08-25 18:12:07 <mps> thanks :)
2020-08-25 18:57:21 <c705> mps: hi. i just built my own iso with linux-edge. hostname is (none) and root login is not working. was something else changed?
2020-08-25 18:59:39 <mps> login don't depends on kernel
2020-08-25 19:00:04 <mps> also hostname
2020-08-25 19:00:28 <mps> cat /etc/hostname
2020-08-25 19:01:05 <c705> can't login to check even
2020-08-25 19:01:51 <mps> yes ofc, but you can mount iso and look there
2020-08-25 19:02:25 <mps> does it gives you login prompt
2020-08-25 19:02:55 <c705> yeah, i'll check the iso
2020-08-25 19:03:42 <c705> same results with lts
2020-08-25 19:04:05 <mps> also look at /etc/securetty
2020-08-25 19:04:18 <mps> is the 'console' listed there
2020-08-25 19:05:23 <c705> mps: /etc/hostname is fine in the apkovl, console is listed on securetty
2020-08-25 19:06:12 <mps> I don't have other ideas where and what to look for, sorry
2020-08-25 19:07:01 <mps> never built alpine iso
2020-08-25 19:17:02 <kunkku> Ariadne: I'll post comments on static routing later this week
2020-08-25 19:17:24 <Ariadne> sounds good
2020-08-25 19:19:00 <c705> worked on 08-22, now it's totally broken and I haven't made any changes. Guess i'll file a bug
2020-08-25 19:20:07 <MY-R> after musl upgrade few things not working well, especially firefox... :\
2020-08-25 19:21:16 <mps> MY-R: libdbus is problem
2020-08-25 19:21:56 <Cogitri> Ariadne: Have you looked into that yet?
2020-08-25 19:22:04 <Cogitri> Would be really nice to get that fixed ASAP
2020-08-25 19:22:28 <Ariadne> not yet.  this week probably
2020-08-25 19:22:48 <mps> at libdbus?
2020-08-25 19:23:18 <c705> what script is unpacking the apkovl at boot? any idea?
2020-08-25 19:23:39 <MY-R> mps, problem that I cant even compile firefox with disabled dbus/pulse whatever because right before making package I have got error with weird config.mk error with rust...
2020-08-25 19:24:24 <mps> MY-R: I posted git aports patch about two weeks ago here iirc
2020-08-25 19:25:18 <Cogitri> Ariadne: Okie, thanks
2020-08-25 19:26:21 <mps> MY-R: kiss linux have patch to remove libdbus from FF
2020-08-25 19:26:27 <c705> i *think* whats happening is apk add during the unpack errors out and aborts unpacking the apkovl leaving me with an unusable system
2020-08-25 19:27:20 <MY-R> mps, have you got some link around? cus it wasnt only about firefox disable flags :/
2020-08-25 19:28:03 <mps> MY-R: give me some time to find patch which can be applied to aports with 'git am'
2020-08-25 19:28:16 <Cogitri> I think with FF 80 support for disabling libdbus is upstream
2020-08-25 19:28:43 <mps> ah, good news
2020-08-25 19:28:57 <Cogitri> But again, it'd be nice if we could just get the bug fixed in libdbus
2020-08-25 19:29:09 <mps> I read announce about this some time ago
2020-08-25 19:29:40 <MY-R> mps, oh, dont need it now, Im after "few" so wont do it tonight and I have irc session around so can read back log :)
2020-08-25 19:30:08 <mps> I don't agree, you should remove libpulse, dbus, pipewire from FF, imo
2020-08-25 19:30:10 <c705> firefox is only 1 issue, the problem is with libdbus which needs to be fixed
2020-08-25 19:30:17 <c705> other apps are affected
2020-08-25 19:30:34 <MY-R> mps, I dont rly need them at all tbh
2020-08-25 19:30:39 <mps> c705: yes, I also disabled it for mpv
2020-08-25 19:31:11 <MY-R> I think with dbus enabled my screensaver is blocked when watching youtube and that is all what got from it...
2020-08-25 19:31:19 <mps> I mean, libpulse for mpv, not sure about dbus
2020-08-25 19:31:41 <MY-R> pulse I could flush in toilet :
2020-08-25 19:31:45 <MY-R> :\
2020-08-25 19:31:59 <c705> vlc is also affected. probably others
2020-08-25 19:32:05 <mps> dbus is bad by design imo, and I will not elaborate this further
2020-08-25 19:32:13 <c705> my point is that targeting single apps for fix isn't a good solution. the lib needs to be patched
2020-08-25 19:32:22 <Cogitri> You kinda need IPC in some form
2020-08-25 19:33:32 <mps> Cogitri: yes, I agree
2020-08-25 19:34:26 <MY-R> is hard to make "all" apps to cooperate eatch other so it isnt easy task for sure :\
2020-08-25 19:38:19 <c705> after the apkovl unpacks the apks, i see: "grep: /sysroot/etc/inittab: no such file or directory" which crashes the script that is unpacking the apkovl. I haven't changed my process in the last month or so. i will file a bug unless someone can point out something i am doing/not doing correctly
2020-08-25 20:10:22 <mps> MY-R: here is FF-non-bloated patch for aports https://tpaste.us/4EVl
2020-08-25 20:58:45 <mps> Cogitri: thanks for review iwgtk
2020-08-25 20:59:58 <Cogitri> 👍
2020-08-25 21:10:39 <MY-R> mps, cheers mate
2020-08-25 21:11:04 <MY-R> damn, it doesnt looks like a simple patch :D
2020-08-25 21:12:35 <mps> MY-R: well not simple but not complicated too much
2020-08-25 21:16:49 <MY-R> will try it after sleep for sure but I'm kind of tired of compiling stuff and Im feeling like gonna stuck with gentoo again after 10+ years of divorce ;)
2020-08-26 11:03:59 <telmich> <MY-R "will try it after sleep for sure"> To be fair: software complexity has grown immensely since that time and it's impressive that most of the enabled/disable flags in FF and co. actually work somewhat cross-os
2020-08-26 11:10:40 <mps> Ariadne: are you managed to boot your hana chromebook with kernel from https://gitlab.collabora.com/eballetbo/linux/-/tree/topic/chromeos/somewhat-stable-5.8
2020-08-26 11:37:29 <Ariadne> most: haven't tried yet.  want to make a backup of the system first
2020-08-26 11:38:32 <mps> hm, you mean mps and not most?
2020-08-26 11:42:07 <Ariadne> yes
2020-08-26 11:42:11 <Ariadne> on phone
2020-08-26 11:42:22 <mps> last few days I'm talking with Enric on #linux-mediatek to fix some drivers and dts for linux-next
2020-08-26 11:42:42 <mps> np
2020-08-26 11:43:14 <Ariadne> could be nice if we could get everything in mainline
2020-08-26 11:44:08 <mps> he is trying hard but I think you know it is not easy task to 'mainline' something in kernel
2020-08-26 11:44:28 <mps> but, most things are already mainlined
2020-08-26 11:45:56 <mps> not much people run native linux on these old chromebooks
2020-08-26 11:46:22 <mps> so testing and fixing goes slow
2020-08-26 11:47:41 <mps> Enric told me that he knows only me and he uses elm-oak
2020-08-26 11:48:49 <mps> and I think your deep knowledge would be useful
2020-08-26 11:50:52 <mps> if we manage to make these devices working maybe people will start to buy these abandoned boxes for little money
2020-08-26 12:02:01 <Ariadne> yep
2020-08-26 12:02:05 <Ariadne> I dropped by
2020-08-26 13:42:51 <mps> maxice8: just wanted to click Merge for f2fs-tools :)
2020-08-26 13:43:00 <maxice8> the CLI was faster :D
2020-08-26 13:43:08 <maxice8> even with the rebase process being an absolute dumpster fire
2020-08-26 13:43:11 <mps> I see ;)
2020-08-26 13:44:11 <mps> anyway, number of MRs is going down
2020-08-26 13:44:19 <maxice8> too high
2020-08-26 13:44:22 <maxice8> over 100 is too high
2020-08-26 13:44:45 <mps> 153, not too much, imo
2020-08-26 13:44:49 <maxice8> 50 to 75 is the sweet spot
2020-08-26 15:13:23 <mmlb[m]> hey all, I've just noticed that mkinitfs has no license in source (https://gitlab.alpinelinux.org/alpine/mkinitfs) but shows as gpl2 in aports. Seems like an oversight in mkintifs or maybe non of the repos have licenses by some blanket ("all alpine files are under $license) somewhere (which would be strange), so I went looking at other repos in gitlab.alpinelinux.org and see a mix of un-licensed and MIT repos.
2020-08-26 15:14:22 <mmlb[m]> I'd like to fix atleast mkinitfs and would be happy to do the others too if thats wanted.
2020-08-26 15:14:47 <mmlb[m]> Should I go and start opening PRs or will someone else take care of it?
2020-08-26 16:05:28 <Ariadne> minimal: it hung because I forgot set -e in the script :p
2020-08-26 16:05:35 <Ariadne> I fixed it :)
2020-08-26 16:07:31 <minimal> Ariadne: the boot hang? Oh, I was off trying to see if cloud-init was playing bad and hanging lol
2020-08-26 16:07:42 <Ariadne> yeah
2020-08-26 16:07:57 <Ariadne> the scripts we have now are temporary
2020-08-26 16:08:11 <Ariadne> I plan on replacing them with programs that speak netlink directly
2020-08-26 16:08:49 <minimal> moving targets ;-)
2020-08-26 16:09:48 <Ariadne> having executors in C means we can have nice error messages :)
2020-08-26 16:09:51 <minimal> the change to my cloud-init package to depend on ifupdown-ng rather than ifupdown went through yesterday
2020-08-26 16:10:05 <Ariadne> While setting MTU: Invalid argument
2020-08-26 16:10:07 <Ariadne> for example
2020-08-26 16:10:45 <Ariadne> ah you should have pinged me
2020-08-26 16:10:52 <Ariadne> I could have made it go through faster :)
2020-08-26 16:12:56 <minimal> sorry for the mtu misdirection - it seems it was added to my config as part of a rationalisation across archs (I have Ansible scripts that build ready-to-go Alpine VM images and physical machine images for x86_64, armv7, and aarch64 including for RPI) and the MTU setting was already in place for non-RPIs and accidentally got added to RPIs.
2020-08-26 16:13:41 <Ariadne> well ifupdown is kind of a black box
2020-08-26 16:14:11 <Ariadne> so I consider it a user story for what to improve :)
2020-08-26 16:14:33 <Ariadne> but really we've dialed in ifupdown-ng very quickly.
2020-08-26 16:14:41 <Ariadne> at least the core of it.
2020-08-26 16:15:28 <minimal> as for the package MR approval - yeah I noticed recently that getting stuff merged is a hit hit-and-miss and takes several days typically (I had a MR for the older version of cloud-init just to change the ifupdown->ifupdown-ng dependancy and I closed it after a day or so as the new ver was released so that MR was no longer needed)
2020-08-26 16:20:55 <minimal> Ariadne: happy to have helped you shake down ifupdown-ng. I see 0.8.4 is out. Does that have the change you mentioned? I'll test that shortly.
2020-08-26 16:21:11 <Ariadne> 0.8.4 has set -e yeah
2020-08-26 16:46:12 <minimal> ncopa: Hi, wanted to chat about my comment in Issue 11889
2020-08-26 17:14:22 <ikke> #11889
2020-08-26 17:15:46 <nmeum> is it just me or does the apk add -X flag no longer work? e.g. apk add -X ~/pkg/community foobar
2020-08-26 17:16:02 <nmeum> > apk: unrecognized option: X
2020-08-26 17:16:29 <minimal> nmeum: yeah there's a issue already raised for this by someone
2020-08-26 17:16:48 <minimal> #11890
2020-08-26 17:17:08 <nmeum> ah, nice
2020-08-26 19:53:47 <mps> anyone experienced problems with libseccomp when building pkgs on edge
2020-08-26 19:54:12 <ikke> I don't recall any issues
2020-08-26 19:54:57 <mps> zathura 0.4.6 fails
2020-08-26 19:55:43 <ikke> is that on docker or lxc?
2020-08-26 19:55:49 <mps> lxc
2020-08-26 19:55:52 <ikke> hmm, ok
2020-08-26 19:56:51 <mps> I will put it aside for now, don't have much time to investigate problem
2020-08-26 19:57:06 <mps> hm, maybe I can try native build
2020-08-26 19:58:03 <mps> but enough for today
2020-08-26 19:59:55 <mps> same problem on native build :(
2020-08-26 20:03:46 <mps> hah, using its test and not alpine custom test.sh works
2020-08-26 20:06:27 <ikke> so it's just the tests that are failing?
2020-08-26 20:06:40 <mps> yes
2020-08-26 20:06:58 <mps> alpine have custom test.sh
2020-08-26 20:07:08 <ikke> Yeah, saw it
2020-08-26 20:07:24 <mps> this fails, running 'ninja -C build test' works
2020-08-26 20:08:10 <mps> but now 'abuild -r' fail because of fish-completion
2020-08-26 20:12:11 <mps> huh, amove is there :\
2020-08-26 20:12:35 <ikke> mps: there are built-in functions now
2020-08-26 20:12:39 <ikke> so maybe just use those?
2020-08-26 20:12:57 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1986
2020-08-26 20:13:17 <ikke> It's exactly the same though
2020-08-26 20:13:27 <ikke> What is the error>?
2020-08-26 20:15:14 <mps> heh, will look
2020-08-26 20:16:00 <mps> mv: can't rename '/home/mps/aports/community/zathura/pkg/zathura/usr/share/fish/completions': No such file or directory
2020-08-26 20:16:25 <ikke> did they remove the fish completion files?
2020-08-26 20:16:26 <ikke> or move
2020-08-26 20:17:40 <mps> no, but I think this is probably meson/ninja file bug
2020-08-26 20:17:45 <ikke> ah ok
2020-08-26 20:17:47 <ikke> data/fish-completion.in exists in hte source
2020-08-26 20:18:01 <mps> yes, but didn't in pkg subdir
2020-08-26 20:20:05 <ikke> Installing /home/build/aports/community/zathura/src/zathura-0.4.6/build/data/zathura.fish to /home/build/aports/community/zathura/pkg/zathura/usr/share/fish/vendor_completions.d
2020-08-26 20:20:43 <mps> yes
2020-08-26 20:20:52 <ikke> So installed in a different directory
2020-08-26 20:22:23 <mps> pkg/zathura/usr/share/fish/vendor_completions.d/zathura.fish
2020-08-26 20:22:29 <ikke> yes
2020-08-26 20:23:40 <mps> I don't know what is proper solution. rename to old fish-completion or install this new file somewhere
2020-08-26 20:25:57 <ikke> fish_compdir = join_paths(datadir, 'fish', 'vendor_completions.d')
2020-08-26 20:26:10 <ikke> in data/meson.build
2020-08-26 20:26:26 <maxice8> should be installed to /usr/share/fish/completions
2020-08-26 20:26:59 <ikke> I see it's trying to do something with pkg_conf
2020-08-26 20:27:01 <mps> could someone of you take it, I don't know much about meson/ninja
2020-08-26 20:27:16 <ikke> https://tpaste.us/adnm
2020-08-26 20:27:23 <mps> rm test.sh
2020-08-26 20:27:28 <ikke> patch is quite easy
2020-08-26 20:28:04 <mps> and change check to  'ninja -C build test'
2020-08-26 20:28:21 <ikke> mps: https://tpaste.us/qlQO
2020-08-26 20:29:03 <mps> thanks
2020-08-26 20:29:48 <ikke> Note that I've never done anything with meson before
2020-08-26 20:32:09 <mps> passed with your patch
2020-08-26 20:33:33 <mps> hmm, how did you knew what to do then? (I know answer: you have much experience with similar things and big knowledge)
2020-08-26 20:34:09 <ikke> I just grepped for vendor_completions.d
2020-08-26 20:34:15 <ikke> And saw that was the only reference to it
2020-08-26 20:34:35 <ikke> before I looked in the pkgdir for anything called fish
2020-08-26 20:34:39 <ikke> so I found that directory
2020-08-26 20:39:04 <mps> ikke: !11786
2020-08-26 20:40:22 <mps> I'm going to drink wine
2020-08-26 20:40:30 <ikke> not a bad idea
2020-08-27 09:10:20 <clandmeter> algitbot: ping
2020-08-27 09:10:30 <clandmeter> thought this channel is broken
2020-08-27 09:10:43 <clandmeter> im going to restart gitlab with new patch release
2020-08-27 09:25:08 <mps> upgraded xorg-server segfault on edge aarch64, don't have time to investigate
2020-08-27 09:26:27 <Cogitri> Seems like it fails to build on other arches too unfortunately
2020-08-27 09:26:35 <Cogitri> Looking into fixing libre office right now
2020-08-27 09:52:15 <MY-R> looks like firefox upgrade to 80 fixed issue #11815
2020-08-27 09:54:04 <Cogitri> Nice
2020-08-27 09:55:31 <MY-R> before every time when closed firefox I had to rerun it multiple times to have working youtube but some sites needed multiple refresh to get working too... so hope it fixed all that
2020-08-27 10:03:36 <MY-R> or didnt fix, whatever, but looks like working much better...
2020-08-27 11:27:06 <Cogitri> `WARNING: libnetfilter_cttimeout-1.0.0-r0: no checksum for file usr/lib/libnetfilter_cttimeout.so.1.0.0` https://gitlab.alpinelinux.org/runlevel5/aports/-/jobs/193901
2020-08-27 11:30:36 <Cogitri> Maybe that started to happen w/ the new apk?
2020-08-27 11:49:05 <mps> (modern developers are much too influenced by marketing and academic nonsense)
2020-08-27 12:58:29 <ncopa> Cogitri: that could be a bug in updated apk tools
2020-08-27 12:59:10 <Cogitri> Yeah, maybe a bug in the new apk-tools or maybe some new behaviour that uncovers a bug elsewhere
2020-08-27 13:00:12 <ikke> PureTryOut[m] reported a similar bug
2020-08-27 13:00:25 <ikke> Or error I must say
2020-08-27 13:01:48 <insep_> "Cogitri" (https://matrix.to/#/@freenode_Cogitri:matrix.org): someone had similar issue with installkernel
2020-08-27 16:35:43 <ikke> rust 1.46 is out
2020-08-27 16:37:07 <Cogitri> Neat, will look into bumping it at the weekend
2020-08-27 16:37:15 <Cogitri> Once libre office is happy on the builders :^)
2020-08-27 16:38:13 <Cogitri> https://tpaste.us/5ELj does one of you know why libbost_datetime would have missing symbols like this only on the builders?
2020-08-27 16:38:22 <Cogitri> CI built it fine and building it locally just works too
2020-08-27 16:52:08 <ikke> nm -D output of libboost-date_time.so: https://tpaste.us/vJpM
2020-08-27 16:52:14 <ikke> on the aarch64 builder
2020-08-27 16:57:05 <ikke> so I guess the symbol is there?
2020-08-27 16:57:31 <ikke> hmm, U means undefined
2020-08-27 17:02:25 <mps> Cogitri: FF 80 which I rebuilt without dbus (and other libpulse, pipewire) works fine on aarch64
2020-08-27 17:04:17 <mps> maybe to put it somewhere on dev.a.o as temporary solution for users who needs it, till dbus is fixed
2020-08-27 17:09:38 <ikke> Cogitri: ldd reports a lot of missing symbols (where __cxa_free_exception is the first one mentioned), not sure if that's expected or not
2020-08-27 17:09:57 <ikke> fyi, it also happens when I install it in a docker container
2020-08-27 17:10:29 <Cogitri> mps: imho just make a MR and let's roll this out to aports
2020-08-27 17:10:38 <Cogitri> ikke: Huh, how does this work in rootbld then
2020-08-27 17:10:44 <Cogitri> This is so weird
2020-08-27 17:12:36 <mps> Cogitri: ok
2020-08-27 18:51:39 <smcavoy> hello I am noticing that aport merge request builds fail when run from all non x86 systems. Failure is a connection refused from downloads.sourceforge.net:443  anyone else notice these?
2020-08-27 18:56:45 <ikke> Haven't seen that yet
2020-08-27 18:57:36 <smcavoy> here is a link to a build  https://gitlab.alpinelinux.org/smcavoy/aports/-/pipelines/43692
2020-08-27 18:57:50 <smcavoy> been happening since at least yesterday
2020-08-27 19:00:22 <ikke> Hmm, trying to run curl from one of the CI hosts does work
2020-08-27 19:01:25 <ikke> and now it's continuing as well
2020-08-27 19:03:06 <smcavoy> what changed?
2020-08-27 19:03:17 <ikke> No clue
2020-08-27 19:03:26 <ikke> Guess something with sourceforge, but hard to tell
2020-08-27 19:03:29 <ikke> ppc64le is failing btw
2020-08-27 19:03:42 <ikke> I think you should add `update_config_guess` to prepare()
2020-08-27 19:03:52 <ikke> 'configure: error: cannot guess build type; you must specify one'
2020-08-27 19:04:31 <smcavoy> I thinking the build machines might have been black listed/throttled for access to sourceforge
2020-08-27 19:05:14 <ikke> yes, perhaps, though strange it happened to most of them on the same time (they are different hosts, sometimes in different parts of the world, from different providers)
2020-08-27 19:10:50 <smcavoy> ikke: thanks for the update_config_guess that fixed the ppc64le
2020-08-27 19:17:19 <mps> Cogitri: !11811 feel free to change whatever you like
2020-08-27 19:24:21 <Cogitri> Can we leave pipewire on?
2020-08-27 19:26:17 <nmeum> I still think the right way to address this issue would be to debug it and find out why it's freezing with dbus enabled. how knows maybe we actually discover a bug in dbus or something
2020-08-27 19:26:26 <nmeum> that being said i am also very annoyed by firefox freezing all the time
2020-08-27 19:26:36 <nmeum> and don't have the time to do the debug myself currently
2020-08-27 19:27:50 <mps> Cogitri: I didn't tested with pipewire enabled, but probably it can be enabled
2020-08-27 19:28:43 <mps> i removed it because I don't need it for my personal use (and that is what consider bad in MR) and because that told you can do whatever you like
2020-08-27 19:29:05 <Cogitri> Yes, fixing dbus certainly is the right way forward
2020-08-27 19:29:24 <Cogitri> But no one did that in the last week, so I think a functioning browser would be good for now
2020-08-27 19:29:29 <mps> nmeum: I read somewhere that dbus have bug report for few years but upstream didn't fixed it
2020-08-27 19:30:28 <mps> glibc have workaround (which is wrong thing to do) but musl 1.2.1 doesn't
2020-08-27 19:30:40 <mps> musl is right, imo
2020-08-27 19:30:59 <mps> `don't hide bugs` is good moto for software
2020-08-27 19:32:00 <nmeum> link to that dbus bug report?
2020-08-27 19:33:06 <mps> don't have it, sorry
2020-08-27 19:35:35 <mps> nmeum: maybe this https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-sysdeps-unix.c#L4029 as nsz told on #musl
2020-08-27 19:35:49 <mps> maybe this is problem*
2020-08-27 19:41:10 <nmeum> I don't know the dbus code base
2020-08-27 19:42:12 <mps> hmm, maybe this https://gitlab.freedesktop.org/dbus/dbus/-/issues/173
2020-08-27 19:42:26 <mps> though not years old but months ;)
2020-08-27 19:42:52 <nmeum> well, at least the headline sounds like it might be related
2020-08-27 19:43:02 <mps> also I don't know dbus (actually I think it bad idea to have it)
2020-08-27 19:43:10 <nmeum> maybe post this in the alpine firefox issue?
2020-08-27 19:43:43 <mps> I'm not sure, because that I trying to be quiet
2020-08-27 19:47:44 <nmeum> hm?
2020-08-27 19:52:44 <mps> that is from #musl `2020-08-08 22:38........... nsz| mps: both libpulse and libdbus have issues so if you removed libpulse that's not expected to solve all the hangs`
2020-08-27 19:53:58 <mps> if #musl is archived somewhere full discussion can be read
2020-08-27 19:55:01 <nmeum> took the liberty of posting the freedesktop link in the issue
2020-08-27 19:55:33 <mps> fine
2020-08-27 20:37:14 <nmeum> found yet another time_t issue in main/dpkg by enabling the test suite for dpkg
2020-08-27 20:37:15 <nmeum> fun fun fun
2020-08-27 20:57:03 <nmeum> what's the easy way to fix a program which uses '%ld' to print a time_t? use '%lld' and cast the argument to (long long int) to prevent a -Wformat warning on 64-bit arches?
2020-08-27 20:58:15 <nmeum> ah, existing patches seem to use PRId64 from inttypes.h that's probably "better"
2020-08-27 21:10:19 <Cogitri> Good that the issue was caught by tests though :)
2020-08-27 21:10:47 <nmeum> yeah, -Wformat also caught it but -Werror wasn't set
2020-08-27 21:11:38 <nmeum> !11812 will merge it tomorrow i guess
2020-08-27 21:16:26 <Cogitri> Maybe you also feel like taking a look at libre office? :P
2020-08-27 21:16:42 <Cogitri> Reverted the change to clang now since that didn't pass configure for some reason
2020-08-27 21:16:49 <Cogitri> But it still fails with GCC10
2020-08-27 21:17:03 <Cogitri> ```
2020-08-27 21:17:03 <Cogitri>     /usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/buildozer/aports/community/libreoffice/src/libreoffice-6.4.6.2/workdir/CxxObject/sot/source/sdstor/ucbstorage.o: in function `UCBStorage_Impl::Init()':
2020-08-27 21:17:03 <Cogitri> ```
2020-08-27 21:17:03 <Cogitri>     ucbstorage.cxx:(.text+0x67e0): undefined reference to `non-virtual thunk to cppu::WeakImplHelper<com::sun::star::io::XInputStream>::acquire()'
2020-08-27 21:24:48 <Cogitri> We should also backport ff-esr 78 to 3.12
2020-08-27 21:26:20 <mps> i thought of that but I don't have 'big' machine with 3.12 to test build
2020-08-27 21:28:11 <nmeum> Cogitri: what's the problem with libre office?
2020-08-27 21:28:18 <mps> and not only -esr but 80 also
2020-08-27 21:36:29 <nmeum> that libreoffice error looks fun but I am calling it a day for now
2020-08-27 21:44:24 <Cogitri> Same here
2020-08-27 23:09:57 <awilfox> hi so as of last month, the Alpine wiki incorrectly says that Adélie is based on Alpine.
2020-08-27 23:10:08 <awilfox> we share almost no code outside of apk-tools and a few APKBUILDs (mostly gcc)
2020-08-27 23:10:22 <awilfox> it looks like first incorrect diff was https://wiki.alpinelinux.org/w/index.php?title=Installation&diff=17853&oldid=17852
2020-08-27 23:10:26 <awilfox> please fix this
2020-08-27 23:12:53 <maxice8> Should be fixed
2020-08-28 00:56:41 <awilfox> thank you!
2020-08-28 00:56:47 <maxice8> welcome
2020-08-28 00:56:52 <dalias> :)
2020-08-28 01:07:13 <maxice8> ?
2020-08-28 08:12:08 <mps> Cogitri: https://github.com/kisslinux/repo/blob/master/extra/firefox-esr/patches/no-dbus.patch
2020-08-28 08:13:03 <ikke> nmeum already linked to that in #alpine-commits
2020-08-28 08:29:35 <Cogitri> mps: Sorry to ask you that after I broke it, but since you already used that patch earlier: Would you mind making a MR for ff-esr with that patch?
2020-08-28 08:29:50 <Cogitri> Currently at work, I can look at it later today otherwise
2020-08-28 08:34:27 <mps> Cogitri: I'm also at $work, but will try to find some time
2020-08-28 08:34:57 <Cogitri> Thanks! :)
2020-08-28 08:36:26 <mps> (even I'm owner of gesellshaft it is not easy to find free time always)
2020-08-28 09:01:49 <fcolista> can someone please remember me how can I update a MR? I've sent a patch that I need to update
2020-08-28 09:02:05 <fcolista> (i really need to write this down)
2020-08-28 09:02:28 <ikke> fcolista: locally amend / the commit, the force push to the same branch
2020-08-28 09:02:35 <ikke> amend / rebase*
2020-08-28 09:02:56 <fcolista> git commit --amend ; git force push
2020-08-28 09:02:59 <fcolista> ?
2020-08-28 09:03:21 <ikke> git push --force-with-lease <remote> <branchname> # safer version
2020-08-28 09:03:33 <fcolista> ah ok
2020-08-28 09:03:36 <ikke> where <remote> is the remote of your fork
2020-08-28 09:03:37 <insep_> just push to the same branch your mr is based of
2020-08-28 09:28:54 <PureTryOut[m]> Cogitri: why did you disable Pulse on Firefox as well?
2020-08-28 09:29:33 <Cogitri> PureTryOut[m]: There's a similar bug in libpulse too
2020-08-28 09:36:31 <mps> 
ACTION dreams that bug will stay forewer ;-})

2020-08-28 09:44:19 <insep_> 
ACTION wonders if apulse has the same issue

2020-08-28 09:44:48 <ikke> It's impossible to cater both people who want a complete desktop experience and a minimalist system
2020-08-28 09:45:29 <PureTryOut[m]> Really? How can both libpulse and libdbus start acting up at the same time?
2020-08-28 09:46:24 <ikke> PureTryOut[m]: It's the same issue that we have with other projects
2020-08-28 09:47:03 <mps> ikke: it is not impossible. people can choose distros like debian/fedora if they want 'complete DE'
2020-08-28 09:47:06 <ikke> They do some work after fork which is not async safe, which glibc has mitigations for, but musl not
2020-08-28 09:47:43 <mps> other can choose minimalistic distro as was alpine when I started to use it
2020-08-28 09:48:23 <Cogitri> PureTryOut[m]: They both started to act up after musl 1.2.1 because that switched the malloc implementation and the new one is very good at triggering that bug
2020-08-28 09:48:46 <mps> alpine now looks like a car working as truck
2020-08-28 09:48:54 <ikke> same with openjdk, libvirt, qemu
2020-08-28 09:50:56 <PureTryOut[m]> Cogitri: ah that makes more sense
2020-08-28 09:51:33 <insep_> what malloc are they using now?
2020-08-28 09:51:47 <Cogitri> mallocng
2020-08-28 09:52:15 <Cogitri> https://github.com/richfelker/mallocng-draft
2020-08-28 09:55:28 <insep_> ty
2020-08-28 10:04:00 <mps> hmm, pipewire depends on dbus
2020-08-28 10:05:27 <Cogitri> Yup, but maybe it doesn't trigger the same bug
2020-08-28 10:06:02 <mps> it doesn't build
2020-08-28 10:07:05 <mps> I will now try to build it on armv7 without pipewire in makedeps
2020-08-28 10:07:13 <Cogitri> Ah, it needs --enable-dbus ?
2020-08-28 10:08:12 <mps> not sure, but build failed because can't find libdbus symbols in linking phase
2020-08-28 10:09:07 <Cogitri> Hm
2020-08-28 10:09:45 <Cogitri> Ariadne: fwiw the libreoffice seems to be on GCC10
2020-08-28 10:59:21 <tmlind> fyi, i'm now seeing xorg segfault on startx at least on armv7.. downgrade xorg-server 1.20.9-r0 -> 1.20.8-r3 makes it work again
2020-08-28 11:00:13 <mps> also on aarch64
2020-08-28 11:00:23 <tmlind> ok
2020-08-28 11:37:15 <mps> disabled pipewire in firefox-esr and remove patch fixes build on armv7 lxc
2020-08-28 11:45:42 <tmlind> msp: i noticed firefox non-esr has some alingment exception on armv7, might be javascript related
2020-08-28 11:46:25 <tmlind> mps: sorry meant mps
2020-08-28 11:47:03 <Cogitri> mps: Ah nice, thanks for taking care of it
2020-08-28 11:48:45 <mps> Cogitri: I'm building now on x86_64 to double check before push
2020-08-28 11:49:04 <Cogitri> Okie 👍
2020-08-28 11:51:10 <mps> tmlind: for long time I didn't run 'firefox non-esr' on armv7 so can't check
2020-08-28 12:27:55 <tmlind> mps: ok, sounds like esr will be usable soon though :)
2020-08-28 12:36:04 <mps> tmlind: just pushed it to builders. Hope it will pass on them now as it passed on my two lxcs
2020-08-28 12:57:44 <mps> tmlind: what is your armv7 machine
2020-08-28 13:00:58 <tmlind> mps: i'm using droid4 as my phone and laptop with lapdock with alpine :)
2020-08-28 13:04:59 <tmlind> mps: with lxc you mean some container/qemu setup? or some machine named lxc? :)
2020-08-28 13:09:49 <mps> tmlind: lxc containers
2020-08-28 13:10:33 <tmlind> mps: yeah ok
2020-08-28 13:10:39 <mps> droid4 as phone? do you have any link
2020-08-28 13:11:30 <tmlind> mps: yeah there's some conf videos, and there's a web page on using it with alpine, let me find it for you
2020-08-28 13:12:05 <wsinatra> tmplind: really curious to see the lapdock setup, that sounds fascinating
2020-08-28 13:12:36 <tmlind> here's the alpine bring up info page:
2020-08-28 13:12:39 <tmlind> https://guidelinuxphone.wordpress.com/
2020-08-28 13:13:22 <tmlind> phone calls are still a bit work in progress.. me and pavel have a ofono branch though that's somewhat usable
2020-08-28 13:13:47 <MartijnBraam> oh neat, should integrate that in postmarketOS :D
2020-08-28 13:14:20 <insep_> dang it, i was about to send it to you :(
2020-08-28 13:14:25 <tmlind> wsinatra: mainline v5.8 kernel works pretty much well enough with lapdock, i have some pending patches mostly for voicecalls
2020-08-28 13:15:21 <tmlind> MartijnBraam: yeah i guess pmos should work too :) except the sucky accelerated graphics that still need closed source blobs
2020-08-28 13:15:38 <MartijnBraam> yeah :(
2020-08-28 13:16:04 <insep_> hm, maybe they will work with gcompat
2020-08-28 13:16:21 <MartijnBraam> they barely work on the intended system
2020-08-28 13:16:31 <tmlind> heh i tried nope, can't init sgx with alpine gcopmat
2020-08-28 13:16:38 <wsinatra> tmlind: Very interesting work, I've been using my n900 with pmOS as a on the go dev station, the droid4 has double the resources
2020-08-28 13:16:45 <wsinatra> tempting to look into that
2020-08-28 13:17:16 <MartijnBraam> I have the droid 4 here but didn't manage to get it to boot pmos yet, kernel just refuses to do anything after kexec'ing
2020-08-28 13:17:17 <tmlind> wsinatra: yeh droid4 is the community upgrade for n900 :)
2020-08-28 13:17:40 <tmlind> MartijnBraam: which kernel are you testing with?
2020-08-28 13:18:00 <MartijnBraam> I think it was the maemo leste kernel at the time
2020-08-28 13:18:30 <tmlind> MartijnBraam: yeah ok maemo leste is using the mainline kernel with the pending voice call patches, should work
2020-08-28 13:18:39 <mps> wait, I have two n900 somewhere in 'trash'
2020-08-28 13:18:52 <tmlind> MartijnBraam: what's your bootloader? hopefully droid4-kexecboot?
2020-08-28 13:19:15 <mps> and what is lapdock?
2020-08-28 13:19:31 <wsinatra> mps: dig them out and put pmOS on them, it takes 15 minutes, and you end up with a solid mobile sysadmin/dev tool
2020-08-28 13:19:54 <MartijnBraam> I also should have a lapdock somewhere :D
2020-08-28 13:20:15 <tmlind> mps: motorola did a series of usb + hdmi docks at some point, it's a laptop dock
2020-08-28 13:20:18 <mps> wsinatra: thanks for idea
2020-08-28 13:20:44 <MartijnBraam> lapdock is basically the same thing as the nexdock but a decade earlier
2020-08-28 13:20:45 <mps> but I would prefer alpine
2020-08-28 13:21:10 <tmlind> mps: yeah i'm just using plain alpine
2020-08-28 13:21:12 <wsinatra> mps: agreed there honestly. I appreciate the pmOS work, but plain Alpine is nice
2020-08-28 13:22:02 <MartijnBraam> tmlind: I have kexecboot yes
2020-08-28 13:22:16 <mps> well, my current 'notebook' is less than 1Kg in weight, n900 is little less :)
2020-08-28 13:22:42 <insep_> pmos is alpine <del> + bloat</del>
2020-08-28 13:22:58 <tmlind> MartijnBraam: well let me know if you need help booting it, do you have a 3.3V usb serial to wire to the usb port for debug serial console? see muru.com/linux/d4 for wiring
2020-08-28 13:23:23 <MartijnBraam> nope, don't have that debug cable yet
2020-08-28 13:24:24 <wsinatra> insep_: yeah it is alpine, I haven't had any issues with it on my n900, and the tools/community are nice. But it makes sense that the folks hanging out in the alpine-devel chat want just alpine :)
2020-08-28 13:24:56 <tmlind> MartijnBraam: hmm so does your lcd stay blank or does anything come up after kexec?
2020-08-28 13:25:34 <MartijnBraam> I currenlty get a screen half filled with random noise
2020-08-28 13:26:07 <tmlind> MartijnBraam: ok so that sounds like you're booting to the stock android that's trying to start battery charging mode
2020-08-28 13:26:24 <MartijnBraam> oh yeah right... I don't have the SD in it
2020-08-28 13:26:32 <MartijnBraam> oops
2020-08-28 13:26:52 <tmlind> MartijnBraam: well that usually means the battery is empty, keep it in that mode and check with vol up and down to get it to at least 10%
2020-08-28 13:29:09 <mps_> huh, lost connection when interesting talk is here
2020-08-28 13:33:53 <ikke> mps_: I got an anouncement that they were going to shutdown the freenode server I was connected to, perhaps you were connected to it as well
2020-08-28 13:34:42 <mps_> ikke: no, my router restarted for unknown reason
2020-08-28 13:36:57 <ikke> aha, ok
2020-08-28 13:40:59 <tmlind> hmm thinking of what i have patched.. i have APKBUILD for xf86-video-omap
2020-08-28 13:41:17 <tmlind> that then gets the 3d stuff working with the old driver with closed source blobs
2020-08-28 13:41:41 <tmlind> then i have the pending ofono patches for voice calls
2020-08-28 13:41:53 <tmlind> and then all voicecall related kernel patches
2020-08-28 13:42:17 <tmlind> but in general with those alpine or basically any distro is somewhat usable
2020-08-28 13:43:40 <tmlind> hmm and to get xf86-video-omap built, libdrm needs -Domap=true enabled
2020-08-28 13:44:18 <tmlind> if folks are interested, we could enable xf86-video-omap and the pmos could use it too?
2020-08-28 13:45:18 <Hello71> mps_: https://bpa.st/WQ2Q
2020-08-28 13:47:33 <MartijnBraam> more driver support is always great for pmos
2020-08-28 13:47:46 <MartijnBraam> looks like it's been 10 months since I last messed with the droid :D
2020-08-28 13:48:33 <mps_> Hello71: thanks
2020-08-28 13:48:53 <tmlind> MartijnBraam: heh well the kernel behaves a bit better now, there was at least an issue where some variants did not have emmc working
2020-08-28 13:49:56 <MartijnBraam> hmm I should use that 5.4 kernel?
2020-08-28 13:50:43 <tmlind> MartijnBraam: no take the 5.7 kernel from maemo leste, or even the 5.8 kernel
2020-08-28 13:51:01 <MartijnBraam> ok
2020-08-28 13:51:36 <tmlind> MartijnBraam: or do you just want a git branch with everything to build it?
2020-08-28 13:52:13 <MartijnBraam> I want any kernel tree that boots :D
2020-08-28 13:52:45 <MartijnBraam> this is what I used last time: https://gitlab.com/postmarketOS/pmaports/-/blob/b302b96e2dbe5069b7925f13c078365060e1db27/device/linux-motorola-maserati/APKBUILD
2020-08-28 13:53:12 <tmlind> hmm well maybe try mainline v5.8 with omap2plus_defconfig, that does not get you voice calls or accelerated graphics though
2020-08-28 13:53:48 <tmlind> maemo leste is using my two branches merged together and omap2plus_defconfig tweaked
2020-08-28 13:55:18 <mps_> isn't that for pmOS IRC
2020-08-28 13:56:27 <mps_> ok sorry, maybe also for alpine
2020-08-28 13:56:49 <tmlind> mps_: well for kernel we can't yet use linux-lts without heavy patching :)
2020-08-28 13:57:10 <mps> tmlind: what about linux-edge
2020-08-28 13:57:34 <tmlind> mps: oh i did know know there is such a thing, is that on v5.8?
2020-08-28 13:57:48 <mps> yes :)
2020-08-28 13:57:51 <mps> in testing
2020-08-28 13:57:54 <tmlind> oh cool :)
2020-08-28 13:58:34 <tmlind> MartijnBraam: so yeah give linux-edge built with omap2plus_defconfig a try, it should boot but with no voice call or accelerated graphics
2020-08-28 13:59:05 <MartijnBraam> looks like linux-edge doesn't do omap currently
2020-08-28 14:00:07 <tmlind> MartijnBraam: that could be added, i'm pretty sure multi_v7_defconfig will not work nice currently for battery life because of all the built-in device drivers.. i might be wrong though
2020-08-28 14:00:34 <tmlind> it's been a while i tried to use multi_v7_defconfig for anything battery operated :)
2020-08-28 14:01:53 <tmlind> i guess the config would need mach-omap2 enabled, then grep "=m" arch/arm/configs/omap2lus_defconfig >> arch/arm/configs/multi_v7_defconfig or something like that
2020-08-28 14:02:54 <mps> Arch alarm have omap in armv7 mp
2020-08-28 14:03:31 <wsinatra> tmlind: what kind of battery life do you see on your droid4?
2020-08-28 14:03:37 <tmlind> mps: ok
2020-08-28 14:04:24 <mps> and linux-edge have omap enabled
2020-08-28 14:04:25 <tmlind> wsinatra: i get about 65 - 75mW power consumption idle with modem online lcd blanked, wlan off
2020-08-28 14:04:50 <tmlind> wsinatra: so maybe 1.5 days easily
2020-08-28 14:04:51 <mps> but no one tested it yet afaik
2020-08-28 14:05:32 <wsinatra> that is a thing of beauty. I was happy to squeeze 6-7 hours out of my nokia
2020-08-28 14:06:04 <tmlind> mps: ok i'll give it a try and add some extra options when i get a chance, might be few weeks before i get around doing it though..
2020-08-28 14:06:32 <tmlind> that is assuming folks are ok enabling more stuff there
2020-08-28 14:06:56 <mps> tmlind: you are talking with maintainer, so sure :)
2020-08-28 14:07:36 <tmlind> mps: ok cool, i'll switch over to using that kernel then :)
2020-08-28 14:08:00 <mps> test reports and fixes are welcome
2020-08-28 14:08:09 <mps> and bug reports ofc
2020-08-28 14:08:37 <tmlind> mps: are all the dtb files now installed?
2020-08-28 14:09:12 <mps> for enabled SOCs yes, I think
2020-08-28 14:09:43 <tmlind> mps: great, the last time i checked only selected dtbs were installed
2020-08-28 14:10:25 <mps> but I don't own much different SOCs/SBCs to test all them
2020-08-28 14:10:25 <tmlind> hmm some of the defconfig changes i've been meaning to patch directly in the mainline kernel but have not gotten around to doing it
2020-08-28 14:11:57 <tmlind> mps: do you need more hardware to test with?
2020-08-28 14:13:36 <tmlind> heh i bough about 20 droid4 few years ago at $6.95 each :) i have given away most of them though
2020-08-28 14:13:39 <mps> I'm quite fine if our users or developers do test and report bugs and solutions
2020-08-28 14:14:07 <tmlind> mps: ok cool
2020-08-28 14:14:25 <mps> but if someone (manufacturers) want to send me some boards I'm not against
2020-08-28 14:15:09 <MartijnBraam> oh that's some cheap droids, paid like $80 for mine
2020-08-28 14:15:36 <tmlind> mps: i might have a droid4 for you if you're interested, but it will be some weeks as whatever few i have left are in a container right now
2020-08-28 14:16:37 <mps> tmlind: with your knowledge and will to make it work I think it is not worth hassles to send it to me
2020-08-28 14:16:49 <tmlind> mps: ok
2020-08-28 14:17:39 <tmlind> MartijnBraam: i bought them before i started to send out patches for the device :p
2020-08-28 14:17:59 <tmlind> $25 seems to be about the going rate now, of course shipping can get expensive
2020-08-28 14:18:34 <MartijnBraam> yeah it was ~$20 for the device and $50 shipping
2020-08-28 14:19:00 <tmlind> MartijnBraam: yup, when i was giving them out, shipping was way more than the devices i sent
2020-08-28 14:20:53 <MartijnBraam> yep, easier to hand them out at fosdem :D
2020-08-28 14:21:16 <mps> my son found battery for acer chromebook for 35 eurs but shipping is 175
2020-08-28 14:21:25 <tmlind> heh
2020-08-28 14:23:22 <tmlind> anyways, let's start with linux-edge patches, then libdrm and xf86-video-omap, and after that it should be usable for alpine. ofono and the voice call patches need me to patch more annoying stuff to get the merged upstream..
2020-08-28 14:24:54 <tmlind> hmm oh so i also have a userspace tool called altalt on my github page that i use for the limited keyboard to be able to login and use it in console mode too
2020-08-28 14:25:40 <tmlind> but i guess for alpine setup to run that's not even needed for installing
2020-08-28 14:27:28 <tmlind> gotta go now to pick up my family, probably won't be around much for a few days except briefly
2020-08-28 14:28:38 <mps> looks like firefox-esr passed on builders
2020-08-28 14:29:11 <tmlind> cool, will give it a try at some point, ttyl
2020-08-28 14:30:10 <mps> ok, please report issue if there are some
2020-08-28 15:06:24 <mps> 2cbc79ffc56ba7e98d3ee4056e4e46063007db9e
2020-08-28 15:06:48 <mps> maxice8: maybe add reason why it is disabled
2020-08-28 15:06:48 <maxice8> I was asked
2020-08-28 15:06:54 <maxice8> I did
2020-08-28 15:07:32 <mps> I mean in commit msg
2020-08-28 15:09:33 <maxice8> I see
2020-08-28 15:10:10 <mps> ok, np, I understand why it is disabled
2020-08-28 15:10:55 <mps> we all make omissions from time to time. keep your good work :)
2020-08-28 15:11:51 <maxice8> ty
2020-08-28 15:13:54 <mps> I have to thank you
2020-08-28 15:14:34 <mps> tmlind: ah, n900 is omap, so I have device for test
2020-08-28 15:42:39 <ncopa> i think someone needs to take care of mips64. the 3.12 builder does not complete its build neither does edge
2020-08-28 15:43:09 <ncopa> i was thining of tagging new releases early next week but cant do that if builds fails
2020-08-28 15:57:53 <ikke> ncopa: was already wondering when a new release would happen
2020-08-28 16:01:01 <ikke> ncopa: I'll try to see if I can get mips green again
2020-08-28 16:14:51 <ncopa> i think Ariadne did some manual trick to build gcc. Dont know what she did
2020-08-28 16:16:27 <ncopa> argh... why does kamailio sudeenly fail to build on 3.12?
2020-08-28 16:29:42 <ikke> She had to disable pre-compiled headers
2020-08-28 16:43:11 <Ariadne> I crosscommpiled it
2020-08-28 17:32:36 <crosbymichael> what do you think the next LTS kernel will be for alpine?
2020-08-28 17:34:11 <mps> 5.9 or 5.10
2020-08-28 17:34:38 <mps> we will know in a month
2020-08-28 17:34:51 <crosbymichael> sgtm
2020-08-28 19:18:23 <MartijnBraam> mps: well looks like I can boot the droid 4 with my fork of the linux-edge kernel with omap2plus enabled at least
2020-08-28 19:19:01 <MartijnBraam> being able to use that kernel for the n900 would also be nice
2020-08-28 19:31:17 <mps> MartijnBraam: thanks for info. looks like we will have more devices supported in near future
2020-08-28 19:36:45 <MartijnBraam> yeah, hopefully 5.9 is functional enough to boot on the pinebook pro
2020-08-28 19:57:00 <mps> in last kernels support is added for a lot of arm devices
2020-08-28 19:58:48 <wsinatra> MartijnBraam: any interest in documenting your process? Or was tmlind's info enough to get everything together?
2020-08-28 19:59:19 <MartijnBraam> the info from tmlind was enough :)
2020-08-28 20:00:35 <wsinatra> excellent, glad to hear that. I ended up hunting down a droid4 earlier this afternoon. Eager to get an upgrade on my n900
2020-08-28 20:00:52 <wsinatra> the good results help me feel like that isn't impulsive, or at least pretend it isn't
2020-08-29 04:55:16 <tmlind> mps, MartijnBraam: good to hear, almost everything necessary should be possible to enable as loadable modules for linux-edge
2020-08-29 05:13:48 <tmlind> mps: both firefox and firefox-esr crash very soon after trying to start on armv7 with some alignment exception
2020-08-29 07:14:43 <mps> tmlind: this bug is introduced if firefox somewhere after 68, 65 version iirc, and looks like not yet fixed
2020-08-29 07:15:46 <mps> s/if/in/
2020-08-29 07:15:46 <alpine-meetbot> mps meant to say: tmlind: this bug is introduced in firefox somewhere after 68, 65 version iirc, and looks like not yet fixed
2020-08-29 07:17:50 <mps> tmlind: re linux-edge, if you have time please report which modules and/or options should be enabled
2020-08-29 07:19:43 <mps> and what you people who use small devices with low RAM thinks about adding https://github.com/dolohow/uksm
2020-08-29 09:36:37 <tmlind> mps: yeah i'll take a look
2020-08-29 11:28:12 <mps> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10708
2020-08-29 11:28:25 <mps> we should not push untested base tools even to edge
2020-08-29 11:28:49 <mps> try to use them for one week on some separate builder
2020-08-29 11:29:16 <_ikke_> A separate builder that no one uses, so nothing is actually discovered?
2020-08-29 11:29:58 <_ikke_> A good test suite should ideally cover most ground
2020-08-29 11:29:58 <mps> developer who pushes base tools could and should use such builders
2020-08-29 11:30:39 <mps> sometimes I do right that on my local builders, and not only for base tools
2020-08-29 11:30:43 <_ikke_> Apparently this issue is not affecting all packages, so might be some kind of edge case
2020-08-29 11:36:26 <afontain_> yeah
2020-08-29 11:36:31 <afontain_> it also seems that rebuilding the failed package works
2020-08-29 11:37:37 <_ikke_> mps: don't get me wrong. We should try to avoid pushing obviously broken stuff
2020-08-29 11:37:50 <_ikke_> but at some point, you need a bigger test base to smoke out the remaining bugs
2020-08-29 11:40:10 <mps> _ikke_: yes, I understand that, and bugs happens, but that doesn't mean we shouldn't start to think to improve things
2020-08-29 11:40:33 <mps> btw, you got old nick
2020-08-29 11:41:56 <_ikke_> hmm, true
2020-08-29 13:37:14 <Ariadne> mps: that is not a bug, but a deprecation warning
2020-08-29 13:37:59 <ikke> Ariadne: regarding what?
2020-08-29 13:39:06 <ikke> ah, regarding the missing checksum
2020-08-29 13:39:36 <ikke> yes, I agree, if the message would be a little bit more clear, than we would know what the issue is
2020-08-29 14:02:59 <ikke> Ariadne: gcc is failing again on mips btw
2020-08-29 14:03:03 <ikke> (segfault)
2020-08-29 14:03:41 <Ariadne> yes I know
2020-08-29 14:03:51 <Ariadne> it's going to remain fucked until gcc fixes the bug
2020-08-29 14:04:16 <Ariadne> since I am going to have to rebootstrap gcc I want to wait until they fix it
2020-08-29 14:10:00 <ikke> ok
2020-08-29 14:10:21 <ikke> ncopa wanted to do a 3.12 release next week, so he wanted the builders to be idle
2020-08-29 14:11:29 <mps> Ariadne: ah, ok.
2020-08-29 19:28:57 <Cogitri> !11848 <- I don't think we need to disable dbus for 3.12 since musl <1.2 doesn't trigger the bug in libdbus?
2020-08-29 20:15:26 <dalias> cogitri, not true. the bug is always present, it's just that child has corrupt state instead of predictable deadlock
2020-08-29 20:15:39 <dalias> but don't disable it
2020-08-29 20:15:45 <dalias> just do the trivial patch to fix it
2020-08-29 20:49:49 <Cogitri> dalias: Well, what would the trivial patch be? That got lost in IRC history since we don't have a gitlab issue for htat
2020-08-29 20:59:16 <mps> Cogitri: yes, for 3.12 disable dbus is not needed, I think. (though I would like :P )
2020-08-29 21:17:15 <Cogitri> Hmm, does someone know to debug pam for !11862 ? Just broke my login by upgrading to it
2020-08-29 21:18:20 <Cogitri> Actually, seems like logging in on a TTY works but not in GDM 🤔
2020-08-29 21:38:26 <Hello71> forgot to merge apk-new?
2020-08-29 21:43:57 <Cogitri> Nop, seems like the new pam dropped some modules GDM wants
2020-08-29 21:51:36 <Cogitri> pam_tally{,2}.so and pam_lastlog.so have been dropped in the latest pam release
2020-08-29 21:51:49 <Cogitri> Would be nice if could grep for those in your /etc/pam.d
2020-08-29 22:01:05 <afontain_> maxice8: huh, I don't think my pantalaimon MR was quite ready though
2020-08-29 22:02:09 <maxice8> I'm merging the ready parts so people have an easier time reviewing the ones that are not ready
2020-08-29 22:03:35 <maxice8> Only the pantalaimon commit remains, if you could rebase and apply the fixes it would put it on the edge of being merged
2020-08-29 22:03:45 <maxice8> Also need to look into enabling tests for olm-python3
2020-08-29 22:04:29 <afontain_> right
2020-08-29 22:04:53 <afontain_> did you disable the broken tests?
2020-08-29 22:05:10 <maxice8> For olm-python3 ?
2020-08-29 22:06:24 <afontain_> I think the dunst dependency was missing on some arch, so that py3-notify2 fails to build
2020-08-29 22:06:31 <maxice8> yes, s390x
2020-08-29 22:06:35 <maxice8> algitbot: retry master
2020-08-30 06:44:02 <mps> ncopa: `aports/community/mutt > aports-glmr` gives this https://tpaste.us/DDqX
2020-08-30 06:49:24 <ikke> mps: do you mean that mutt is also matching neomutt?
2020-08-30 07:06:25 <mps> ikke: looks like it is
2020-08-30 07:07:05 <mps> it does*
2020-08-30 08:07:40 <mps> I got this on 3.12 when run 'abuild -r' for some pkgs https://tpaste.us/Bjvk
2020-08-30 08:08:06 <mps> ERROR: No such package: .makedepends-faultstat
2020-08-30 08:37:46 <ikke> ERROR: faultstat: builddeps failed
2020-08-30 08:38:20 <ikke> It could not install the dependencies, so as a result it could not reinstall them either
2020-08-30 08:38:43 <ikke> deinstall*
2020-08-30 09:00:05 <mps> hmm, not sure. system is in clean state
2020-08-30 09:01:09 <ikke> abuild deps works for me with faultstat
2020-08-30 09:01:12 <ikke> can you try apk fix?
2020-08-30 09:02:18 <mps> ikke: only firefox-esr need fix and I don't want to fix it
2020-08-30 09:05:15 <mps> will check later, right now I'm testing xorg on aarch64 and linux-edge on armv7, so I'm somewhat busy. sorry for annoying you
2020-08-30 09:36:00 <mps> do we really need /usr/bin/Xorg setuid?
2020-08-30 09:49:46 <mps> hmm, link to freenode is unstable in last days or irssi have some issues
2020-08-30 09:50:40 <ikke> I've been disconnected once
2020-08-30 09:51:40 <mps> in last 3 days I'm disconnected few times, and reconnect from irssi didn't worked
2020-08-30 10:14:42 <MY-R> mps, ye I have got disconnection too few days ago, when before for months didnt have even single one
2020-08-30 10:14:52 <MY-R> got irssi too
2020-08-30 10:17:18 <MY-R> but it did reconnect without problem
2020-08-30 10:32:32 <mps> MY-R: maybe I'm impatient to wait for reconnect
2020-08-30 10:33:46 <MY-R> freenode usually disconnect before 300s :D
2020-08-30 10:35:16 <mps> toooo loooong for my nerves :)
2020-08-30 10:36:29 <MY-R> :P
2020-08-30 10:58:22 <Cogitri> Hm, what's the way to recognize things getting stuck due to doing AS-unsafe things between fork() and exec() ?
2020-08-30 10:58:32 <Cogitri> Tilix started getting stuck every so often since the musl upgrade
2020-08-30 10:58:39 <Cogitri> And your main terminal getting stuck isn't fun :)
2020-08-30 10:59:25 <Cogitri> Seems like Tilix waits forever on some futex
2020-08-30 11:47:09 <Cogitri> mps: Maybe the outages are due to Cloudflare? https://www.cloudflarestatus.com/incidents/hptvkprkvp23
2020-08-30 11:49:41 <mps> Cogitri: could be, but last one was because fuse in my house went down
2020-08-30 11:51:17 <llnu_> o/ should ip6tables be part of iproute2 pkg? (im deciding where to fix a missing dependency: wireguard tools depends on iproute2 and doesnt pull ip6tables which is required)
2020-08-30 11:52:04 <mps> usually it is stable for months but last week I lost connections more that 5-6 times
2020-08-30 11:52:13 <mps> llnu_: no. why?
2020-08-30 11:52:30 <llnu_> because iptables was part of iproute2
2020-08-30 11:52:38 <llnu_> s/was/is/g
2020-08-30 11:52:38 <alpine-meetbot> llnu_ meant to say: because iptables is part of iproute2
2020-08-30 11:52:42 <mps> really? when?
2020-08-30 11:56:12 <llnu_> correction: iptables is just a dependency of iproute2
2020-08-30 11:56:22 <llnu_> i wonder if ip6tables should be a dependency too
2020-08-30 11:57:03 <llnu_> (which would solve a missing dependency for wireguard-tools-wg-quick)
2020-08-30 11:58:20 <mps> why it should depend?  wg works fine without it in my cases, though I install ip6tables for other reasons
2020-08-30 12:00:08 <llnu_> because without it wg-quick up fails for me
2020-08-30 12:00:09 <llnu_> [#] ip6tables-restore -n
2020-08-30 12:00:10 <llnu_> /usr/bin/wg-quick: line 32: ip6tables-restore: command not found
2020-08-30 12:00:14 <llnu_> at this point
2020-08-30 12:00:15 <mps> alpine keep (or should) minimal deps whenever possible
2020-08-30 12:00:26 <llnu_> and installing ip6tables by hand fixes it
2020-08-30 12:00:37 <mps> then this is bug in wg-quick
2020-08-30 12:01:31 <mps> it should check if ip6tables installed before attempting to use it
2020-08-30 12:02:01 <Cogitri> Well, if the command is required it can't do anything other than failing and exiting
2020-08-30 12:02:14 <mps> hmm, Jason is not here anymore
2020-08-30 12:03:54 <mps> huh, looks like now Cogitri lost connection
2020-08-30 12:04:38 <mps> anyway, if wg-quick need it then ip6tables should be added in its 'depend'
2020-08-30 12:05:05 <llnu_> oki! ill open an mr
2020-08-30 12:05:28 <Cogitri> mps: Just restarted my irc bridge for an upgrade
2020-08-30 12:49:35 <llnu_> i still wonder why ip6tables shouldnt be a dependency for iproute2
2020-08-30 12:50:36 <llnu_> it's not v4 exlusive
2020-08-30 12:51:41 <llnu_> or the other way around, why shouldn't wg-quick depend on iptables and ip6tables (instead of iproute2 and ip6tables)
2020-08-30 12:56:33 <Hello71> iptables is a dep because of ip4xt or whatever it is
2020-08-30 12:56:54 <Hello71> ip4tc
2020-08-30 12:57:28 <Hello71> it's unrelated to the /sbin/iptables
2020-08-30 13:14:26 <llnu_> oki! (MR opened: !11876)
2020-08-30 13:17:10 <Hello71> libip4tc.so
2020-08-30 16:46:01 <mps> tmlind: xorg-server on ARMs is fixed
2020-08-30 16:46:27 <ikke> mps: thanks
2020-08-30 16:47:26 <mps> ikke: np, I scratched my itch :)
2020-08-30 16:48:03 <ikke> That's how a lot of things happen ;-)
2020-08-30 16:49:00 <mps> hmm, maybe it is time to try align planet little better ;)
2020-08-30 19:42:56 <obarun> i saw an interesting discussion about supervision on Alpine here; https://lists.alpinelinux.org/~alpine/devel/%3C3LLUI2KOULSYM.359WA6HATX45B%408pit.net%3E.
2020-08-30 19:42:56 <obarun> Ariadne Conill did an explanation of what Alpine expect for a supervisor, bu t i'm not sure to understand correctly this sentence : * Support for consuming systemd units without having to jump through hoops.
2020-08-30 19:42:56 <obarun> What's that mean? Do you expect to convert units file to another format? How can be accomplish without having every single features of systemd on your new supervisor like cgroups, automatic mountpoint creation for mount units, and so on?
2020-08-30 19:42:56 <obarun> But maybe i'm out of the scope of the subject....
2020-08-30 19:43:23 <maxice8> you can ignore those optional features I guess
2020-08-30 19:43:55 <Ariadne> the idea is to support the ini style file format
2020-08-30 19:44:02 <Ariadne> and have the basics work
2020-08-30 19:44:08 <Ariadne> not to support all systemd features
2020-08-30 19:46:45 <obarun> format like this https://framagit.org/pkg/observice/dbus-66serv/-/blob/master/trunk/dbus ?
2020-08-30 19:48:07 <Ariadne> yes, but with the keys used by systemd, not some homemade shit
2020-08-30 19:48:44 <obarun> so you want systemd without systemd, i get it
2020-08-30 19:48:50 <obarun> got*
2020-08-30 19:49:15 <ikke> The idea is to be able to use service files provided by upstream without having to maintain them ourselves
2020-08-30 19:49:22 <Ariadne> ^^
2020-08-30 19:49:56 <insep_> https://github.com/KillingSpark/rustysd i know about this which claims to work with systemd files, don't think it matches with other your points
2020-08-30 19:49:59 <insep_> also
2020-08-30 19:50:02 <insep_> > For the love of god do not use this in anything that is important.
2020-08-30 19:50:28 <maxice8> unfortunately it is written in Rust so it won't be present in some arches
2020-08-30 19:50:50 <insep_> also this^
2020-08-30 19:50:52 <obarun> if you do a converter you absolutely don't care about the final key name as far as the service work well
2020-08-30 19:51:04 <Ariadne> we don't want to do a converter
2020-08-30 19:51:11 <Ariadne> we want to use the unit files natively.
2020-08-30 19:51:39 <obarun> oh, ok that's completely different so
2020-08-30 19:54:05 <Ariadne> also 66 while interesting, the CLI does not really fit the design of other alpine tools
2020-08-30 19:55:10 <obarun> what do you mean?
2020-08-30 19:58:11 <Cogitri> Rust works on everything but s390x and mips right now though. I think at least s390x and mips64 should be possible to add (but I'm not terribly enthusiastic about adding them when next to no one is going to use it anyway)
2020-08-30 20:52:15 <Cogitri> PureTryOut[m]: https://lists.alpinelinux.org/~alpine/devel/%3C902cce83b8dd4155c8664cdf1ebf1ca6abd99c56.camel%40cogitri.dev%3E <- could you do the grep thingie on KDE to make sure the PAM upgrade doesn't break it?
2020-08-30 20:52:28 <Cogitri> mps: You use XFCE, right? Could you please also do that?
2020-08-30 20:57:05 <mps> Cogitri: no, I use awesome WM
2020-08-30 20:58:58 <mps> my daughter use xfce but on stable and I don't want to break her machine
2020-08-30 21:08:14 <detha> Cogitri: I see those lines in /etc/pam.d/system-login yes. lightdm+xfce machine
2020-08-30 21:08:20 <Cogitri> Ah, just the grep for tally and lastlog would do
2020-08-30 21:08:44 <Cogitri> detha: Ah yes, system-login is provided by linux-pam and that is patched in the new version
2020-08-30 21:08:52 <Cogitri> Thanks for checking 👍
2020-08-30 21:10:40 <detha> cool, thanks for not breaking my setup ;)
2020-08-30 21:12:31 <Cogitri> Heh, no worries, breaking pam (and a such login) is no fun
2020-08-30 23:39:25 <andypost[m]> Getting weird error in x86 CI (32-bits) ERROR: py3-terminaltables-3.1.0-r3: BAD signature
2020-08-30 23:39:37 <maxice8> Bad signatures, try bumping pkgrel
2020-08-30 23:39:43 <andypost[m]> https://gitlab.alpinelinux.org/andypost/aports/-/jobs/196565
2020-08-30 23:40:19 <andypost[m]> bump is only way?
2020-08-30 23:40:25 <maxice8> yes
2020-08-31 04:34:54 <tmlind> mps: thanks, xorg-server 1.20.9-r1 works for me now
2020-08-31 06:49:03 <PureTryOut[m]> Cogitri: just on my regular install with KDE? Sure
2020-08-31 07:12:09 <mps> https://linuxplumbersconf.org/event/7/contributions/655/attachments/638/1161/LPC20_SoC_support_in_the_kernel_1.pdf
2020-08-31 07:13:03 <mps> Arnd Bergman mentions Alpine RAM on pages 45-50, less that openwrt :)
2020-08-31 07:32:50 <mps> huh, `lab` tool is screwy
2020-08-31 08:35:32 <ikke> morning
2020-08-31 08:37:58 <Cogitri> Morning 👋
2020-08-31 08:39:54 <Cogitri> dalias/Ariadne: Sooo, can one of you tell me about that libdbus bug that causes freezes? We're currently stuck between a rock and a hard place because FF with dbus freezes all the time and FF without dbus crashes on Wayland :/
2020-08-31 08:40:36 <abenz> PureTryOut[m]: hi, re kdenlive, a comment says to try the appimage, but afaik those don't work on alpine do they? I just checked and it wont run. I also checked the appimage github and it seems alpine support is planned for "type 3" appimages which will have glibc gcompat/etc stuff baked in..
2020-08-31 08:40:46 <ikke> Cogitri: is that the issue of using maloc (or any non-async safe function) after fork, but before exec?
2020-08-31 08:41:09 <PureTryOut[m]> abenz: yeah it's not a valid option. But I guess we could try a Flatpak version instead
2020-08-31 08:41:12 <abenz> comment on the upstream bug report I meant
2020-08-31 08:41:38 <abenz> PureTryOut[m]: I did that actually, and flatpak works
2020-08-31 08:41:52 <PureTryOut[m]> Then again, of course it does
2020-08-31 08:41:58 <PureTryOut[m]> I don't really see how it's relevant tbh
2020-08-31 08:42:07 <Cogitri> ikke: Yes, but no idea where exactly that is happening since we don't have a gitlab issue or smth anywhere
2020-08-31 08:42:29 <Cogitri> And I have a hard time testing it since for some reason I don't get any freezes on any of my machines
2020-08-31 08:42:47 <abenz> PureTryOut[m]: when you originally packaged kdenlive what version was it?
2020-08-31 08:43:02 <abenz> I mean what was the last version that worked on alpine ?
2020-08-31 08:43:12 <abenz> natively*
2020-08-31 08:46:59 <PureTryOut[m]> Originally packaged was 19.04.2, latest working was iirc 19.12.2?
2020-08-31 08:48:03 <abenz> alright
2020-08-31 13:15:32 <ollieparanoid[m]> it seems that since gcc 10 in alpine, the -cc binary (or was it a symlink to -gcc?) is now missing. does anybody know more about the reasoning behind this (upstream gcc change?)
2020-08-31 13:18:00 <ollieparanoid[m]> searching for CC/cc in gcc code base is fun... :p
2020-08-31 13:30:39 <Cogitri> cc seems to exist just fine for me?
2020-08-31 13:34:49 <Hello71> https://pkgs.alpinelinux.org/contents?file=*cc&path=&name=gcc&branch=edge
2020-08-31 13:35:22 <Hello71> I don't think there was ever a $CHOST-cc
2020-08-31 13:35:37 <Hello71> because there's no point
2020-08-31 13:36:53 <Cogitri> Hm, we have `x86_64-alpine-linux-musl-c++` and not `x86_64-alpine-linux-musl-cc` tho
2020-08-31 13:37:35 <Hello71> https://pkgs.alpinelinux.org/contents?file=*-cc&path=&name=&branch=edge
2020-08-31 13:37:57 <Hello71> ccache is generally confused anyways
2020-08-31 14:10:29 <sonder> dalias: I knew that concurrent use of malloc isn't optimal on musl, but it is a bit extreme for my payload. https://git.io/JUqPr Is it worth to dig deeper?
2020-08-31 14:11:17 <ikke> sonder: there is a dedicated #musl channel :)
2020-08-31 14:16:39 <sonder> ikke: yes, I guess I switch to there if this an intersting issue.
2020-08-31 14:17:37 <dalias> i'm not sure if there's anything to be done except either "don't do that" or "use a performance-oriented malloc" but #musl would be the appropriate place to discuss
2020-08-31 14:22:07 <Ariadne> sonder: if you don't care about things like ASLR using a magazine allocator (which splits large malloc chunks into smaller chunks) can improve performance
2020-08-31 19:15:51 <maxice8> @ncopa https://gitlab.alpinelinux.org/alpine/aports/-/issues/11906
2020-08-31 20:21:38 <Hello71> maxice8: seems like your response doesn't actually answer the original question
2020-08-31 20:22:07 <Hello71> namely, the disk usage
2020-08-31 21:20:30 <ikke> But isn't the problem that when you run a python program as non-root, it cannot create the __pycache__ files for system libraries?
2020-08-31 21:39:07 <maxice8> @afontain_: can you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11891 ?
2020-08-31 22:57:53 <Hello71> ikke: yes, and also it starts slower
2020-08-31 22:58:22 <Hello71> I'm not saying there's a solution