2021-10-01 07:23:03 <maxice8> Ikke: you there ? can you remove the distfiles for basu-0.2.0
2021-10-01 07:23:17 <maxice8> the source= url was changed with it the checksum but the archive name remained the same so it fails
2021-10-01 08:18:15 <mps> ncopa: before freeze icu must be upgraded
2021-10-01 08:19:39 <mps> I'm testing upgrade path icu->harfbuzz->firefox
2021-10-01 08:21:29 <ncopa> good morning
2021-10-01 08:21:46 <ncopa> icu is not critical for aports bootstrap
2021-10-01 08:21:50 <mps> good morning
2021-10-01 08:22:19 <ncopa> icu can be upgraded after builders are up and running, even if it is preferred to do it before
2021-10-01 08:22:36 <ncopa> maxice8: which builder?
2021-10-01 08:22:38 <mps> yes, it is, but I don't see any better option than to upgrade it and force maintainers to upgrade/rebuild rest
2021-10-01 08:22:55 <maxice8> ncopa: all of them 
2021-10-01 08:25:49 <ncopa> abuild renamed it to basu-0.2.0.tar.gz.c9ccb1af 
2021-10-01 08:28:18 <Misthios> ncopa did u have time to help with the llvm rebuilds like u said or should i do it sunday?
2021-10-01 08:28:35 <ncopa> i will try have a look on it in a bit
2021-10-01 08:28:41 <Misthios> because im hitting a problem with abuild rootbld: it doesnt find llvm12 while abuild -r does
2021-10-01 08:28:59 <Misthios> but llvm12-static conflicts with 11 static
2021-10-01 08:39:24 <ncopa> what is wget2? why was it added as new package instead of upgrading wget?
2021-10-01 08:40:37 <mps> iirc, it is for new http version
2021-10-01 08:41:23 <mps> nghttp?
2021-10-01 08:44:29 <PureTryOut> wget2 is failing hard on all the builders currently...
2021-10-01 08:50:43 <Misthios> wget is a kind of successor to wget developed along side wget. they made it a seperate program since it is not a drop in for wget ncopa
2021-10-01 08:59:58 <ncopa> ok. makes sense
2021-10-01 09:43:45 <mps> ERROR: wget2*: Has /home/... in rpath
2021-10-01 09:43:54 <mps> that is why it fails
2021-10-01 09:50:52 <ncopa> b0003df8a439d1b6d6485dd15479e1fb98773cd2
2021-10-01 10:55:57 <ddevault> ncopa: can you see about this patch? https://lists.alpinelinux.org/~alpine/devel/patches/3596
2021-10-01 11:13:47 <PureTryOut> ncopa: any particular reason main/icu is 2 major versions behind? Is it safe to upgrade to the latest? I need it for a package
2021-10-01 11:15:56 <mps> PureTryOut: a lot of pkgs needs rebuild
2021-10-01 11:16:37 <mps> I vote for upgrade and 'force' maintainers to rebuild pkgs which depends on icu
2021-10-01 11:17:19 <mps> GL workflow in some cases holds us
2021-10-01 11:18:02 <mps> i.e. all or none in one MR
2021-10-01 11:20:15 <PureTryOut> Hmm
2021-10-01 11:39:34 <Hello71> icu upgrades are painful for every linux distro because they bump soname with each release
2021-10-01 11:59:31 <PureTryOut> Fun
2021-10-01 12:02:28 <ikke> And I prediect we would get a lot of support questions when we upgrade ICU without rebuilding everything
2021-10-01 12:13:55 <mps> good, I'm not only one with crystal ball ;p
2021-10-01 12:14:32 <mps> but I think 'we' should upgrade right now
2021-10-01 12:15:04 <mps> it is on the _edge_
2021-10-01 12:30:32 <PureTryOut> I'm preparing a MR right now
2021-10-01 12:34:02 <Ariadne> +1 for improving full disk encryption support btw
2021-10-01 12:34:14 <Ariadne> i have some
2021-10-01 12:34:22 <Ariadne> machines in not so great places
2021-10-01 12:34:34 <Ariadne> that i would prefer to use FDE with
2021-10-01 12:34:36 <Ariadne> :)
2021-10-01 13:01:08 <ncopa> PureTryOut: reason is noone has spent the needed time to update all the deps
2021-10-01 13:02:14 <Misthios> isnt there a icu mr already from andy?
2021-10-01 13:02:53 <Misthios> !14092
2021-10-01 13:04:55 <kpcyrd> full disk encryption support in the installer would also make me very happy :)
2021-10-01 13:05:05 <Misthios> +1
2021-10-01 13:06:10 <PureTryOut> Misthios: 11 months old!
2021-10-01 13:06:44 <Misthios> 4 weeks ago last activity
2021-10-01 13:06:58 <Misthios> i believe its blocked by some packages in community
2021-10-01 13:07:40 <Misthios> see !24903
2021-10-01 13:09:51 <PureTryOut> Ah good
2021-10-01 13:09:56 <PureTryOut> Thanks for those links
2021-10-01 13:11:52 <Misthios> np
2021-10-01 13:59:10 <Hello71> there are *several* MRs: https://gitlab.alpinelinux.org/search?search=icu&group_id=2&project_id=1&scope=merge_requests&state=opened
2021-10-01 14:05:56 <mps> I think we should split this upgrades by repo
2021-10-01 14:06:02 <mps> not all at once
2021-10-01 14:07:30 <mps> in main only deps are boost, libical, harfbuzz, nodejs and postgresql
2021-10-01 14:07:50 <mps> (why the nodejs is in main)
2021-10-01 14:11:28 <PureTryOut> It is split by repo
2021-10-01 15:13:07 <mps> why they aren't merged
2021-10-01 15:15:19 <mps> ah, I see, just updated
2021-10-01 15:43:29 <ncopa> ddevault: sorry that I have not been able to review that patch. i had a quick look now, and i think it would be nice if it also could support a combination of crypt and lvm and possibly raid. not sure its worth it though
2021-10-01 15:43:41 <ddevault> do we have to do a v9 and wait another 6 months
2021-10-01 15:43:45 <ddevault> I feel like this is pretty good already
2021-10-01 15:43:54 <ddevault> future enhancements for future patches?
2021-10-01 15:44:01 <ncopa> i guess so
2021-10-01 15:45:31 <ncopa> i guess i would have wanted it to be "layered" similar to mdadm + lvm, which supports both data and sys over mdadm and/or lvm
2021-10-01 15:45:47 <ncopa> but i haven't looked close enough at the code if it is possible do that in a nice way
2021-10-01 15:47:14 <ddevault> I lack much expertise on lvm
2021-10-01 15:47:28 <ncopa> Misthios: sorry but I have not been able to look at llvm (or alpine) today at all. got caught up in other stuff
2021-10-01 15:48:08 <ncopa> ddevault: understand
2021-10-01 15:48:42 <ncopa> and I lack expertise on cryptsetup
2021-10-01 15:49:10 <ddevault> cryptsetup < plaintext block device > encrypted block device
2021-10-01 15:49:46 <ncopa> i do have superficial knowledge about it
2021-10-01 15:50:04 <ddevault> I mean, it's not much more than that
2021-10-01 15:50:21 <ddevault> cryptsetup luksFormat /dev/some/block/device
2021-10-01 15:50:27 <ddevault> cryptsetup open /dev/some/block/device cryptdev
2021-10-01 15:50:44 <ddevault> /dev/mapper/cryptdev now exists and acts like a block device which transparently encrypts and persists on the underlying device
2021-10-01 15:50:57 <ncopa> lvm can use any block device, mdadm real disk or cryptdev
2021-10-01 15:51:15 <ncopa> lvm does not care much about the underlying device
2021-10-01 15:52:25 <ddevault> question is
2021-10-01 15:52:36 <ddevault> lvm(luks(ext4)) or luks(lvm(ext4))
2021-10-01 15:52:56 <ddevault> none of this discussion is leading to me updating the patch btw, I haven't got the time to learn enough to make a good cryptsetup+llvm patch
2021-10-01 15:52:58 <ddevault> lvm*
2021-10-01 15:53:22 <ncopa> we do mdam(lvm(ext4)) and dont support lvm(mdadm(ext4))
2021-10-01 15:54:10 <ncopa> and i havent got the time to test your patch either
2021-10-01 15:54:23 <ncopa> i guess i would need a half day or a full day to look at it
2021-10-01 15:55:06 <Misthios> ncopa no problem
2021-10-01 15:55:12 <adhawkins> Spotted an issue with my latest package for borg-space. If someone could look at !26021, that fixes it.
2021-10-01 15:55:16 <ddevault> fwiw I used the patch to set up a machine today, and earlier revisions have also worked, and 9 or 10 people have manually applied the patch when doing their own installs
2021-10-01 15:55:26 <ddevault> it works
2021-10-01 15:55:33 <adhawkins> Sorry, !26027
2021-10-01 15:56:20 <ncopa> question is if I should accept it and support it as is or look closer at it and make sure its done "properly"
2021-10-01 15:56:47 <ddevault> fair enough
2021-10-01 15:56:48 <ncopa> because I suppose I will end up dealing with bugs if there are any
2021-10-01 15:57:15 <ddevault> it is a feature quite sorely missed, and many people would appreciate it if you found the time to look at it in the foreseeable future
2021-10-01 15:57:17 <ncopa> but that said, it does look ok-ish.
2021-10-01 15:57:25 <ddevault> but aye, in your own time
2021-10-01 16:04:13 <minimal> ddevault: fs on LVM on LUKS makes more sense than LUKS on LVM
2021-10-01 16:05:07 <minimal> ddevault: I've scripted LVM disk setup and scripted LUKS disk setup, just haven't yet joined the dots and scripted LVM-on-LUKS yet
2021-10-01 16:09:47 <omni> 
ACTION run ZFS on LUKS

2021-10-01 16:26:32 <Hello71> crypt_required looks suspicious. it won't work with busybox blkid, and i don't think blkid makes any guarantees about the particular return value, only that it can be used to access the device
2021-10-01 16:35:08 <minimal> Hello71: busybox blkid could be used with piping to "grep" (or similar) to extract the required stuff out but then it gets a bit messy
2021-10-01 16:39:56 <Hello71> the right implementation looks like devname=$(findfs "$devname") || return; cryptsetup status "$devname"
2021-10-01 16:41:10 <ncopa> ugh... email is broken
2021-10-01 16:41:22 <ncopa> i spent time on writing a response to the setup-disk patch
2021-10-01 16:41:41 <ncopa> and this is what i get in return: [2021-10-01 18:40:03] SMTP< 553 5.7.1 <ncopa@alpinelinux.org>: Sender address rejected: not owned by user alpine@tanael.org
2021-10-01 16:41:56 <ncopa> i kinda understand why github has become so popular
2021-10-01 16:43:19 <dalias> >_<
2021-10-01 16:43:34 <ncopa> apparently i can no longer send emails
2021-10-01 16:43:46 <dalias> which server gave you that error?
2021-10-01 16:43:54 <dalias> and what mail sw are you using?
2021-10-01 16:44:00 <ncopa> some selfhosted mail server
2021-10-01 16:44:04 <ncopa> postfix
2021-10-01 16:44:06 <ncopa> i guess
2021-10-01 16:44:21 <dalias> but did postfix reject it, or recipient's server reject it?
2021-10-01 16:44:42 <ncopa> ddevault: sorry but the review didnt make it
2021-10-01 16:44:57 <ncopa> dalias: i think it was postfix
2021-10-01 16:45:09 <dalias> it might just be a config error on your side then
2021-10-01 16:45:16 <ncopa> yeah. i think it is
2021-10-01 16:45:25 <ikke> https://serverfault.com/questions/870888/sender-address-rejected-not-owned-by-user
2021-10-01 16:45:27 <dalias> if you need to send in a hurry you could try my mxclient :)
2021-10-01 16:45:47 <ncopa> i was supposed to have weekend an hour ago
2021-10-01 16:45:56 <ncopa> oh well
2021-10-01 16:45:59 <ikke> :/
2021-10-01 16:46:02 <ncopa> have a nice weekend everyone
2021-10-01 16:46:04 <dalias> mxclient -f your_address rcpt_address < message_file_with_headers
2021-10-01 16:46:26 <mps> dalias: is it ready for packaging?
2021-10-01 16:46:33 <ikke> dalias: does that directly deliver it to the recievers mail server?
2021-10-01 16:46:35 <dalias> mps, i think it's ok to package
2021-10-01 16:46:38 <Hello71> dalias: if you want it to be rejected by the recipient instead...
2021-10-01 16:46:40 <dalias> ikke, yep that's the whole point :)
2021-10-01 16:46:55 <mps> good, I wanted to add it to alpine some time ago
2021-10-01 16:47:06 <mps> what is current url
2021-10-01 16:47:20 <dalias> https://github.com/richfelker/mxclient/
2021-10-01 16:47:26 <mps> thanks
2021-10-01 16:47:58 <ddevault> ncopa: bah
2021-10-01 16:48:05 <ddevault> ncopa: well, thanks for taking another look
2021-10-01 16:48:19 <dalias> it does need bearssl; do you have[4~ that packaged?
2021-10-01 16:48:32 <dalias> looks like yes :)
2021-10-01 16:48:48 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/bearssl
2021-10-01 16:48:59 <ncopa> ddevault: in case you can help me forward it: https://tpaste.us/6W1W
2021-10-01 16:49:24 <mps> ikke: yes, we have bearssl
2021-10-01 16:49:29 <ncopa> now im gonna throw the computer out the window and move to the forest. have a nice weekend!
2021-10-01 16:49:36 <ddevault> are you having mail issues?
2021-10-01 16:49:56 <ikke> ddevault: postfix is rejecting his mail
2021-10-01 16:50:01 <ddevault> I see
2021-10-01 16:50:15 <mps> ncopa: enjoy and care of the bear(s) :)
2021-10-01 16:50:43 <dalias> the bears(sl) :)
2021-10-01 16:50:56 <mps> dalias: I meant this ;)
2021-10-01 16:51:24 <dalias> we could get ncopa an "I <3 BEARS" shirt ;-)
2021-10-01 16:51:56 <ddevault> this patchset is two and a half years old and it's going back for it's ninth revision
2021-10-01 16:52:02 <ddevault> the very last thing I want to see is the scope expanded to lvm
2021-10-01 16:52:18 <ddevault> please, please, postpone that to future enhancements
2021-10-01 16:52:23 <mps> dalias: there are more candidates for such shirts ;)
2021-10-01 16:53:17 <dalias> just make sure they're  not fancy ones :)
2021-10-01 16:56:25 <mps> could be because I'm oldtimer but I still prefer mail over anything else
2021-10-01 16:56:33 <dalias> *nod*
2021-10-01 16:58:31 <dalias> i prefer mail in that (1) it's something I actually possess and can refer back to without having to trust that someone else will preserve availability and integrity, and (2) i can access it in the ways that work for me rather than being stuck with somebody else's ui whims that are constantly changing
2021-10-01 16:59:03 <dalias> these are things we should aim to be able to deliver to folks who have other good reasons not to like mail, tho
2021-10-01 16:59:14 <PJ[m]> right, but mails are such fragile thing
2021-10-01 16:59:18 <Newbyte> Can I disable tests only for a specific arch? 
2021-10-01 16:59:29 <dalias> pj[m], frag[4~ile?
2021-10-01 16:59:42 <ddevault> if [ $CARCH = aarch64 ]; then options="!check"; fi
2021-10-01 16:59:53 <Newbyte> thanks!
2021-10-01 17:00:05 <Newbyte> but believe it or not, the test succeeds on aarch64, but not x86_64
2021-10-01 17:00:07 <mps> dalias: right these reasons
2021-10-01 17:00:31 <dalias> btw i should add the proxy option to mxclient
2021-10-01 17:00:34 <ikke> But it only 'works' for the people that have the know-how
2021-10-01 17:00:41 <dalias> right
2021-10-01 17:00:58 <mps> ikke: people should learn
2021-10-01 17:01:08 <dalias> it's a fairly simple posix_spawn of ssh -W
2021-10-01 17:01:13 <mps> it is not 'rocket science'
2021-10-01 17:01:23 <PJ[m]> fragile, because hosting own mailserver is pain and good luck if your mail just disappears somewhere in the web
2021-10-01 17:01:33 <ikke> mps: people don't want to maintain a mail server
2021-10-01 17:01:50 <mps> well, that is not excuse imo
2021-10-01 17:01:58 <ikke> nowdays, people barely want e-mail
2021-10-01 17:01:58 <PJ[m]> that is excuse
2021-10-01 17:01:59 <ddevault> there are many companies who will maintain a mail server for you
2021-10-01 17:02:03 <PJ[m]> it's a pretty valid one
2021-10-01 17:02:16 <ddevault> I usually recommend migadu.com
2021-10-01 17:02:43 <mps> installing and setting local mail server takes about hour or two
2021-10-01 17:03:07 <ikke> mps: and then your e-mails are rejected / marked as spam
2021-10-01 17:03:33 <ikke> If you configure it improperly, you become an open relay
2021-10-01 17:03:44 <mps> that happens, true, but that happens with big co servers also
2021-10-01 17:04:33 <PJ[m]> I recommend setting up local mailserver for learning experience but not for running it seriously
2021-10-01 17:04:45 <mps> ikke: do you work for some big co mail server provider ;P
2021-10-01 17:04:49 <ikke> No
2021-10-01 17:04:52 <ddevault> I don't recommend local mail servers except in certain situations
2021-10-01 17:04:55 <ikke> It's just the reality
2021-10-01 17:04:59 <dalias> ikke, that's one of the advantages of mxclient: you can't become an open relay because there's no accepting channel at all :)
2021-10-01 17:05:05 <ddevault> I run one, but it relays through a dedicated provider
2021-10-01 17:05:15 <ikke> dalias: how is it with deliverability?
2021-10-01 17:05:43 <PJ[m]> I presume it's up to destination MX to hold it
2021-10-01 17:06:05 <dalias> ikke, it depends on if your ip is in the nastylists
2021-10-01 17:06:10 <mps> I run home mail server for more than 25 years and didn't had any serious problem (except some spam in mailbox)
2021-10-01 17:06:11 <dalias> that's why i need to add the proxy feature
2021-10-01 17:06:29 <ikke> mps: for the record, I run my own mail servers as well
2021-10-01 17:06:39 <ddevault> I have also run mail servers which have had no deliverability issues for several years
2021-10-01 17:06:50 <dalias> after looking up mx, ssh -W to it and communicate over socketpair to that
2021-10-01 17:07:01 <ddevault> arch linux issues, however, were an issue :(
2021-10-01 17:07:15 <dalias> then the mail comes out from the ip you ssh -W thru
2021-10-01 17:07:17 <ikke> ddevault: hmm, I'm running it on arch for years, no issues
2021-10-01 17:07:27 <dalias> but the TLS is still terminated on your side
2021-10-01 17:07:34 <dalias> so the host you ssh -W thru sees nothing
2021-10-01 17:07:43 <Hello71> dalias: you can't receive any mail though
2021-10-01 17:07:44 <ddevault> it took me years to completely eliminate arch from my fleet
2021-10-01 17:07:47 <ddevault> and I still have one arch server
2021-10-01 17:07:52 <ddevault> and naturally it is the most problematic one
2021-10-01 17:08:11 <dalias> hello71, you need separate software for receiving, and it's intentionally built with no ability to send :)
2021-10-01 17:08:16 <Hello71> i mean that's selection bias
2021-10-01 17:11:27 <donoban> uhm, I run a mail server years ago for a radio podcast (which was using gmail) and it was a pain to get the emails from it not marked as spam in gmail
2021-10-01 17:12:55 <mps> for me having all 'important' mails on local storage and not depend on some service with their decisions and policy is very important. I have mails from 1991 year
2021-10-01 17:13:26 <mps> 1992*
2021-10-01 17:13:41 <PJ[m]> You know that almost any service allows you to connect via SMTP/IMAP etc.
2021-10-01 17:13:48 <donoban> well but you don't need to run a mail server for having a copy of all your inbox
2021-10-01 17:14:03 <PJ[m]> That doesn't prevent from keeping local copies
2021-10-01 17:14:47 <mps> yes, but sorting by inboxes and taking care of all this is the job of my mail server and not my
2021-10-01 18:19:46 <andypost[m]> Does it make sense to add new boost to main before starting 3.15 builders? see !25709
2021-10-01 19:29:47 <Ariadne> yes i think so
2021-10-01 19:29:56 <Ariadne> we should version boost like that anyway
2021-10-01 19:32:45 <ikke> Can they be installed side-by-side?
2021-10-01 19:34:13 <Ariadne> the runtime libs can
2021-10-01 19:34:17 <Ariadne> the headers can’t
2021-10-01 19:34:22 <Ariadne> same situation as openssl
2021-10-01 19:34:36 <dalias> yes, libraries with incompatible versions should have the version as part of the package name
2021-10-01 19:34:48 <dalias> so that upgrading doesn't break everything you compiled from source
2021-10-01 19:34:53 <Ariadne> :)
2021-10-01 19:35:04 <dalias> and leave you unable to compile it again because some of the other dependency packages were unmaintained and removed
2021-10-01 19:35:08 <JuniorJPDJ> anyone was working with jemalloc?
2021-10-01 19:35:12 <dalias> (yes this really happens to me. frequently.)
2021-10-01 19:35:15 <JuniorJPDJ> telegram-desktop seems to depend on it now...
2021-10-01 19:35:29 <Ariadne> why
2021-10-01 19:35:32 <Ariadne> just why
2021-10-01 19:36:09 <Ariadne> i wish people would stop just cramming jemalloc into musl packages because malloc-ng is “slow”
2021-10-01 19:36:50 <dalias> is it actually related to musl? I doubt that
2021-10-01 19:36:56 <Ariadne> malloc-ng is new and will likely see performance improvements over time
2021-10-01 19:37:00 <Ariadne> yes people do it
2021-10-01 19:37:14 <Ariadne> i read about it a lot on certain orange tinted websites
2021-10-01 19:37:35 <JuniorJPDJ> i mean upstream of telegram-desktop
2021-10-01 19:37:50 <JuniorJPDJ> I'm working on providing updated version of tdesktop to alpine
2021-10-01 19:37:52 <Ariadne> yes they’re doing it because it’s meme
2021-10-01 19:38:13 <JuniorJPDJ> and I'm not sure what should I do
2021-10-01 19:38:14 <dalias> the build process is doing "if musl, force jemalloc" ?
2021-10-01 19:38:32 <dalias> or what?
2021-10-01 19:38:40 <Ariadne> in case of telegram no idea
2021-10-01 19:38:40 <JuniorJPDJ> it's just doing "if linux, link with jemalloc, if jemalloc missing in os, compile it inside"
2021-10-01 19:38:58 <dalias> doing this for some electron shit sounds like an awful idea
2021-10-01 19:39:04 <JuniorJPDJ> but internal jemalloc build fails
2021-10-01 19:39:05 <dalias> because it's absolutely full of DF and UAF bugs
2021-10-01 19:39:11 <dalias> just disable it
2021-10-01 19:39:18 <JuniorJPDJ> telegram is not electron app
2021-10-01 19:39:21 <Ariadne> telegram desktop is not electron
2021-10-01 19:39:23 <dalias> oh
2021-10-01 19:39:24 <JuniorJPDJ> its native qt app
2021-10-01 19:39:51 <JuniorJPDJ> its like the only modern IM not running in browser
2021-10-01 19:39:51 <minimal> Ariadne: there is also mimalloc2 that was packaged a couple of months ago that is "supposed" to compete with other alloc libs like jemalloc
2021-10-01 19:39:59 <dalias> still i think it's a good candidate for wanting a harder malloc not a faster one
2021-10-01 19:40:10 <dalias> mimalloc is nothing exciting
2021-10-01 19:40:30 <JuniorJPDJ> so you guys think I should patch it to remove jemalloc dependency?
2021-10-01 19:40:34 <dalias> yes
2021-10-01 19:40:34 <Ariadne> yes
2021-10-01 19:40:44 <JuniorJPDJ> cool
2021-10-01 19:40:48 <Ariadne> malloc-ng is good enough in most workloads
2021-10-01 19:40:53 <dalias> imo this should be alpine policy
2021-10-01 19:40:57 <dalias> it's a hardened distro
2021-10-01 19:41:10 <dalias> packages that intentionally subvert the hardening of the OS should be patched not to
2021-10-01 19:41:18 <Ariadne> agree
2021-10-01 19:41:35 <Ariadne> though i wonder about improving malloc performance
2021-10-01 19:41:46 <dalias> it will also drop the memory pressure by like 50-75% i bet :-p
2021-10-01 19:41:52 <dalias> because jemalloc is a HUGE hog
2021-10-01 19:42:01 <dalias> and swapping from memory pressure is the main way desktop apps are slow
2021-10-01 19:42:12 <Ariadne> transcoding is noticeable slower on alpine vs debian containers due to malloc overhead
2021-10-01 19:42:19 <dalias> transcoding = ?
2021-10-01 19:42:25 <Ariadne> ffmpeg
2021-10-01 19:42:34 <dalias> oh weird. i didn't think ffmpeg was malloc-intense at all
2021-10-01 19:42:48 <dalias> are you sure it's that and not stack-protector, PIE, etc.?
2021-10-01 19:43:10 <Ariadne> yeah there’s a lot of syscalls overhead with brk(2)
2021-10-01 19:43:19 <Ariadne> that isn’t there on glibc
2021-10-01 19:43:34 <Ariadne> i guess glibc just uses mmap after a while
2021-10-01 19:43:49 <Ariadne> have not done enough of a dive yet
2021-10-01 19:46:05 <JuniorJPDJ> it there an easy way of testing if package compiles on other arches than my native?
2021-10-01 19:46:12 <JuniorJPDJ> other than making pull request ofc
2021-10-01 19:46:28 <JuniorJPDJ> does abuild support some qemu TCM emulation or something?
2021-10-01 19:47:36 <Ariadne> CBUILD=whatever abuild rootbld
2021-10-01 19:49:33 <dalias> i see something like 0.2% cpu in malloc related stuff
2021-10-01 19:49:38 <dalias> with perf top running ffmpeg
2021-10-01 19:49:42 <dalias> so i dont think it's malloc
2021-10-01 19:50:18 <Ariadne> i’ll have to check my notes, it was with a multithreaded codec
2021-10-01 19:50:48 <dalias> this was with x264 encoding and there's some pthread mutex lock/unlock going on
2021-10-01 19:50:54 <dalias> with tiny % too but more than malloc
2021-10-01 20:02:16 <Newbyte> what can you do if a program wants catchsegv? it seems to come from glibc
2021-10-01 20:03:55 <dalias> if it's just trying to print backtraces on crash or upload them to some phone-home service, just patch that out
2021-10-01 20:06:01 <ericonr> it doesn't come from glibc
2021-10-01 20:06:07 <ericonr> that smells like gnulib bullshit
2021-10-01 20:08:08 <Hello71> no, it's glibc
2021-10-01 20:08:35 <Hello71> it's actually not a bad idea except it's implemented with LD_PRELOAD instead of ptrace
2021-10-01 20:08:39 <Newbyte> https://paste.centos.org/view/3d2642b4
2021-10-01 20:09:06 <ericonr> oh wait I thought it was a function
2021-10-01 20:09:13 <ericonr> not the absurd executable
2021-10-01 20:10:14 <ericonr> what does it want catchsegv for, then? it should never run things under catchsegv on a user machine
2021-10-01 20:11:11 <Newbyte> seems it's tests: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/meson.build#L314
2021-10-01 20:12:13 <ericonr> it should have an option to not use catchsegv :/ otherwise this is a glibc only test
2021-10-01 20:12:37 <mps> now I sorry why I didn't removed jemalloc on time
2021-10-01 20:12:49 <dalias> ?
2021-10-01 20:13:04 <mps> from alpine aports
2021-10-01 20:13:18 <dalias> heh
2021-10-01 20:13:34 <dalias> i dont think it hurts to have it there, but stuff shouldn't be gratuitously built against it
2021-10-01 20:13:39 <mps> remembering time when nothing depend on it and I removed it from firefox
2021-10-01 23:46:27 <smcavoy> anyone using lxd in testing? I have noticed that the openrc setup does not seem to stop systemd based containers. I was going to submit an update to include `lxd shutdown` as the openrc stop function.  any thoughts?
2021-10-02 00:24:19 <Ariadne> seems reasonable
2021-10-02 04:16:23 <handlerug> how can I enable network (/etc/resolv.conf) when using `abuild rootbld`? there's a check for net option but I don't know how to set it
2021-10-02 04:29:20 <handlerug> nvm, found it
2021-10-02 09:19:07 <maxice8> shouldn't scribus follow the stable branch (1.4.x) instead of development candidates (1.5.x) ?
2021-10-02 09:20:13 <ikke> mps: ^
2021-10-02 09:20:55 <mps> maxice8: stable doesn't build on alpine iirc
2021-10-02 09:21:02 <maxice8> fair
2021-10-02 09:22:01 <mps> I'll have to look at my mail archive to be sure
2021-10-02 09:22:52 <ikke> Seems like ranger on edge needs screen as a dependency
2021-10-02 09:23:58 <mps> I made scribus aport because one men asked me when he had to go to hospital, and after that he didn't contacted me. I would hand out maintainership anyone with will and knowledge to maintain it
2021-10-02 09:28:13 <maxice8> ikke: GNU screen ?
2021-10-02 09:28:31 <ikke> ah, it becomes I have 'screen-256color' in my TERM
2021-10-02 09:28:36 <ikke> it's because*
2021-10-02 09:28:54 <mps> hmm, wg-quick is bash script
2021-10-02 09:29:20 <maxice8> and the screen binary too
2021-10-02 09:29:37 <ikke> ?
2021-10-02 09:29:52 <maxice8> https://github.com/ranger/ranger/blob/50f8971a6eccb43442bb53186fa83212d0763c01/ranger/ext/img_display.py#L315 ?
2021-10-02 09:31:26 <ikke> https://github.com/ranger/ranger/blob/50f8971a6eccb43442bb53186fa83212d0763c01/ranger/gui/ui.py#L58
2021-10-02 09:31:39 <ikke> https://github.com/ranger/ranger/blob/50f8971a6eccb43442bb53186fa83212d0763c01/ranger/gui/ui.py#L505
2021-10-02 09:32:07 <ikke> It assumes that if the TERM is screen*, you must have screen available
2021-10-02 09:36:28 <ikke> https://github.com/ranger/ranger/issues/2272
2021-10-02 10:00:14 <donoban> could someone take a look on !25850?
2021-10-02 10:01:05 <ikke> donoban: I suppose you want to bump pkgrel?
2021-10-02 10:01:44 <donoban> ouch
2021-10-02 10:01:53 <donoban> 1 sec
2021-10-02 10:02:21 <mps> aren't DMs have autologin features
2021-10-02 10:03:31 <ktprograms> Hi, can someone please take a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29 ? Thanks!
2021-10-02 10:03:33 <donoban> what do you mean mps ?
2021-10-02 10:04:19 <mps> donoban: what is use case for autologin pkg
2021-10-02 10:05:36 <donoban> good question hehe
2021-10-02 10:06:22 <mps> in my case autologin on console works with agetty and on X with slim DM
2021-10-02 10:06:36 <donoban> I use it as depedency for tinydm, autologin just logs and runs some command without interaction
2021-10-02 10:06:47 <donoban> it can be plenty of different use cases
2021-10-02 10:07:04 <mps> .xinitrc also runs whatever you like
2021-10-02 10:08:05 <donoban> yep there are probably many ways of achieving the same, difficult to know what it's the best
2021-10-02 10:08:34 <mps> simple and small things are best ;)
2021-10-02 10:08:46 <donoban> I probably could just start sway from autologin
2021-10-02 10:09:09 <donoban> I'm not sure if there are some benefit of using tinydm
2021-10-02 10:09:16 <mps> I could even from console :p
2021-10-02 10:09:49 <donoban> well the idea is to get a graphich desktop after unlocking the hard driver, without any interaction
2021-10-02 10:10:01 <donoban> hard drive*
2021-10-02 10:11:13 <donoban> ikke: bumped :)
2021-10-02 10:26:57 <mps> I found this patch to convert wg-quick to use ash https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg06547.html
2021-10-02 10:27:35 <mps> it is big, but maybe we can use it instead of bash for wg-quick
2021-10-02 11:07:16 <ikke> donoban: abuild checksum ;-)
2021-10-02 11:07:35 <donoban> ouch
2021-10-02 11:08:50 <donoban> it's rare, it was fine on previous push
2021-10-02 11:09:24 <ikke> because you didn't change the APKBUILD, it didn't build the package
2021-10-02 11:10:23 <donoban> ah ok
2021-10-02 11:24:42 <ddevault> how would we feel about removing the non-free packages from aports
2021-10-02 11:30:20 <eris[m]> whats the point of doing that?
2021-10-02 11:30:26 <maxice8> personally indifferent
2021-10-02 11:30:46 <ddevault> dead code
2021-10-02 11:30:48 <ddevault> not useful
2021-10-02 11:30:50 <ddevault> non-free
2021-10-02 11:31:03 <eris[m]> how is not free software.. not useful? 
2021-10-02 11:31:12 <ddevault> not useful as in I don't think anyone really uses these packages
2021-10-02 11:31:26 <ddevault> and if they do, they're responsible for maintaining them on their own anyway
2021-10-02 11:31:35 <eris[m]> have you considered asking the maintainers of those packages specifically? 
2021-10-02 11:31:52 <eris[m]> i dont get why non-free means you should remove them, either ;) 
2021-10-02 11:31:54 <ddevault> well, I would like to remove them as a matter of global alpine policy
2021-10-02 11:32:02 <ddevault> because alpine is a free software linux distribution
2021-10-02 11:33:46 <eris[m]> where does it say that? 
2021-10-02 11:33:47 <ddevault> at least the unmaintained directory has a possibility of someone picking them back up later, but non-free software will never be eligible for inclusion in main/community/testing
2021-10-02 11:34:06 <eris[m]> plus, doesn't alpine use linux?
2021-10-02 11:34:09 <ddevault> it's a fact that alpine only includes free software in its repositories
2021-10-02 11:34:12 <ddevault> oh for fuck's sake
2021-10-02 11:34:12 <eris[m]> not libre
2021-10-02 11:34:21 <ddevault> free != libre
2021-10-02 11:34:32 <eris[m]> confusing 
2021-10-02 11:34:38 <ddevault> er, free == libre
2021-10-02 11:34:41 <ddevault> but free != copyleft
2021-10-02 11:35:02 <ddevault> free software does not mean the GPL, though the GPL is one of many free software licenses (MIT, BSD, and Apache 2.0 are also free software licenses)
2021-10-02 11:35:55 <ddevault> anyway, I think the imposition should be on the non-free software to justify its continued inclusion
2021-10-02 11:36:12 <ddevault> if it'll never end up in the repos, why bother keeping it around in aports
2021-10-02 11:36:26 <ddevault> if someone really wants to maintain a non-free tree for alpine, more power to them, but it should be done separately from alpine upstream
2021-10-02 11:37:48 <maxice8> a separate repo aports-nonfree ?
2021-10-02 11:38:09 <ddevault> aye, maintained independently of alpine
2021-10-02 11:38:48 <ddevault> a possible compromise would be to put packages in there on a fixed lifetime, so that they get removed after e.g. one alpine release, and only allow packages to be added to it if they're being moved from main/community because upstream went non-free, to give users a grace period for migration to an alternative package
2021-10-02 11:39:19 <ddevault> or to establish independent maintenance of the package, if they so wish
2021-10-02 12:16:18 <z3ntu> Hey, I'm trying to update shiboken6 in aports but getting this error `scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in /home/builder/aports/community/shiboken6/pkg/py3-shiboken6/usr/lib/python3.9/site-packages/shiboken6/Shiboken.cpython-39-x86_64-linux-musl.so` . Shiboken6 gets built with a mix of cmake and probably some python setuptools
2021-10-02 13:03:30 <nmeum> ddevault: you could suggest that to the TSC
2021-10-02 13:04:52 <nmeum> an interesting question is also what classifies a software as non-free, e.g. there are a few packages in main/ and community/ which have licenses which are neither approved by FSF nor OSI (like main/unzip for example)
2021-10-02 13:14:14 <Hello71> arguably unzip could be removed on the basis that nobody is keeping up with needed patches, e.g. #11986, and busybox and libarchive cover the functionality
2021-10-02 13:18:52 <ikke> there are some ~20 packages that explicitly depend on unzip
2021-10-02 13:25:07 <skarnet> naughty ones
2021-10-02 13:47:03 <dalias> how is "large" relevant? this sounds like it's gonna be dumb..
2021-10-02 13:47:50 <dalias> wait why is llvm distributing a zip rather than a tarball !?
2021-10-02 13:47:53 <dalias> ...
2021-10-02 13:48:13 <dalias> and why does bsdtar supposedly processs zip files? :/
2021-10-02 13:48:18 <dalias> there are so so many layers of WHY here
2021-10-02 13:49:06 <mps> dalias: fyi I prepared mxclient !26060
2021-10-02 13:51:32 <ikke> dalias: from the thread: "It is.  This only happens if you have more then 16k entries and when one of the 16k entry infos is reused it happend to be previously used for a symlink entry."
2021-10-02 13:56:21 <Sheila> why *wouldn't* bsdtar support zip? gzip is a DEFLATE implementation too, iirc.
2021-10-02 13:58:54 <Hello71> bsdtar supports all sorts of stuff. pax, cpio, shar, iso, rar4 and rar5, 7-zip, cab...
2021-10-02 13:59:44 <ikke> mps: huh, do you explicitly need to create $pkgdir/usr/bin?
2021-10-02 14:00:33 <Hello71> pacman doesn't bother invoking unzip, it just calls bsdtar for everything
2021-10-02 14:03:32 <dalias> sheila, because zip isn't tar
2021-10-02 14:04:03 <dalias> and supporting all sorts of random formats is giant attack surface
2021-10-02 14:04:41 <Sheila> I feel like most of the formats Hello71 mentioned is a much better example for that argument than zip.
2021-10-02 14:04:47 <dalias> if tar errors out "this isn't a tar" for "foo.tar" then i see something is sus and decide whether i want to feed it to another program
2021-10-02 14:04:53 <Sheila> are much better examples*
2021-10-02 14:05:04 <dalias> if tar just silently accepts non-tar files..
2021-10-02 14:05:17 <Hello71> gnu tar already auto-detects a large number of compression formats
2021-10-02 14:05:18 <dalias> then there's no sign anything was off
2021-10-02 14:05:30 <dalias> yes, compression formats are a lot less sketchy tho
2021-10-02 14:06:06 <Sheila> again, gzip and zip are pretty similar, so if you support the one it makes sense to support the other.
2021-10-02 14:06:19 <dalias> sheila, no, they're not
2021-10-02 14:06:34 <dalias> zip *uses similar compression* but is a completely different type of archive format from tar
2021-10-02 14:06:48 <Sheila> but i didn't compare it to tar, I compared it to gzip.
2021-10-02 14:07:04 <dalias> gzip isn't an archive format at all so ...
2021-10-02 14:07:38 <Sheila> yes, actually, it is…the common implementations of it don't support multi-file archives, but the specification *does*.
2021-10-02 14:07:39 <dalias> most versions of tar support various compressed stream formats the tar can be inside
2021-10-02 14:08:33 <dalias> that's completely unrelated to supporting other types of archive formats that use the same kind of compression inside them
2021-10-02 14:09:56 <mps> ikke: I found this as simplest solution
2021-10-02 14:10:27 <ikke> solution for what?
2021-10-02 14:10:54 <mps> hardcoded path in Makefile to /usr/local/bin
2021-10-02 14:11:41 <ikke> and setting bindir does not create that dir?
2021-10-02 14:11:41 <mps> no, sorry
2021-10-02 14:12:12 <mps> it doesn't
2021-10-02 14:13:58 <Sheila> 
ACTION looks up. "Patch + PR with upstream?"

2021-10-02 14:59:41 <nmeum> Hello71: unzip is just one example, there are others as well
2021-10-02 16:57:16 <proycon> fyi, alpine edge has issues with inconsistent boost versions currently: https://download.anaproy.nl/mess.txt
2021-10-02 16:57:25 <proycon> (unable to upgrade)
2021-10-02 16:58:16 <proycon> yesterday evening everything was fine still
2021-10-02 17:00:26 <skarnet> you had the opportunity to say "yesterday, all my trouble seemed so far away" and you didn't take it
2021-10-02 17:53:33 <maxice8> people forgot to rebuild boost1.76 without the provides= and replaces= that claim the unversioned names for boost and boost-libs, boost-dev, etc
2021-10-02 17:54:59 <maxice8> Example: 2c9b99ce67e45b0de834fe06ea1eb72402291e1b
2021-10-02 17:56:34 <mps> and people don't have names ;)
2021-10-02 18:10:50 <andypost[m]> I'm sorry about it)
2021-10-02 18:11:42 <mps> andypost[m]: we all make mistakes, so np
2021-10-02 18:11:54 <andypost[m]> btw I bet few apps could be rebuild with 1.77
2021-10-02 18:11:57 <mps> that is nature of development
2021-10-02 18:12:28 <mps> so we can't be perfect
2021-10-02 18:12:51 <andypost[m]> btw I recall I checked that all libs has different sonames, but missed to check core(
2021-10-02 18:13:01 <mps> good thing is that we can fix mistakes
2021-10-02 18:16:31 <andypost[m]> btw main/boost needs higher priority?
2021-10-02 18:16:39 <andypost[m]> s/boost/boost1.76/
2021-10-02 18:20:40 <Ariadne> ddevault: people use the nonfree apkbuilds, understanding they need to be built locally.  it could be removed from aports but a replacement would need to be provided.
2021-10-02 18:21:18 <Ariadne> that replacement does not necessarily need to be an official alpine project though
2021-10-02 18:25:30 <Ariadne> (in fact it would likely be best for everyone that it not be really)
2021-10-02 18:31:38 <andypost[m]> mps: looking for review !26072
2021-10-02 18:31:38 <Ariadne> ddevault: i opened a tsc issue for it, i think we should do it.  i will try to make the case to do it for 3.15 at the next TSC meeting.
2021-10-02 18:32:04 <Ariadne> huh?  why would boost need provider_priority
2021-10-02 18:32:19 <Ariadne> oh, i see
2021-10-02 18:32:56 <Ariadne> why not just have provider_priority=176, and then when boost 1.77 enters main, have that one be provider_priority=177
2021-10-02 18:33:14 <Ariadne> alternatively, we can just do provides="boost=${pkgver}"
2021-10-02 18:33:20 <Ariadne> and not fuss with provider_priority at all
2021-10-02 18:45:55 <andypost[m]> but if get priorities correctly 1.77 will take over 1.76 which is not BC
2021-10-02 18:46:08 <mps> !26072
2021-10-02 18:47:57 <mps> andypost[m]: I'm not versed in boost, looks ok for my untrained eyes
2021-10-02 18:52:57 <Ariadne> o
2021-10-02 18:53:00 <Ariadne> i see
2021-10-02 18:53:04 <Ariadne> yes that makes sense
2021-10-02 18:53:11 <Ariadne> but i think version will still be preferred
2021-10-02 19:16:31 <Newbyte> do you have any idea what's happening with gtk-vnc on x86 in !26028?
2021-10-02 19:17:09 <Newbyte> loads of error locating (...) symbol not found
2021-10-02 19:17:49 <Newbyte> also, armv7 fails because the job takes too long. can I do something about that?
2021-10-02 19:17:59 <Newbyte> it's hard to make an MR like this not take long
2021-10-02 19:18:42 <Newbyte> Never mind, found the setting I think
2021-10-02 19:20:28 <Hello71> the "Error loading shared library libglib-2.0.so.0: No such file or directory" would seem to be more critical
2021-10-02 19:21:09 <Hello71> and if you scroll up a bit, "ERROR: libffi-3.3-r2: temporary error (try again later)"
2021-10-02 19:22:15 <Newbyte> oh, so I suppose that's the real problem
2021-10-02 19:22:30 <Newbyte> in which case, this would probably not be my bug?
2021-10-02 19:24:51 <Hello71> probably not
2021-10-02 19:48:57 <Newbyte> Nice, x86 built now
2021-10-02 22:14:24 <ddevault> Ariadne: thanks!
2021-10-03 09:09:16 <nmeum> libftdi1-1.5-r0 for armhf seems to have a bad signature on dl-cdn, could someone fix that? 🥺 already tried the curl -XPURGE trick but that didn't fix it
2021-10-03 09:09:44 <nmeum> see https://gitlab.alpinelinux.org/alpine/aports/-/jobs/504309 for example
2021-10-03 09:10:47 <ikke> possibly related to https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10728
2021-10-03 09:46:35 <ikke> nmeum: can you check again?
2021-10-03 11:08:48 <nmeum> ikke: the problem seems to persist https://gitlab.alpinelinux.org/alpine/aports/-/jobs/504376
2021-10-03 19:31:15 <ikke> perhaps another rsync issue
2021-10-03 19:31:32 <ikke> the file is different from the one on dl-master, but rsync does not want to update it
2021-10-03 19:39:47 <ikke> 'libftdi1-1.5-r0.apk is newer'
2021-10-04 08:05:54 <ikke> morning
2021-10-04 08:06:13 <mps> good morning
2021-10-04 08:21:19 <ncopa> goo dmorning
2021-10-04 08:21:55 <fcolista> _0/
2021-10-04 08:24:07 <fcolista> probably this has already been mentioned in the past weeks, but what's the workaround for openssl1-compat-dev and openssl-dev (3.0) conflict?
2021-10-04 08:24:08 <fcolista> https://tpaste.us/
2021-10-04 08:25:13 <mps> fcolista: something is missing after '/'
2021-10-04 08:25:36 <mps> but, rebuilding probably
2021-10-04 08:25:47 <fcolista> https://tpaste.us/dPb8
2021-10-04 08:26:10 <fcolista> nevermind
2021-10-04 08:26:12 <fcolista> done
2021-10-04 08:26:24 <fcolista> openssl-dev was installed in my buildenv
2021-10-04 08:26:36 <fcolista> just removed it. Sorry for the noise
2021-10-04 08:26:48 <mps> yes, that's clear from tpaste test
2021-10-04 08:26:53 <mps> text*
2021-10-04 09:47:20 <ddevault> Ariadne: your apk fix still doesn't appear to be working on edge
2021-10-04 09:51:43 <Ariadne> which issue?
2021-10-04 09:53:23 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13049
2021-10-04 09:53:39 <ikke> sorry, wrong one
2021-10-04 09:53:47 <ddevault> the segfault issue
2021-10-04 09:53:51 <ddevault> https://builds.sr.ht/~sircmpwn/job/601125#task-genimg-76
2021-10-04 09:53:53 <ddevault> this guy
2021-10-04 09:54:11 <mepholic> https://git.alpinelinux.org/aports/tree/main/lvm2/mlockall-default-config.patch
2021-10-04 09:54:17 <mepholic> anyone know what this patch is about?
2021-10-04 09:54:31 <Ariadne> my fix was to move it back to openssl 1.1
2021-10-04 09:54:49 <ddevault> does not seem to have worked
2021-10-04 09:55:07 <mepholic> ncopa seems to have added that patch originally
2021-10-04 09:55:50 <Ariadne> can you verify the apk package version ?
2021-10-04 09:56:05 <ddevault> please hold
2021-10-04 09:56:18 <ddevault> okay it was on my end
2021-10-04 09:57:28 <mepholic> > “use_mlockall = 0” means in theory the memory used by lvm and its libs could get swapped out, but that should only affect you in low-memory situations. So, in most situations “mlock failed: Cannot allocate memory” is only informational message, unless you really have low free RAM.
2021-10-04 09:57:30 <mepholic> oh lmao
2021-10-04 10:00:37 <Ariadne> phew :)
2021-10-04 10:36:21 <mepholic> new lvm2 release seems to not include sys/file.h in 2 files it needs to be
2021-10-04 10:36:23 <mepholic> odd
2021-10-04 10:36:26 <ikke> ncopa: not sure if you noticed, but an MR to enable running tests in CI for abuild: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/120
2021-10-04 10:38:00 <mps> objections or comments for !26059
2021-10-04 10:38:49 <mps> though (as I commented there) maybe we should move vim to community
2021-10-04 10:41:41 <psykose> i don't see why it would be in community
2021-10-04 10:42:39 <mps> why not
2021-10-04 10:43:07 <mps> we have busybox vi in main
2021-10-04 10:43:39 <mercenary> mps: To me that split makes perfect sense. Moving vim (as one of the first things I install one any machine) does not
2021-10-04 10:43:44 <psykose> following that reason every text editor should be in community
2021-10-04 10:43:50 <psykose> because busybox vi is in main
2021-10-04 10:43:58 <psykose> it doesn't make any coherent sense
2021-10-04 10:44:10 <mps> if we move vim to community then less often backport in case of security fixes
2021-10-04 10:44:38 <psykose> that goes for every single package in main, at which point it just becomes an edge only distro at some point
2021-10-04 10:45:01 <mps> psykose: that is good idea, move all text editors to community (maybe except nano)
2021-10-04 10:45:37 <mps> psykose: community has stable also
2021-10-04 10:45:43 <mps> stable release
2021-10-04 10:45:44 <mercenary> especially nano :p
2021-10-04 10:45:46 <psykose> but i thought if nano is in main that means it needs more fixes backported? should avoid that
2021-10-04 10:46:04 <psykose> we should move busybox to community actually
2021-10-04 10:46:09 <mepholic> +1 for moving all text editors to community
2021-10-04 10:46:13 <mercenary> and build busybox without vi, there is ed
2021-10-04 10:46:29 <ikke> busybox vi is unusable for me
2021-10-04 10:46:36 <mps> hmm, looks like some people have a lot of free time :)
2021-10-04 10:47:22 <Misthios> whats free time
2021-10-04 10:47:42 <mps> Misthios: :D (good question)
2021-10-04 10:48:17 <mps> back to question, please comment above MR
2021-10-04 10:49:06 <jvoisin> ^ excellent idea
2021-10-04 10:52:58 <clandmeter> i like bb vi, please dont kill it.
2021-10-04 10:59:02 <skarnet> ^
2021-10-04 11:01:57 <mps> no one wants to remove bb vi, iiuc
2021-10-04 11:05:13 <mps> ikke: also I prefer vim over bb vi, but use them both, on small devices bb vi mostly but on desktops and bigger server use vim
2021-10-04 11:45:10 <Hello71> mepholic: there are already at least two lvm mrs open
2021-10-04 11:46:51 <mepholic> in alpine's repo?
2021-10-04 11:49:24 <mepholic> ah i see
2021-10-04 19:06:16 <anjan> Hi, can someone review this patch https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24276 so that this patch https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24275#note_178372 can be reviewed?
2021-10-04 19:17:51 <ikke> anjan: You can combine them if they depend on eachother
2021-10-04 19:32:21 <anjan> ikke: Ive already fixed one of them....
2021-10-04 19:32:26 <anjan> It would be annoying to combine now
2021-10-04 19:40:31 <ikke> ok
2021-10-05 00:08:33 <tomalok> could someone remind me...  how far back do community repo security updates need to go?  master (obviously), 3.14-stable, ... any further? 
2021-10-05 00:20:45 <Hello71> https://alpinelinux.org/releases/
2021-10-05 00:20:57 <tomalok> thanks hello71
2021-10-05 08:41:58 <Misthios> PureTryOut (since it is your package) do you have any idea why the kdevelop rebuild keeps failing due to not being able to find clang when updated to 12?
2021-10-05 08:42:35 <Misthios> i tried patching the findclang.cmake file to also look for 12 but didnt make a difference
2021-10-05 08:43:02 <PureTryOut> Not out of the top of my head. Got a build log somewhere?
2021-10-05 08:58:31 <Misthios> let me grab one
2021-10-05 08:59:46 <Misthios> https://sourceb.in/lAsJuN6uyg
2021-10-05 09:00:32 <PureTryOut> Could you use a pastebin service that doesn't require JavaScript? 😅
2021-10-05 09:01:13 <Misthios> oh srry
2021-10-05 09:03:13 <Misthios> https://tpaste.us/0wo7 
2021-10-05 09:05:26 <PureTryOut> Thanks
2021-10-05 09:07:05 <PureTryOut> So patching https://invent.kde.org/kdevelop/kdevelop/-/blob/master/cmake/modules/FindClang.cmake#L33 to include clang 12 didn't help right?
2021-10-05 09:08:35 <PureTryOut> It seems for previous Clang/LLVM versions that was good enough https://invent.kde.org/kdevelop/kdevelop/-/commit/8abc96ce3b27156ca453603ec41ae7e278205f50
2021-10-05 09:08:55 <Misthios> nope, put 12 and 12.0.1 in there but it didnt seem to work
2021-10-05 09:12:59 <psykose> as a sanity check, clang/12.0.1/include/cpuid.h exists right
2021-10-05 09:17:57 <Misthios> i have 11.1.0 on my device, but it should atleast exist in ci (clang gets build before it) and in abuild rootbld since my local repo has clang12?
2021-10-05 09:21:54 <PureTryOut> I suppose so
2021-10-05 09:23:19 <PureTryOut> Seems like it should just work by adding 12 there. Better ask upstream I suppose
2021-10-05 09:24:37 <Misthios> i will
2021-10-05 09:24:42 <Misthios> ty anyway
2021-10-05 09:25:50 <PureTryOut> We do have a downstream patch that changes some paths it checks for Clang
2021-10-05 09:27:37 <mepholic> Misthios: do you see cpuid.h _anywhere_ under clang's include dir or library dir?
2021-10-05 09:27:50 <Misthios> yes
2021-10-05 09:28:13 <mepholic> where?
2021-10-05 09:28:16 <mepholic> specifically
2021-10-05 09:28:19 <Misthios> PureTryOut that shouldnt matter right? since the paths are the same just another version
2021-10-05 09:28:25 <mepholic> what is the full path?
2021-10-05 09:28:36 <PureTryOut> Yes so I don't assume that is why it breaks
2021-10-05 09:28:47 <mepholic> I don't see a clang12 apk anywhere so i assume you're trying to bump clang locally?
2021-10-05 09:29:08 <Misthios>  /usr/lib/clang/version/include/
2021-10-05 09:29:13 <mepholic> otherwise I'd just inspect it on pkgs.alpinelinux.org
2021-10-05 09:29:24 <mepholic> wait literally `version`?
2021-10-05 09:30:10 <mepholic> that is expected to be $(llvm-config --version)
2021-10-05 09:30:28 <Misthios> no not version, but thats just to indictate
2021-10-05 09:30:46 <mepholic> well I asked what the specific path was
2021-10-05 09:30:55 <mepholic> why would you modify it before sending it?
2021-10-05 09:30:59 <mepholic> that's literally not what I asked for
2021-10-05 09:31:17 <Misthios> then version = 11.1.0 locally since clang12 breaks some stuff
2021-10-05 09:31:32 <Misthios> but rootbld should use clang12 and so should the ci where it just breaks again
2021-10-05 09:31:51 <PureTryOut> Is the path `/usr/lib/clang/12.0/include` in clang12?
2021-10-05 09:32:06 <mepholic> are you sure that's a valid configuration? can you even use llvm 11 with clang12?
2021-10-05 09:32:28 <psykose> you should make quadruple sure they are both 12.0.1
2021-10-05 09:32:42 <Misthios> i do not use llvm11 with clang12
2021-10-05 09:32:52 <Misthios> just in a chroot i use llvm12 with clang12
2021-10-05 09:33:33 <mepholic> is your compiler/abuild running inside the chroot?
2021-10-05 09:33:47 <mepholic> does the chroot strictly have llvm12?
2021-10-05 09:34:16 <Misthios> i use abuild rootbld
2021-10-05 09:34:21 <mepholic> do you see cpuid.h anywhere inside the include dir for llvm12 in the chroot?
2021-10-05 09:34:52 <Misthios>  i will just make a normal chroot during my break to double check
2021-10-05 09:35:27 <psykose> include dir for clang12, but yes
2021-10-05 09:35:41 <mepholic> either way, the specific error you're getting indicates that cmake can't find whatever llvm include dir that the cpuid.h file is in
2021-10-05 09:36:04 <mepholic> see: https://invent.kde.org/kdevelop/kdevelop/-/blob/master/cmake/modules/FindClang.cmake#L105
2021-10-05 09:36:47 <mepholic> and: https://invent.kde.org/kdevelop/kdevelop/-/blob/master/cmake/modules/FindLLVM.cmake#L61
2021-10-05 10:09:21 <Misthios> i think i got it
2021-10-05 10:09:44 <Misthios> there were no >=12 statements so it pulled in llvm12 but decided to get clang11
2021-10-05 11:53:02 <ikke> python 3.10 release
2021-10-05 11:53:09 <ikke> but I guess too late for 3.15
2021-10-05 12:12:29 <psykose> force merge it
2021-10-05 13:13:36 <andypost[m]> The same for just-released llvm13
2021-10-05 13:21:06 <Misthios> 13 was to risky to try to get in
2021-10-05 13:28:18 <Hello71> ikke: some stuff is still broken, e.g. chromium (but i think alpine still uses python2)
2021-10-05 13:49:54 <mps> firefox 93.0 is released, and icu 'block' us to upgrade
2021-10-05 14:32:05 <Misthios> Rip
2021-10-05 14:46:45 <PureTryOut> Well icu is being blocked by Firefox too atm 😛 So the Firefox upgrade should probably become part of the icu MR's
2021-10-05 14:49:29 <mps> no, ff is blocked by icu, and not only icu
2021-10-05 14:49:39 <mps> no, ff is blocked by icu, and not only ff
2021-10-05 14:50:08 <mps> postgresql 14 fails with new icu
2021-10-05 14:50:49 <Misthios> And with llvm12 for some reason (at least on s390x)
2021-10-05 14:51:40 <amk> Hey, Is the mailinglist bot dead? I sent a patch about an hour ago and it hasnt shown up.
2021-10-05 14:52:00 <PureTryOut> mps: but icu is being blocked by Firefox too. Current Firefox in repos doesn't compile with newer icu it seems
2021-10-05 14:52:21 <Hello71> PureTryOut: just vendor everything /s
2021-10-05 14:52:58 <mps> PureTryOut: yes, but we should build current ff with new icu
2021-10-05 14:53:08 <mps> shouldn't*
2021-10-05 14:53:39 <mps> new ff with new icu builds fine
2021-10-05 14:55:01 <PureTryOut> Agreed, that's why I said the Firefox upgrade should probably be part of the ICU upgrade MR
2021-10-05 14:56:29 <mps> this way we will wait too loooooong
2021-10-05 14:56:48 <PureTryOut> How so?
2021-10-05 14:57:07 <ikke> ddevault: ^
2021-10-05 14:57:36 <mps> because first icu MR stays unfixed for more than a month, last time I looked blocker is postgresql on aarch64
2021-10-05 14:57:58 <ddevault> lines between source message and ^ exceeds maximum buffer length
2021-10-05 14:58:09 <ddevault> 
ACTION looks into it

2021-10-05 14:58:59 <ddevault> no, I don't think it's broken
2021-10-05 14:59:03 <ddevault> your patch does not appear on the mailing list
2021-10-05 14:59:06 <ddevault> did you get the address right?
2021-10-05 14:59:38 <ddevault> the last aports patch is my flask patch and it has a corresponding MR from the bot, so afaict the whole system is hunky-dory
2021-10-05 15:00:18 <amk> Yeah It should be right, I've got the address saved, I'll try resend it and see whats up
2021-10-05 15:00:58 <ddevault> if not reach out to whoever is responsible for the mail server, I forget
2021-10-05 15:02:17 <ddevault> and when you find out who, tell me so I can ask them a favor regarding the postfix config
2021-10-05 15:05:51 <andypost[m]> mps: pgp14 upgrade also stuck on timescale upgrade
2021-10-05 15:06:47 <andypost[m]> so if previous version works with new icu we could wait with upgrade of pg
2021-10-05 15:26:08 <mps> andypost[m]: I didn't tested pg 13.x
2021-10-05 15:26:36 <mps> will test now
2021-10-05 15:34:07 <andypost[m]> added comment about it to !24153
2021-10-05 15:36:49 <mps> andypost[m]: with icu-69.1-r0 postgresql-13.4-r2 builds fine with 'abuild -r' on aarch64 lxc
2021-10-05 15:37:50 <mps> revert pg to current in aport and merge icu MR
2021-10-05 15:38:01 <mps> next will be community
2021-10-05 15:39:01 <mps> yes, some pkgs will probably break but we have to do this sooner or later
2021-10-05 15:39:54 <mps> (wonder how we managed to have solid distro without gitlab :D )
2021-10-05 15:53:50 <andypost[m]> great news, thank you!
2021-10-06 01:03:41 <Seirdy> Hey, I noticed a certain Fedora issue I had was also visible in Alpine. It revolves around packaging Go programs and use of -buildmode=pie.
2021-10-06 01:03:43 <Seirdy> I sent this to a Fedora list, but I think the bits that aren't RPM-specific should apply here: https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org/thread/PKV3RRMQUBZVGK7CYMKMM4VI2HHVNLDI/
2021-10-06 01:05:54 <Seirdy> Essentially, both Fedora and Alpine use buildmode=pie when the Go runtime uses a fixed address regardless; buildmode=pie only makes a difference when CGO is involved, and for binaries that don't otherwise need CGO it only exists to tick a "make everything PIE" box and doesn't improve security. atl that's what the go authors have said.
2021-10-06 01:06:35 <Seirdy> wondering if any apk devs can chime in
2021-10-06 03:30:05 <psykose> if it doesn't harm security but is sometimes used (cgo) then it should just always be there anyway
2021-10-06 03:30:13 <psykose> the pie flag, that is
2021-10-06 08:18:10 <ncopa> Seirdy: what is the downside with static PIE? you mention that it means that binaries are linked to dynamic loader but that does not seem to be the case
2021-10-06 08:19:32 <ncopa> ah.. you are right. the dynamic linker is actually needed
2021-10-06 08:20:27 <ncopa> so the downside is that you cannot copy the binary to a place with different libc
2021-10-06 08:21:58 <ncopa> not sure it is worth to separate buildmode=pie
2021-10-06 08:23:05 <ncopa> i mean, i understand the benefit, but I'm not sure its worth the extra work, and risk to unintentionally disable PIE where it should be enabled
2021-10-06 09:22:12 <adhawkins> Is a package in community allowed to depend on a package in testing?
2021-10-06 09:22:28 <adhawkins> One of my packages has just been updated and has a new dependency which isn't packaged.
2021-10-06 09:29:37 <vyivel> i don't think that's allowed
2021-10-06 09:33:59 <adhawkins> Ok. In that case, is it ok for a package to go straight into community then? It's a python module that one of my other python module packages now depends on.
2021-10-06 09:34:16 <Cogitri[m]> Yes, you can move it directly to community
2021-10-06 09:36:35 <adhawkins> Ok great, thanks vyivel and Cogitri[m]
2021-10-06 09:57:53 <mps> will someone upgrade protobuf
2021-10-06 09:58:08 <mps> I could but have to remove ruby part
2021-10-06 09:59:03 <mps> I did this locally already
2021-10-06 10:35:02 <mps> hmm, looks like I fixed ruby part in it, though I don't 'understand' what i did :|
2021-10-06 10:37:16 <Misthios> magic
2021-10-06 10:50:40 <mps> I refactored one patch actually
2021-10-06 12:17:40 <adhawkins> Any python experts help me get this new package I'm working on to run its tests?
2021-10-06 12:17:52 <adhawkins> https://github.com/smarie/python-pytest-cases
2021-10-06 12:18:22 <adhawkins> I could push the branch I have to gitlab if it'd help. It needs another new package as one of its dependencies.
2021-10-06 12:20:20 <adhawkins> This is the output I'm getting: https://paste.debian.net/1214470/
2021-10-06 12:32:00 <adhawkins> !26195 if someone has time to take a look.
2021-10-06 12:36:26 <mps> fcolista: rnalrd: ncopa: !26194
2021-10-06 12:36:55 <mps> please review you pkgs there
2021-10-06 12:37:30 <mps> your*
2021-10-06 12:39:00 <jvoisin> ^ excellent idea
2021-10-06 12:46:34 <mps> uh, it fails one test on 32 bits arches
2021-10-06 12:46:57 <fcolista> LGTM, mps. Thanks!
2021-10-06 12:56:50 <rnalrd> mps all good tnx!
2021-10-06 12:58:46 <mps> thank you both for review
2021-10-06 12:59:31 <mps> looks like i have to readd and refactor skip-failing-tests.patch
2021-10-06 13:02:20 <adhawkins> Ah, my issue looks like a circular dependency perhaps.
2021-10-06 13:02:54 <adhawkins> pytest-cases depends on decopatch, and decopatch's tests requires pytest-cases...
2021-10-06 13:03:02 <adhawkins> Any way around that?
2021-10-06 13:11:25 <adhawkins> Would it be acceptable to disable the tests compeletely in decopatch, as the tests needs pytest-cases to run (which also depends on decopatch)
2021-10-06 13:25:37 <adhawkins> Ok, I've disabled the tests due to that circular dependency. Anyone care to comment on !26195
2021-10-06 13:46:12 <mps> ok, fixed this protobuf failed tests on 32bit arches, but don't have idea how to add it to MR with multiple commits
2021-10-06 13:46:52 <mps> except manually, recreate everything 'by hand'
2021-10-06 13:54:20 <ncopa> git rebase -i
2021-10-06 13:55:22 <ddevault> ncopa: you told me the other day that hoping someone else will fix a bug will generally not result in a fixed bug
2021-10-06 13:55:24 <ddevault> ncopa: proved you wrong :)
2021-10-06 13:55:59 <ddevault> you're generally correct, though, to be sure
2021-10-06 13:57:03 <mps> git rebase -i is option but have fear to make mess
2021-10-06 13:57:49 <mps> would be good exercise though
2021-10-06 14:09:28 <Hello71> Seirdy: i disagree with your premise that it is a problem for distro packages to require distro files, and i assume fedora commenters will say the same. additionally, the claim that aslr has no benefits for go code is belied by the fact that go data races can still cause arbitrary memory corruption. https://research.swtch.com/gorace,
2021-10-06 14:09:30 <Hello71> https://insanitybit.github.io/2016/12/28/golang-and-rustlang-memory-safety, https://github.com/netanel01/ctf-writeups/blob/master/googlectf/2019/pwn_gomium/README.md
2021-10-06 14:10:34 <Hello71> for your private binaries, you can use -buildmode pie -ldflags "-linktype external -extldflags -static-pie", but this doesn't actually "reduce attack surface"
2021-10-06 14:12:14 <Hello71> for proof that -buildmode=pie does do something: package main; import ( "fmt"; "reflect" ); func main() { fmt.Printf("%p", reflect.ValueOf(main).Pointer()) }
2021-10-06 14:13:30 <Hello71> running this program without -buildmode=pie always produces %!p(uintptr=4716288). with -buildmode=pie, it produces a large number that varies on each invocation
2021-10-06 14:50:27 <adhawkins> I have a number of packages that I maintain the are frontends or otherwise use borgbackup. Borgbackup isn't available on all architectures. Is there any way in my packages to refer to the list of architectures in the borg package, so that they stay in sync?
2021-10-06 14:56:34 <ddevault> not as far as I'm aware
2021-10-06 14:56:53 <ddevault> the common case is to leave a comment in the APKBUILD explaining why the arches are limited, i.e. due to borgbackup
2021-10-06 14:57:24 <ddevault> git grep 'arch.*rust' for examples
2021-10-06 14:58:57 <dalias> isn't available on all architectures?? wtf
2021-10-06 14:59:17 <dalias> it sounds like it would make more sense to investigate why that's the case and fix it
2021-10-06 14:59:44 <ddevault> https://github.com/zeromq/pyzmq/issues/1274
2021-10-06 14:59:59 <dalias> i can't imagine any legitimate reason for a backup program (vs something hardware-specific or 'reasonably' written in asm) to fail to build/run on some archs
2021-10-06 15:00:13 <ddevault> then your imagination is quite limited
2021-10-06 15:00:22 <ddevault> don't forget how awful software is
2021-10-06 15:00:44 <dalias> :)
2021-10-06 15:00:53 <dalias> it says right there that the bug is just in the test not the software
2021-10-06 15:01:14 <dalias> so the test should be disabled and the !s390x restriction removed
2021-10-06 15:01:33 <ddevault> no, the buggy test should be fixed
2021-10-06 15:01:55 <eris[m]> s390x is weird
2021-10-06 15:02:06 <dalias> that would be nice too but fixing should not be blocked on tests
2021-10-06 15:02:31 <dalias> this is one of the glibc mentalities i wanted to get past with musl
2021-10-06 15:02:45 <ddevault> yikes
2021-10-06 15:03:01 <dalias> leaving things broken because there's insufficient volunteer labor to write tests for the correct behavior
2021-10-06 15:03:27 <ddevault> big no thanks to that philosophy
2021-10-06 15:03:48 <dalias> known-broken is worse than "might still have problems because we haven't tested it well enough"
2021-10-06 15:04:12 <ddevault> my philosophy of testing generally devalues them
2021-10-06 15:04:24 <ddevault> but not entirely, and a test with an issue is a bug, and I don't work around bugs
2021-10-06 15:04:29 <ddevault> bugs are to be fixed, not avoided
2021-10-06 15:04:30 <dalias> in this case you could even avoid losing the test functionality on LE archs by adding #if BYTE_ORDER == LITTLE_ENDIAN around them
2021-10-06 15:04:46 <ddevault> any commit which "fixes" a bug by working around it is never accepted into any of my repositories
2021-10-06 15:04:48 <PJ[m]> or, OR, you can write patch for the software
2021-10-06 15:04:50 <dalias> in the presence of infinite labor availability, sure
2021-10-06 15:05:02 <ddevault> literally everything operates in terms of a labor scarcity
2021-10-06 15:05:07 <dalias> nobody's done that for over a year and a half since ariadne confirmed it's just an invalid test
2021-10-06 15:05:16 <ddevault> so pluck up
2021-10-06 15:05:23 <ddevault> you're the one who wanted this package to work on s390x
2021-10-06 15:05:31 <ddevault> once a sufficiently motivated person appears, the problem will be solved
2021-10-06 15:05:49 <dalias> no, i'm the one who wants contributors' time not to be wasted figuring out how to work around a dependency being missing on some archs
2021-10-06 15:06:10 <dalias> because someone disabled building it rather than disabling the buggy tesst
2021-10-06 15:06:11 <ddevault> it's a common problem that many contributors have to deal with, thanks to rust
2021-10-06 15:06:23 <ddevault> buggy tests are bugs
2021-10-06 15:06:26 <adhawkins> Is this an issue only on Alpine, or all distros that support s390?
2021-10-06 15:06:28 <dalias> no they're not
2021-10-06 15:06:32 <ddevault> yes, they are
2021-10-06 15:06:35 <dalias> they're in software other than the software being packaged
2021-10-06 15:06:43 <PJ[m]> they have PR opened  regarding licencing since 2017...
2021-10-06 15:06:43 <ddevault> nonsense
2021-10-06 15:06:48 <dalias> and so i don't care if they have bugs
2021-10-06 15:06:58 <dalias> if there's a bug in libc-test that's not a bug in musl
2021-10-06 15:07:13 <ddevault> the test either draws attention to a real bug (bug), or erroneously draws attention to itself, causing alarm fatigue (bug)
2021-10-06 15:07:41 <dalias> basically *every single* test failure i've reviewed over the past 2+ years has been a buggy test
2021-10-06 15:07:41 <ddevault> ignoring it is definitely the wrong answer
2021-10-06 15:07:45 <dalias> not a bug in the software being tested
2021-10-06 15:07:52 <dalias> tests have tiny SNR
2021-10-06 15:08:01 <ddevault> maybe your tests
2021-10-06 15:08:04 <dalias> not my tests
2021-10-06 15:08:04 <ddevault> don't write bad tests
2021-10-06 15:08:13 <dalias> tests of software alpine and other distros are building
2021-10-06 15:08:21 <dalias> it's a huge time sink
2021-10-06 15:08:26 <ddevault> anyway, disabling tests is a stupid answer
2021-10-06 15:08:35 <ddevault> what happens when another test fails, pointing out a genuine bug, and no one notices?
2021-10-06 15:08:42 <ddevault> until the CVE comes in, then everyone notices
2021-10-06 15:08:59 <eris[m]> i disable tests on personal packages
2021-10-06 15:09:12 <ddevault> well, that's a risk you may be willing to accept on a personal level
2021-10-06 15:09:15 <dalias> see for example https://github.com/Singular/Singular/issues/1114
2021-10-06 15:09:19 <ddevault> but it's not acceptable as a matter of policy for aports upstream
2021-10-06 15:09:44 <dalias> there should be some middle ground
2021-10-06 15:10:09 <dalias> if the test is passing on all but certain archs, a limited time window for feedback on whether it's a software bug or test bug
2021-10-06 15:10:14 <ddevault> yes, if you can make a sufficiently good case that actually fixing the bug is very difficult and the consequences of not shipping a workaround are severe
2021-10-06 15:10:17 <dalias> and once it's determined a test bug, test disabled for that arch
2021-10-06 15:10:28 <ddevault> but "this is annoying" is not that case
2021-10-06 15:10:30 <dalias> not 1.5 years
2021-10-06 15:10:38 <dalias> maybe 2 weeks or 30 days
2021-10-06 15:10:43 <ddevault> you got a problem, you fix the bug
2021-10-06 15:10:52 <ddevault> this software comes as-is, with no warranty or guarantee of fitness for purpose
2021-10-06 15:10:54 <dalias> there are actual *real bugs* to fix
2021-10-06 15:10:58 <dalias> and finite time/labor
2021-10-06 15:10:59 <ddevault> this
2021-10-06 15:11:02 <ddevault> is
2021-10-06 15:11:04 <ddevault> a real
2021-10-06 15:11:06 <ddevault> bug
2021-10-06 15:11:20 <dalias> ok since you want to argue over words, i won't use "real" like that
2021-10-06 15:11:33 <dalias> there are bugs that are actually *installed on the user's system* that need to be fixed
2021-10-06 15:11:38 <dalias> this is not one
2021-10-06 15:11:39 <ddevault> the purpose of the test suite is to establish confidence in the software it tests
2021-10-06 15:11:47 <ddevault> if the reliability of the test suite is not good, the confidence in the tested software is reduced
2021-10-06 15:11:58 <eris[m]> does confidence mattwr?
2021-10-06 15:12:08 <ddevault> it does to anyone running a production system
2021-10-06 15:12:11 <dalias> plenty of things with much lower confidence are packaged
2021-10-06 15:12:13 <PJ[m]> you could have just `return true` in all tests and then waht
2021-10-06 15:12:13 <ddevault> i.e. most alpine users
2021-10-06 15:12:17 <dalias> your argument is not valid
2021-10-06 15:12:27 <eris[m]> does confidence matter enough to stop someone using the package on s390x?
2021-10-06 15:12:30 <PJ[m]> s/waht/what/
2021-10-06 15:12:31 <dalias> you could even put these packages in a failing-tests repo
2021-10-06 15:12:50 <dalias> so users who want them cound install them and users who believe your "confidence" mumbo jumbo don't accidentally install them
2021-10-06 15:13:01 <ddevault> that less carefully packages exist doesn't counter the argument, it just points out a problem
2021-10-06 15:13:33 <ddevault> and yes, confidence matters, if alpine wants to support production use-cases
2021-10-06 15:13:43 <dalias> +http://rsync.alpinelinux.org/alpine/edge/failing-tests
2021-10-06 15:14:05 <ddevault> I think that'd sooner go to the existing unmaintained directory
2021-10-06 15:14:17 <ddevault> after all, what's the difference between this situation and any other unmaintained package
2021-10-06 15:14:18 <dalias> no, it's not a separate source section fo aports
2021-10-06 15:14:32 <ddevault> it has a bug no one wants to fix, that sounds like unmaintained to me
2021-10-06 15:14:33 <dalias> it's just a place the produced apk's would get placed if the "make test" failed
2021-10-06 15:14:36 <dalias> automatically
2021-10-06 15:14:43 <dalias> that's nonsense
2021-10-06 15:14:43 <ddevault> bugs don't get fixed by incentivizing workarounds
2021-10-06 15:14:54 <dalias> zeromq is not unmaintained
2021-10-06 15:15:01 <ddevault> zeromq on alpine is not maintained
2021-10-06 15:15:13 <dalias> s390x is understaffed and the bug is hidden to everyone not on s390x
2021-10-06 15:15:27 <ddevault> if you don't care, then the status quo is fine
2021-10-06 15:15:34 <ddevault> if you care, then you are the perfect one to fix it
2021-10-06 15:15:47 <dalias> i've already wasted more time than i wanted to arguing with you over this >_<
2021-10-06 15:15:50 <ddevault> don't incentivize workarounds, incentivize problem solving
2021-10-06 15:16:13 <adhawkins> If I wanted to look in to this, is there any way I could emulate an s390 environment locally (to me) to test it?
2021-10-06 15:16:24 <PJ[m]> with qemu you can
2021-10-06 15:16:27 <dalias> qemu should work but slow
2021-10-06 15:16:40 <ddevault> the qemu binfmt handler is reasonably fast
2021-10-06 15:16:50 <ddevault> I have a useful riscv64 chroot whose performance is acceptable for most uses
2021-10-06 15:16:59 <adhawkins> Would anyone be prepared / able to help me get it set up? A nice docker container would be perfect :)
2021-10-06 15:17:01 <PJ[m]> there are also some bugs in s390x qemu
2021-10-06 15:17:02 <ddevault> easier to set up than a full blown VM too
2021-10-06 15:17:52 <ddevault> adhawkins: this should be enough to start googling for, might also recommend reading man apk/man apk-add to learn how to create the chroot
2021-10-06 15:18:07 <ddevault> or you can use the mini rootfs https://dl-cdn.alpinelinux.org/alpine/v3.14/releases/s390x/alpine-minirootfs-3.14.2-s390x.tar.gz
2021-10-06 15:18:34 <Hello71> isn't the alpine riscv64 builder is still using qemu-user
2021-10-06 15:18:41 <Hello71> s/is //
2021-10-06 15:18:42 <ikke> yes + docker
2021-10-06 15:18:51 <adhawkins> Found a docker container that purports to do it, but it hasn't been updated in 6 years...
2021-10-06 15:19:01 <ddevault> add qemu-s390x and qemu-openrc, start qemu-binfmt, extract the mini rootfs, and you can chroot into it normally
2021-10-06 15:19:21 <PJ[m]> you can/should use docker images that are used in aports gitlab pipelines
2021-10-06 15:19:23 <ikke> if you have binfmt setup, you can also use odkcer
2021-10-06 15:19:25 <ikke> docker
2021-10-06 15:19:57 <adhawkins> This is all stuff that is new to me I'm afraid. Never used qemu.
2021-10-06 15:20:48 <ddevault> https://xkcd.com/1988/
2021-10-06 15:21:09 <ddevault> adhawkins: install those two packages, then service qemu-binfmt start, then extract the tarball I linked and run `chroot path/to/extracted/tarball/ /bin/sh` as root
2021-10-06 15:21:40 <ddevault> qemu is an emulator which can create an emulated s390x VM on your machine
2021-10-06 15:21:45 <PJ[m]> or install docker and skip on migraine
2021-10-06 15:21:57 <ddevault> what migrane, this is four steps and you're done
2021-10-06 15:22:03 <dalias> hello71, really? qemu-user is quite deficient and will almost certainly make some configure tests produce different results from what they should
2021-10-06 15:22:26 <adhawkins> I have docker installed and available. If there were a simple way to invoke a container that would do it, that would be better for me.
2021-10-06 15:22:39 <adhawkins> I already run the alpine-ci container locally to test builds before I push up to gitlab.
2021-10-06 15:22:40 <PJ[m]> `docker run --platform linux/s390x alpinelinux/alpine-gitlab-ci:latest`  
2021-10-06 15:22:42 <ddevault> I told you every command, you just need to copy and paste them into your terminal -_-
2021-10-06 15:22:45 <dalias> for some archs it even has some of the kernel syscall types wrong
2021-10-06 15:22:46 <ddevault> please yourself
2021-10-06 15:22:46 <clandmeter> docker also needs qemu-user
2021-10-06 15:22:49 <ddevault> the state of modern software development
2021-10-06 15:22:55 <clandmeter> so its not "easier"
2021-10-06 15:23:00 <clandmeter> except on macos i think
2021-10-06 15:23:11 <PJ[m]> it's definitely much easier
2021-10-06 15:23:40 <ddevault> docker: just learn this one tool and you'll never learn anything else ever again!
2021-10-06 15:23:46 <Hello71> dalias: yes but we don't have any riscv64 hardware, so "half the packages broken" is an improvement over "all the packages are broken"
2021-10-06 15:23:56 <PJ[m]> you realise that Alpine CI is literally running Docker?
2021-10-06 15:23:57 <Hello71> PJ[m]: for people who have never heard of chroot
2021-10-06 15:24:08 <dalias> hello71, alpine doesn't have a beagle-v or anything?
2021-10-06 15:24:09 <clandmeter> PJ[m]: i think we do
2021-10-06 15:24:47 <PJ[m]> not ddevault it seems
2021-10-06 15:24:50 <ddevault> I maintain an alpine system on riscv64 and I haven't noticed any issues (at least none that couldn't be fixed)
2021-10-06 15:24:54 <clandmeter> anyway, if its easier for you, thats cool and keep using it.
2021-10-06 15:24:56 <Hello71> dalias: i think some people have hardware but not connected to alpine infra
2021-10-06 15:25:03 <ddevault> I don't have an issue with qemu-user for riscv64
2021-10-06 15:25:08 <clandmeter> i do
2021-10-06 15:25:09 <clandmeter> :p
2021-10-06 15:25:14 <ddevault> 
ACTION shrugs

2021-10-06 15:25:18 <clandmeter> ash does not load the profile :)
2021-10-06 15:25:24 <ddevault> lol
2021-10-06 15:25:29 <ddevault> that it does not
2021-10-06 15:25:33 <ddevault> I have to use . /etc/profile every time
2021-10-06 15:25:35 <ncopa> ddevault: what bug got fixed?
2021-10-06 15:25:45 <adhawkins> If the docker command above complains about a binary format error, is that because I'm missing qemu? What Debian package should I install to get that? Any idea?
2021-10-06 15:25:45 <clandmeter> well and more freaky stuff, but thats out of this scope :)
2021-10-06 15:25:45 <ddevault> ncopa: chromium, though it wasn't fixed so much as a suitable workaround found
2021-10-06 15:25:59 <ddevault> the fix is trivially added to the aport should someone feel so inclined, there's a write-up in a gitlab issue
2021-10-06 15:26:22 <ddevault> adhawkins: yes. The steps you have to follow to fix the problem are almost exactly 1:1 with the steps I suggested you follow without docker
2021-10-06 15:26:52 <clandmeter> ddevault: did you ever looking to the issue that profile does not get sourced?
2021-10-06 15:27:02 <ddevault> it's a login shell, so it wouldn't be
2021-10-06 15:27:05 <ddevault> it's not* a login shell
2021-10-06 15:27:17 <ddevault> swap /bin/sh for /bin/login instead and it might work
2021-10-06 15:27:24 <Hello71> or just use /bin/sh -l?
2021-10-06 15:27:26 <PJ[m]> adhawkins: normally you can just run `docker run --privileged --rm tonistiigi/binfmt --install all` to have all `qemu-*` configured
2021-10-06 15:27:29 <ddevault> does that work?
2021-10-06 15:27:39 <clandmeter> i think it never works, even if  ssh into a container
2021-10-06 15:27:49 <clandmeter> lxc container
2021-10-06 15:27:51 <ddevault> you should get a profile when you SSH
2021-10-06 15:27:58 <clandmeter> nope
2021-10-06 15:28:03 <ddevault> weird
2021-10-06 15:28:10 <Hello71> i mean normally the problem is that you don't have access to set the command line. if you're already specifying /bin/sh then just stick -l on the end
2021-10-06 15:28:19 <ddevault> I dunno about containers but that's not an issue for SSHing into any of my alpine hosts
2021-10-06 15:28:24 <clandmeter> i guess its has soemthing to do with argv beeing mangled
2021-10-06 15:28:29 <ddevault> Hello71: I meant that -l is non-POSIX, I was not aware of such a feature
2021-10-06 15:28:53 <PJ[m]> normally you should use `login`
2021-10-06 15:28:58 <ddevault> do you use `ssh user@host command...` or do you use `ssh user@host` and then run `command...` in the shell that comes up
2021-10-06 15:29:01 <Hello71> hm, i thought it was posix. didn't know that posix sh has so few options
2021-10-06 15:29:02 <ddevault> only the latter will source the profile
2021-10-06 15:29:06 <ddevault> this is the expected behavior
2021-10-06 15:29:58 <adhawkins> PJ[m]: Mind if I DM you?
2021-10-06 15:30:42 <PJ[m]> sure
2021-10-06 15:31:20 <PJ[m]> not sure if that will work though, since I'm on matrix 😛
2021-10-06 15:33:53 <dalias> i think it's standard posix behavior that sh invoked with - at beginning of argv[0] is a login shell
2021-10-06 15:34:04 <dalias> so if you have a way to exec with custom argv0 that would work
2021-10-06 15:34:13 <ddevault> aye, this is how it works, but there's no way to do that
2021-10-06 15:34:31 <ddevault> it's not really considered a problem, you're not supposed to depend on your login shell configuration to do things when there's not a login session
2021-10-06 15:34:37 <dalias> ln -s /bin/sh /tmp/-sh
2021-10-06 15:34:46 <dalias> :)
2021-10-06 15:35:05 <ddevault> okay, there is a way to do that :)
2021-10-06 15:35:07 <ddevault> but please don't ;_;
2021-10-06 15:36:25 <adhawkins> Ok, with PJ[m]'s help I now have an S390 alpine docker container running that I can get a shell in, Might see if my Python skills are up to fixing that test. Wish me lucj.
2021-10-06 15:36:34 <ddevault> good luck.
2021-10-06 15:37:46 <adhawkins> That's what he said ddevault :)
2021-10-06 15:38:03 <PJ[m]> heh
2021-10-06 15:38:18 <adhawkins> Thanks all for the assistance. That's my little project for this evening sorted! :)
2021-10-06 15:39:31 <mps> I think I will merge protobuf MR, and rebuild pkgs when I found time. maintainer of dependent pkg also should
2021-10-06 15:39:47 <mps> ncopa: ^ ?
2021-10-06 15:40:15 <mps> you are protobuf maintainer
2021-10-06 15:40:56 <mps> (intentionally skipped protobuf-c upgrade for now)
2021-10-06 15:43:32 <Ariadne> wait what?
2021-10-06 15:43:47 <Ariadne> dalias: i did what now 18 months ago?
2021-10-06 15:44:18 <PJ[m]> this probably: https://github.com/zeromq/pyzmq/issues/1274#issuecomment-610701488
2021-10-06 15:44:22 <dalias> ariadne, determine that the zeromq test failure on s390x is a buggy test
2021-10-06 15:44:28 <dalias> (assuming little endian)
2021-10-06 15:46:08 <Ariadne> no
2021-10-06 15:46:16 <Ariadne> that’s not what i was implying
2021-10-06 15:46:29 <Ariadne> the functionality is intact broken, the test failure is legit
2021-10-06 15:46:56 <adhawkins> Ah.
2021-10-06 15:47:09 <Ariadne> i was saying the failure is caused by a lack of endian conversion
2021-10-06 15:47:26 <Ariadne> probably in libzmq
2021-10-06 15:47:27 <adhawkins> I assumed it was the test that wasn't doing the conversion.
2021-10-06 15:47:56 <Ariadne> infact*
2021-10-06 15:49:36 <dalias> oh? then i misread it
2021-10-06 15:49:44 <adhawkins> Me too dalias :)
2021-10-06 15:51:04 <skarnet> so you had an entire philosophical discussion on the nature of buggy tests, and it turns out the test was not buggy
2021-10-06 15:51:47 <dalias> i figured there was just test code using the library to send a binary data structure in host endianness, and some python parsing code saying "parse this as little endian"
2021-10-06 15:52:01 <dalias> that's what it looked like from the report
2021-10-06 15:52:17 <dalias> but you're saying zeromq really has broken endian assumptions??
2021-10-06 15:52:39 <jvoisin> clandmeter: if you find a nice way to have ash source the /etc/profile in lxc, let me know. Not having the hostname displayed is making me sad on every login
2021-10-06 15:52:56 <ikke> Is there a way to set ENV?
2021-10-06 15:53:13 <ikke> Though, that would be sourced on every shell, not just login shells
2021-10-06 15:53:25 <Ariadne> dalias: i am implying that the control socket does not correctly handle endian conversions yes
2021-10-06 15:53:50 <Ariadne> or, perhaps "correctly" is inaccurate here
2021-10-06 15:53:55 <dalias> ikke, i split mine into .env and .profile, and .profile exports ENV=~/.env and sources ~/.env
2021-10-06 15:54:10 <Ariadne> perhaps it is intentional that zeromq sends control data in little endian and pyzmq does not convert it
2021-10-06 15:54:22 <Ariadne> either way, the bug is in the handling of control messages
2021-10-06 15:54:42 <PJ[m]> major shells have way to detect if it's a login shell
2021-10-06 15:55:08 <dalias> (btw even if the bug is in zeromq, having it built for s390x would make the bug show up in software using it, so it would get debugged)
2021-10-06 15:55:51 <Ariadne> in any case, i was just documenting the cause of the test failure, not speculating on the validity of the test (but i think testing the control message parsing seems legitimate)
2021-10-06 15:55:52 <ddevault> (we don't need to do that)
2021-10-06 15:56:04 <ddevault> (the bug has already shown up and it will get debugged as soon as someone wants the package back)
2021-10-06 15:56:11 <Ariadne> what ddevault said
2021-10-06 15:58:08 <adhawkins> Ok, I'll stand down then.
2021-10-06 15:58:23 <adhawkins> At least now I know I can run containers for different architectures :)
2021-10-06 15:58:37 <Ariadne> generally, i do try to fix packages instead of disable them for trivial test failures, by the way
2021-10-06 15:59:16 <Ariadne> the fact that i did not here is because fixing this is not trivial, it requires figuring out which "side" of the concern needs to handle the endian conversion
2021-10-06 15:59:27 <Ariadne> and, indeed, the test itself could still be flawed
2021-10-06 16:00:22 <Ariadne> but 1 != 72057594037927936 (0x10000000000000) is a classic endianness fail
2021-10-06 16:00:55 <ddevault> as dalias points out, we lack infinite labor
2021-10-06 16:01:10 <ddevault> not shipping a broken package is a better solution than shipping a known defect if there's no time to fix it properly
2021-10-06 16:01:16 <Ariadne> yup
2021-10-06 16:02:24 <dalias> ariadne, do you like my "failing-tests" repo idea at all?
2021-10-06 16:02:42 <Ariadne> uhh
2021-10-06 16:02:53 <Ariadne> as in put packages which fail tests in their own repo?
2021-10-06 16:02:54 <dalias> having the builders put packages that build, but fail in test stage, in a failing-tests repo where users can install at their own risk :)
2021-10-06 16:03:03 <dalias> not moving anything at the aports source level
2021-10-06 16:03:08 <dalias> just having the output go there and be available
2021-10-06 16:03:17 <dalias> and allowing dependent packages to be built based on it
2021-10-06 16:03:24 <ddevault> disincentivising anyone to fix it, reducing the already short labor pool
2021-10-06 16:03:28 <dalias> (but then only installable if you enable the failing-tests repo)
2021-10-06 16:03:34 <dalias> i think it helps fixing it
2021-10-06 16:03:46 <Ariadne> i think it will just piss off users
2021-10-06 16:03:48 <dalias> because you're not just stuck with the incomprehensible tests
2021-10-06 16:03:59 <dalias> you can install a package that uses the library with failing tests
2021-10-06 16:04:02 <Ariadne> who don't want to think about enabling even more repos
2021-10-06 16:04:04 <dalias> and debug it in a real world context
2021-10-06 16:04:11 <ddevault> you can already do that to debug the aport
2021-10-06 16:04:13 <dalias> the vast majority of tests i've seen are undebuggable
2021-10-06 16:04:18 <ddevault> and you will almost certainly do so in the process
2021-10-06 16:04:23 <dalias> impossible to even figure out how to invoke the test the same way the build system did
2021-10-06 16:04:37 <ddevault> undebuggable? what?
2021-10-06 16:04:52 <dalias> when i encounter a failing test someone's reported
2021-10-06 16:04:53 <ddevault> what're you packaging, giant webshit modules which depend on a network connection and four external services to run their tests?
2021-10-06 16:04:57 <Ariadne> if i might steer this conversation in another direction,
2021-10-06 16:05:15 <Ariadne> do you know when we can expect a new musl release?
2021-10-06 16:05:22 <dalias> 99% of my time is spent figuring out which file is the actual test source and how it's invoked by the build system in a way i can reproduce it or just read what it's doing
2021-10-06 16:05:29 <dalias> once i know that, fixing it usually takes <1 minute
2021-10-06 16:05:36 <Ariadne> theres a lot of stuff in musl git we want to include in alpine 3.15 :)
2021-10-06 16:05:49 <dalias> ok let's talk about that :)
2021-10-06 16:08:30 <dalias> is there anything not in now that you'd like to see in a release?
2021-10-06 16:09:02 <dalias> the mntent stuff is a candidate (it's known buggy right now) but there are multiple questionable proposals
2021-10-06 16:09:28 <Ariadne> the only thing would be qsort_r i think
2021-10-06 16:09:40 <dalias> it's in :)
2021-10-06 16:09:57 <Ariadne> i have not had caffinated beverage yet :)
2021-10-06 16:10:31 <dalias> np
2021-10-06 16:10:46 <Ariadne> then, no, we're not waiting on anything new, other than a new release :P
2021-10-06 16:10:52 <skarnet> friendly reminder that I still have a fsent.h implementation in a git corner, waiting to be included in musl :P
2021-10-06 16:11:16 <skarnet> (since you were speaking of mntent.h)
2021-10-06 16:11:32 <skarnet> s/fsent/fstab/
2021-10-06 16:14:05 <dalias> :)
2021-10-06 16:17:03 <mps> Ariadne: qsort_r is already in alpine, as patch though
2021-10-06 16:41:06 <clandmeter> jvoisin: are you using rv64 in lxc? 
2021-10-06 17:05:50 <ericonr> dalias: if possible, pulling in the nscd fix would be nice
2021-10-06 17:06:39 <Ariadne> google sent me a fascinating stress test for pkgconf
2021-10-06 17:07:49 <Ariadne> it does not stress the freedesktop version because the freedesktop version doesn't actually try to solve dependencies
2021-10-06 17:08:19 <Ariadne> it just lazily checks them at the end
2021-10-06 17:08:51 <dalias> ericonr, which one?
2021-10-06 17:09:00 <Ariadne> pkgconf solves dependencies as it encounters them
2021-10-06 17:09:06 <dalias> do you meean commit 0ea78a6421322cab24d448670006ee2f99af3ac9 ?
2021-10-06 17:09:47 <Ariadne> so the solution is to track already encountered *constraints* and reuse their solutions
2021-10-06 17:10:17 <Ariadne> which is possibly also a useful optimization to apk-tools
2021-10-06 17:10:30 <ericonr> dalias: no, the one for response[FOUND]==-1
2021-10-06 17:10:51 <dalias> oh
2021-10-06 17:17:49 <dalias> looking back at it i'm a little bit unsure on the semantic correctness but it's almost surely better than what happens now
2021-10-06 17:18:27 <dalias> i wonder what nscd is supposed to do if it hits an error communicating with the backend
2021-10-06 17:18:42 <dalias> seems like error and notfound should be distinguished
2021-10-06 17:19:04 <dalias> but then we get gratuitous error in the "configured not to respond" case
2021-10-06 17:20:32 <skarnet> well if you just look at the getpwnam() level, error and notfound need to be distinguished indeed, since error modifies errno and notfound does not
2021-10-06 17:37:07 <Seirdy> Hello71: that link is interesting, but does the situation change when using buildmode=pie? my understanding is that the Go runtime uses a fixed address even if you run buildmode=pie, and that the pie buildmode exists for compliance but doesn't actually make the runtime """really""" position-independent.
2021-10-06 17:37:46 <Hello71> i posted three links and also a test. did you run the test
2021-10-06 17:40:14 <Seirdy> 
ACTION scrolls up

2021-10-06 17:40:23 <Seirdy> i just responded to what was in my highmon
2021-10-06 17:42:21 <Seirdy> ncopa: PIE introduces complexity (CGO) and increases binary size, the latter of which might be a bit more relevant to Alpine; while ASLR is a Good Thing, buildmode=pie doesn't really achieve nearly what -pie does in a C toolchain, so I wasn't convinced it was worth the cost
2021-10-06 17:42:27 <Seirdy> Hello71: I'll try running it later today
2021-10-06 17:46:24 <dalias> skarnet, any idea what we should do there? (also maybe move this to #musl)
2021-10-06 17:48:16 <Seirdy> Hello71: that test is interesting; do you know if it's a result of recent changes introduced after the golang-nuts thread I linked?
2021-10-06 17:48:42 <skarnet> dalias: I forgot the details of the nscd protocol, and these days I'm useless if a question needs focus, code reading etc.
2021-10-06 17:49:20 <dalias> *nod*
2021-10-06 18:00:34 <jvoisin> clandmeter: I'm using alpine x64 in lxc
2021-10-06 18:10:27 <ikke> oof, llvm12 takes long on aarch64 for some reason. 9h and going
2021-10-06 18:24:02 <Ariadne> is it actually building
2021-10-06 18:24:05 <Ariadne> or is it stuck
2021-10-06 18:24:38 <ikke> It's building, not stuck
2021-10-06 18:25:18 <ikke> The build is about to timeout though
2021-10-06 18:26:59 <andypost[m]> I seen reports about 20h of building(
2021-10-06 18:28:21 <mps> is this complete MR or just one pkg?
2021-10-06 18:29:21 <ikke> oh right, multiple packages
2021-10-06 18:30:48 <mps> I advised Misthios to make it one by one, it is easier ime
2021-10-06 18:41:14 <andypost[m]> As I heard llvm13 build time is x4
2021-10-06 18:43:31 <andypost[m]> Would be great to fix llvm11 while 12 coming via !23389
2021-10-06 18:45:08 <mps> andypost[m]: what is with !14092 
2021-10-06 18:46:17 <andypost[m]> IIRC pg14 won't build with it so not clear how to proceed
2021-10-06 18:46:36 <mps> remove upgrade to pg 14
2021-10-06 18:46:57 <mps> i.e. just bump pkgrel
2021-10-06 18:47:06 <andypost[m]> then question of upgrade firefox&co 
2021-10-06 18:47:49 <mps> firefox will build fine on my test on x86_64, aarch64 and armv7
2021-10-06 18:48:11 <mps> I have it already
2021-10-06 18:48:42 <mps> I hope we would fix other pkgs in time for release 3.15
2021-10-06 18:49:28 <andypost[m]> PureTryOut (matrix.org): asked about it - iicr icu upgrade is a blocker for ff
2021-10-06 18:49:44 <mps> no in my tests
2021-10-06 18:50:03 <andypost[m]> I recall seamonkey wont's build
2021-10-06 18:50:16 <mps> why we keep this pkg?
2021-10-06 18:50:29 <andypost[m]> no idea about this legacy
2021-10-06 18:50:57 <mps> there are not small number pkgs in aports which should be removed imo
2021-10-06 18:51:41 <mps> but we have to upgrade icu, it blocks some other pkgs for next release
2021-10-06 19:00:16 <andypost[m]> mps: the list from month ago https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14092#note_177353
2021-10-06 19:01:41 <mps> yes, that's ok
2021-10-06 19:02:01 <mps> I got it with 'ap revdep icu-dev'
2021-10-06 19:39:17 <andypost[m]> mps: I got build of pg14 with new icu without issues
2021-10-06 19:39:24 <andypost[m]> on x86_64
2021-10-06 19:39:58 <andypost[m]> running check
2021-10-06 19:43:56 <mps> what about aarch64?
2021-10-06 20:12:36 <andypost[m]> rebased MR let's see
2021-10-06 20:13:53 <Misthios> Llvm12 rebuilds are (nearly) done just some random things
2021-10-06 20:14:18 <Misthios> Like postgres not rebuilding on s390x and ff not on x86_64 and some smaller ones
2021-10-06 20:15:29 <Misthios> (and armhf hitting the 10h timeout)
2021-10-06 20:56:17 <andypost[m]> mps: aarch64 passed https://gitlab.alpinelinux.org/alpine/aports/-/jobs/506666 but armhf failed
2021-10-06 21:10:50 <mps> andypost[m]: hmm, postgresql, dovecot and postfix failed, if I see correctly
2021-10-06 21:12:00 <mps> uh, I looked wrong job
2021-10-06 21:12:31 <andypost[m]> mps: no, aarch64 - main/libical, ppc64le - main/postgresql 
2021-10-06 21:12:49 <mps> yes, I see
2021-10-06 21:14:35 <mps> but it is late now, going to bed. good night
2021-10-06 21:15:19 <andypost[m]> good night! leaving soon too
2021-10-06 21:20:02 <adhawkins> Ok, so my attempts to look at zeromq on S390 haven't got very far.
2021-10-06 21:20:26 <adhawkins> Ported one of the test cases from the main lib to a standalone program. That runs fine on amd64, but falls at the first hurdle (creating a socket) on S390.
2021-10-06 21:20:33 <adhawkins> Anyone know if 0mq works at all on S390?
2021-10-06 21:20:52 <adhawkins> Or is it just because I'm running it under docker / qemu?
2021-10-06 21:23:03 <Seirdy> ikke: hasn't llvm13 been out for a little while, tho?
2021-10-06 21:24:06 <ikke> No idea
2021-10-06 21:24:07 <Hello71> yes, a whole 5 days
2021-10-06 21:24:13 <ikke> heh
2021-10-06 21:24:15 <Seirdy> > little
2021-10-06 21:24:17 <ikke> :D
2021-10-06 21:24:39 <Hello71> actually, officially, less than two days
2021-10-06 21:25:09 <ikke> Hello71: wondering what's taking us so long to update 🤐
2021-10-06 21:25:25 <Hello71> probably main reason is that 20 hour compile time
2021-10-06 21:25:46 <ikke> Yeah, we're still trying to get 12 in
2021-10-06 21:25:55 <Hello71> should be more like 5 hours, but still annoying to test
2021-10-06 21:26:17 <Seirdy> (noob question) why not skip 12 and jump to 13?
2021-10-06 21:28:51 <PJ[m]> because not everyone will switch to 13 instantly given it just released
2021-10-06 21:29:31 <Seirdy> ofc rn is a bit early
2021-10-06 21:30:14 <Seirdy> but why not wait a few weeks, and then do 13 instead of trying to test everything against 12?
2021-10-06 21:32:45 <Hello71> because we need to release 3.15
2021-10-06 21:32:45 <eris[m]> it takes a while for things to change, no?
2021-10-06 21:33:04 <eris[m]> in terms of dependencies
2021-10-06 21:33:12 <Hello71> and "few weeks" is not really that long, especially considering that it should be 13.0.1, and *then* wait "few weeks"
2021-10-06 21:33:24 <Seirdy> Hello71: ic
2021-10-06 21:33:31 <eris[m]> actually, qiestion bcos i cant navigate alpine website on a phone all that well
2021-10-06 21:33:42 <eris[m]> do you force rust to use system llvm?
2021-10-06 21:33:55 <Hello71> or more likely, 13.0.1, then wait months for upstreams to be patched for llvm on glibc, then wait months for someone to get around to llvm on alpine again
2021-10-06 21:33:56 <eris[m]> or do you let it use its vendored one
2021-10-06 21:34:13 <eris[m]> hmm, i cany remember if system llvm is even possible with rust
2021-10-06 21:35:07 <Seirdy> Hello71: might be worth borrowing from Void a bit.
2021-10-06 21:35:24 <Hello71> we are aware of the existence of void linux
2021-10-06 21:36:04 <Hello71> eris[m]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/rust/APKBUILD#L31
2021-10-06 21:36:30 <Hello71> it used to be not really working, but nowadays rust patches llvm slowly enough that upstream llvm mostly works
2021-10-06 21:40:12 <eris[m]> cool!
2021-10-06 21:45:59 <Seirdy> reading through https://gitlab.alpinelinux.org/alpine/aports/-/issues/11083, have there been any updates to musl blockers for clang's missing sanitizers (cfi, safe-stack, shadow-call-stack, etc)? my understanding is that it is possible to use them with musl on other musl-based distros.
2021-10-06 22:40:01 <Hello71> theoretically it should work with llvm 12
2021-10-07 00:04:54 <Hello71> which alpine archs are big-endian? mips64, and that's it?
2021-10-07 00:05:06 <Hello71> mips too i guess
2021-10-07 00:09:33 <Hello71> Ariadne: it occurred to me that requiring sse2 would fix https://gitlab.alpinelinux.org/alpine/aports/-/issues/11645
2021-10-07 00:12:06 <Hello71> or, wait, does it?
2021-10-07 00:15:03 <Ariadne> i have no idea
2021-10-07 00:23:57 <Hello71> i know the issue is sse2 *related* but not sure if enabling sse2 would actually fix it, or if musl always needs the fp control word to be the default one or whatever
2021-10-07 00:25:03 <Hello71> or sse1? no idea
2021-10-07 00:52:07 <dalias> hello71, the fp control word must always be valid regardless of sse
2021-10-07 00:52:13 <Hello71> mm.
2021-10-07 00:52:15 <dalias> the affected code is using ld80 math
2021-10-07 00:52:32 <Hello71> you mean in musl, not in php
2021-10-07 00:52:36 <dalias> right
2021-10-07 00:53:01 <dalias> i mean making php use sse would make getting rid of their broken control word setting easier
2021-10-07 00:53:07 <dalias> but you need to get rid of it
2021-10-07 01:07:48 <Hello71> mm.
2021-10-07 05:34:45 <Ariadne> #13068 is an RFC on dropping mozilla official branding (and also all of the advertising crap)
2021-10-07 05:35:22 <Ariadne> i think we have tried to be sympathetic to Mozilla's situation, but on the other hand, advertising in the address bar is just too much
2021-10-07 06:00:45 <psykose> is this new in 93? i think gentoo has it patched out as i don't see the new ad options in the settings
2021-10-07 06:57:27 <kunkku> is there a FF add-on that would prevent advertising? :)
2021-10-07 07:05:52 <mps> kunkku: I think it is called w3m ;)
2021-10-07 07:12:38 <psykose> inside ff itself? you can toggle it in the settings
2021-10-07 07:12:52 <psykose> on websites? ublock origin
2021-10-07 07:39:55 <Ariadne> psykose: whatever nightly is, it seems
2021-10-07 07:40:51 <psykose> ah, nightly is generally 2 versions ahead
2021-10-07 07:40:55 <psykose> bad sign though
2021-10-07 07:52:45 <Ariadne> anyway, i think we should purge the adware in its entirety at this point
2021-10-07 07:53:03 <Ariadne> sponsored tiles was one thing, but this address bar shit is ridiculous
2021-10-07 07:59:01 <psykose> +1 from me
2021-10-07 08:01:47 <psykose> the suggested librewolf in the issue looks like a ready alternative if it's as low-modified as it's marketing makes it out to be
2021-10-07 08:03:53 <psykose> i wonder, does it break the firefox licence to have a `firefox` package that is just a virtual that pulls in a differently-named branding-removed fork
2021-10-07 08:09:38 <linearcannon_> i'm not sure if it technically violates the license, but that is precisely what netbsd does
2021-10-07 08:20:22 <PJ[m]> inb4 `firefoxium`
2021-10-07 08:21:26 <omni> or "firefox" would be a meta package for librewolf?
2021-10-07 08:21:44 <psykose> that's what i meant yeah
2021-10-07 08:21:47 <omni> ah, someone already said
2021-10-07 08:21:58 <omni> yeah
2021-10-07 08:23:12 <omni> sorry, I'm awfully tired
2021-10-07 08:23:24 <psykose> nothing to apologise for :)
2021-10-07 08:23:39 <psykose> i am also quite empty on any meaningful energy
2021-10-07 08:25:20 <mps> alpine is trying to introduce least changes to upstream software
2021-10-07 08:25:53 <mps> I don't see serious reason to change firefox
2021-10-07 08:26:33 <mps> yes, advertising is bad (and I hate it) but it is everywhere anyway
2021-10-07 08:27:23 <omni> hah
2021-10-07 08:45:18 <linearcannon> from my perspective, at this point, the official version of firefox has become adware, and i do not think that it is appropriate for a linux distribution to distribute adware
2021-10-07 08:46:19 <linearcannon> spyware, as well, i think applies here
2021-10-07 08:50:05 <psykose> i didn't check too deeply, but librewolf looks to be a minimally adjusted to upstream version, <https://gitlab.com/librewolf-community/browser/common> this is a pretty minimal set of patches
2021-10-07 08:50:19 <psykose> if the goal is to 'purge the adware in its entirety' then most of this would be just be copied anyway
2021-10-07 08:51:40 <mps> linearcannon: then we have to remove FF (and not ff) from alpine
2021-10-07 08:52:08 <mps> and not only ff*
2021-10-07 08:53:50 <Ariadne> if you know of other software in alpine cramming ads in people's faces, do feel free to remove it
2021-10-07 08:53:52 <Ariadne> :P
2021-10-07 08:54:32 <Ariadne> and, my proposal would be to switch to something like librewolf, yes
2021-10-07 08:56:05 <Ariadne> mps: i think alpine tries to introduce least changes to upstream software as long as upstream software is respecting the user
2021-10-07 08:56:23 <Ariadne> if upstream software stops respecting the user, then i think we are obligated to correct the defect
2021-10-07 08:56:38 <Ariadne> be that through fixing firefox, or shipping a fork which has already fixed firefox
2021-10-07 08:57:28 <Ariadne> we assume a social contract where upstream has the same interests at heart for the user as we do
2021-10-07 08:57:51 <Ariadne> if mozilla wishes to introduce advertising into its address bar, that is a violation of said social contract imo
2021-10-07 09:07:40 <mps> hmm, looks like we are in yet another philosophical tread
2021-10-07 09:09:28 <mps> 'we' is so amorphous entity so when I say we (alpine devs and contributors) I most of time put we in apostrophes, i.e. 'we'
2021-10-07 09:12:44 <mps> and I hope 'we' will preserve non corporate mindset
2021-10-07 09:36:03 <PJ[m]> if I were a user and I've installed Firefox but I don't get the same Firefox that is distributed on other platforms, I would be pretty pissed
2021-10-07 09:47:56 <wyk72> I have a question about Alpine in diskless mode: where can I set the kernel-line parameters for the bootloader (legacy/csm-uefi?) ? Do I have to run update-kernel script ? I'm trying to decode the mkinitfs scripts but it seems they rely in a lot of arbitrary decisions that are not very clear to me
2021-10-07 09:49:25 <wyk72> when I run the update-kernel script I get the /boot dir in the dir /media/usb, maybe I should modify bootloaders configs in there (grub.conf, extlinux.conf) ?
2021-10-07 09:49:49 <wyk72> there is a "standard" way of doign this or should I do it manually?
2021-10-07 09:50:44 <ncopa> which bootloader are you using?
2021-10-07 09:51:54 <ncopa> i think it might be enough to edit /media/usb/boot/syslinux/syslinux.conf (or wherever it was located) i dont think update-kernel edit that?
2021-10-07 09:52:20 <wyk72> both..sometimes the legacy boot loader, sometimes the UEFI/grub one
2021-10-07 09:52:41 <wyk72> update-kernel creates the /boot dir in /media/usb
2021-10-07 09:52:55 <ncopa> i dont think update-kernel modifies the bootloader config?
2021-10-07 09:53:02 <wyk72> it's the standard /boot from the ISO I guess
2021-10-07 09:53:30 <wyk72> the update-kernel script does not modify the bootloader config
2021-10-07 09:53:52 <ncopa> so i think it should be enough to manually edit the boot config of you boot media
2021-10-07 09:53:54 <wyk72> afaik it can add  packages and mkinitfs features
2021-10-07 09:53:57 <wyk72> ok
2021-10-07 09:54:24 <wyk72> it's read-only: there is a standard way to edit it ?
2021-10-07 09:54:36 <wyk72> or should I mount it rw ?
2021-10-07 09:56:07 <ncopa> yes, remount rw before edit, and remount ro when done
2021-10-07 09:56:14 <ncopa> or reboot
2021-10-07 09:56:41 <wyk72> ok trying
2021-10-07 09:56:52 <ncopa> Misthios: how did it go with llvm12?
2021-10-07 09:57:58 <Misthios> i should be nearly done, just some weird failures(postgres on s390x due to jit, firefox on x86_64) and some smaller ones + armhf hits the 10h timeout, aarch64 and arm7 have logs which are to big so gotta figure out which failed there
2021-10-07 09:59:54 <ncopa> ok good
2021-10-07 10:01:17 <Misthios> do u have a quick way to see which package depends on what?
2021-10-07 10:02:02 <mps> Misthios: install atools and run 'ap revdep pkg-dev' in dirs
2021-10-07 10:02:22 <mps> dirs are main community and testing
2021-10-07 10:03:23 <mps> oh not atools but lua-aports
2021-10-07 10:04:31 <Misthios> ty
2021-10-07 10:09:00 <wyk72> I can confirm that editing the  /media/usb/boot/grub/grub.cfg file manually (after running the update-kernel script) works for diskless operations on a "standard" usb key made with the setup-bootable script
2021-10-07 10:09:54 <wyk72> maybe it should be written somewhere (wiki?)
2021-10-07 10:26:01 <Ariadne> mps: no specific meaning for 'we'
2021-10-07 10:27:02 <Ariadne> speaking solely as package maintainers
2021-10-07 10:27:53 <Ariadne> i think that alpine as a project would historically view the presence of adware functionality as a bug and seek to remove or replace the defective software with software lacking that defect
2021-10-07 10:28:14 <ikke> Nod, same thing with telemetry
2021-10-07 10:29:08 <Ariadne> admittedly, we have never actually been presented with this scenario before, where a software has slowly evolved into becoming adware
2021-10-07 10:29:43 <Ariadne> probably because, you know, until now, nobody has actually thought that was a good idea
2021-10-07 10:29:52 <mps> I agree that 'we' should try but I don't see this as obligatory
2021-10-07 10:30:22 <Ariadne> well it isn't obligatory, in that, we could just drop the defective package entirely
2021-10-07 10:30:32 <mps> ofc, if 'we' have enough time, resources and someone will work on this
2021-10-07 10:30:42 <Ariadne> nor is there an explicit policy against adware in alpine
2021-10-07 10:31:27 <Ariadne> this of course being a scenario which nobody was thinking about until mozilla started pushing the needle further and further
2021-10-07 10:31:32 <mps> 'we' do what we can /o\
2021-10-07 10:31:53 <ikke> Yes, including making suggestions on what approach we can take
2021-10-07 10:32:28 <mps> I only wanted to say that 'we' don't have any 'obligation' for users (I'm user also)
2021-10-07 10:33:02 <Ariadne> well, yes, thats implied, "as is, with no warranty" etc
2021-10-07 10:33:41 <Ariadne> but i think alpine does not ship adware, or at least, not adware that is that aggressive
2021-10-07 10:33:56 <Ariadne> i don't care about sponsored tiles so much
2021-10-07 10:34:07 <mps> we shouldn't, I agree
2021-10-07 10:34:14 <jvoisin> it would be nice to still use firefox' upstream code, instead of depending on librewolf
2021-10-07 10:34:14 <Ariadne> this address bar advertising stuff isn't ok tho
2021-10-07 10:34:40 <Ariadne> jvoisin: yes, i am thinking maybe make a deal with debian or so to bring back iceweasel
2021-10-07 10:35:08 <Ariadne> i am pretty sure debian will be on board to patch out the adware functionality, for the same reasons
2021-10-07 10:36:06 <jvoisin> Debian has a social contract <3
2021-10-07 10:36:43 <mps> jvoisin: and a lot of 'resources'
2021-10-07 10:36:51 <jvoisin> yup
2021-10-07 10:38:41 <mps> for me personally is better to have FF even with this adware then not have FF at all
2021-10-07 10:39:15 <mps> ofc, will be nice if someone remove it somehow
2021-10-07 10:55:03 <PureTryOut> If a decision is made on the future of FF in Alpine, please notify the postmarketOS team about it as we ship it by default in most our images but with a custom config applied to make it more feasible on mobile. FF being dropped for an alternative would probably be fine for us, but we would need to adapt to it
2021-10-07 10:55:35 <ikke> PureTryOut: Make sure to subscribe to the ticket :-)
2021-10-07 10:55:42 <PureTryOut> Sorry, what ticket?
2021-10-07 10:55:53 <PureTryOut> (I'm just reading a small bit of backlog here, haven't seen a ticket yet)
2021-10-07 10:56:09 <PureTryOut> Ah https://gitlab.alpinelinux.org/alpine/aports/-/issues/13068?
2021-10-07 10:56:23 <ikke> Yes
2021-10-07 10:56:34 <PureTryOut> Cool thanks
2021-10-07 11:02:50 <Ariadne> PureTryOut: actually, the pmOS side of things might be nice to comment here
2021-10-07 11:03:10 <Ariadne> PureTryOut: since you guys have experience tweaking FF already, maybe you know how hard it would be to nuke the adware
2021-10-07 11:03:26 <Ariadne> i think we all agree the adware should go
2021-10-07 11:03:28 <Ariadne> :)
2021-10-07 11:03:42 <PureTryOut> Yeah I shared it with our other devs. iirc initial work was done by ollieparanoid so he'll know best
2021-10-07 11:03:49 <PureTryOut> and yeah we agree there 😉
2021-10-07 11:18:22 <wyk72> syslinux on latest alpine (3.14.2) on x86 platform segfaults when writing to USB
2021-10-07 11:18:39 <wyk72> x86_64 works as expected
2021-10-07 11:18:47 <wyk72> x86 segfaults
2021-10-07 11:21:32 <Ariadne> ah
2021-10-07 11:45:20 <ncopa> ikke: i was a bit stupid and pushed stuff to abuild, now there is a conflict for https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/120
2021-10-07 11:45:31 <ncopa> i'd like to merge that sooner than later
2021-10-07 12:15:36 <ikke> ncopa: I'll look at it tonight 
2021-10-07 13:39:56 <Newbyte> sorry to bug you, but could someone merge !26209? it's a trivial change and it would unbreak some packages on edge (they currently cannot be installed)
2021-10-07 13:46:05 <mps> Newbyte: it still building on CI
2021-10-07 13:46:26 <psykose> .34 also just came out, you could give it a bump too :)
2021-10-07 13:46:40 <mps> ok, waiting for CI
2021-10-07 13:50:25 <Newbyte> builder shortage?
2021-10-07 13:51:43 <mps> busy, I think
2021-10-07 14:14:06 <ikke> We limit CI to 2 jobs per builder
2021-10-07 14:40:13 <donoban> I see that there is an openh264 package on testing, could the auto download&install in FF be disabled? There are also some telemetry, "portal detection" things on FF that I personally would prefer disabled
2021-10-07 14:41:05 <ikke> donoban: only if we use a none Firefox branded version 
2021-10-07 14:41:26 <donoban> ahh, I understand
2021-10-07 14:41:28 <ikke> There is a issue  about that 
2021-10-07 14:41:58 <ikke> #13868
2021-10-07 14:42:23 <ikke> 
ACTION pokes algitbot

2021-10-07 14:42:52 <donoban> hehe
2021-10-07 14:44:53 <donoban> #13068
2021-10-07 14:45:09 <ikke> Ah, thanks 
2021-10-07 14:52:19 <ncopa> shipping a policy.json sounds like a great idea - specially if we can keep the Firefox branding
2021-10-07 14:52:46 <jvoisin> ^yes
2021-10-07 14:53:13 <donoban> yeah
2021-10-07 15:02:44 <ncopa> looks like there are a number of packages that needs to be rebuilt with the updated libprotobuf: apk list --depends so:libprotobuf.so.26
2021-10-07 15:04:59 <PureTryOut> Yup...
2021-10-07 15:10:55 <mps> not much, I tested pdns and android-tools, they work without rebuilding
2021-10-07 15:11:27 <PureTryOut> android-tools definitely needed rebuild, you can't install it without it
2021-10-07 15:11:45 <mps> but maybe it would not hurt to rebuild all
2021-10-07 15:12:25 <mps> ahm I had it installed, because that it works, but pdns is installed and worked fine
2021-10-07 15:13:00 <PureTryOut> You either had it installed before the upgrade and haven't gotten the upgraded protobuf yet, or you got the just rebuilt version
2021-10-07 15:13:03 <PureTryOut> (of android-tools)
2021-10-07 15:13:38 <mps> no, I had it installed, and upgraded protobuf
2021-10-07 15:13:39 <ncopa> the proper way is to list the packages depending on the old package's provides
2021-10-07 15:13:45 <ncopa> apk list --depends so:libprotobuf.so.26
2021-10-07 15:14:04 <ncopa> i'm rebuilding them here now
2021-10-07 15:14:08 <PureTryOut> mps: idk what to tell you, I definitely couldn't install it and our CI on pmOS failed on it
2021-10-07 15:14:51 <mps> PureTryOut: I don't say it is not true, just say what I had
2021-10-07 15:25:30 <ikke> ncopa: rebased
2021-10-07 15:42:37 <ncopa> ikke: awesome! thanks!
2021-10-07 15:48:48 <ncopa> libarcus does not build with the updated protobuf
2021-10-07 15:55:08 <dalias> lovely
2021-10-07 15:55:34 <dalias> (does this mean alpine is packaging cura now??)
2021-10-07 15:55:38 <PureTryOut> This really should have been found in the MR that bumped protobuf...
2021-10-07 15:55:55 <dalias> yes..
2021-10-07 15:55:59 <ncopa> dalias: apparently. its in testing
2021-10-07 15:56:12 <dalias> libs with unstable api/abi really need testing of all deps before an upgrade merge is allowed
2021-10-07 15:57:36 <ncopa> ideally yes
2021-10-07 16:00:11 <dalias> btw i build cura without arcus :)
2021-10-07 16:00:17 <dalias> but i dont know if that works if you want the gui
2021-10-07 16:03:46 <ncopa> I have reported it upstream. https://github.com/Ultimaker/libArcus/issues/125 my time is up now.
2021-10-07 16:04:10 <ikke> o/
2021-10-07 16:05:07 <mps> testing all dependent would take a lot time, look at current icu status
2021-10-07 16:14:06 <dalias> :-p
2021-10-07 16:14:11 <dalias> does icu break api/abi tho?
2021-10-07 16:33:14 <andypost[m]> dalias: yes, breaks and a lot https://abi-laboratory.pro/index.php?view=timeline&l=icu4c
2021-10-07 16:39:11 <Hello71> dalias: icu bumps soname for every release
2021-10-07 16:40:04 <Hello71> and it is by far the most annoying soname bump for every linux distro, because every bloated crap depends on it and needs rebuild
2021-10-07 16:42:42 <Hello71> you get to recompile firefox (x3+), chromium (x2+), libreoffice, postgres, nodejs, php, qt...
2021-10-07 16:48:05 <dalias> :/
2021-10-07 16:48:22 <dalias> is there any reason to follow releases?
2021-10-07 16:50:11 <ericonr> Firefox and chromium require latest ICU now
2021-10-07 16:52:23 <dalias> uhg why
2021-10-07 16:52:29 <dalias> why do they even use icu at all?
2021-10-07 16:52:52 <dalias> i would expect them to have their own differently-hideous unicode implementations
2021-10-07 16:58:51 <Hello71> they conveniently bundle copies so you can inflate your disk space by an additional 35 MB
2021-10-07 16:59:25 <Hello71> so they do use their own implementations, just in the worst way
2021-10-07 16:59:26 <dalias> :-p
2021-10-07 16:59:47 <mps> hm, only zathura-pdf-mupdf depends on mupdf, maybe we should remove both from alpine
2021-10-07 16:59:53 <dalias> tbf using the embedded one sounds less awful if the system one keeps getting version skew breakage
2021-10-07 17:00:10 <Hello71> mps: mupdf is arguably the least worst pdf renderer atm
2021-10-07 17:00:27 <Hello71> pdf.js is more secure, but then, like, js
2021-10-07 17:00:48 <mps> Hello71: yes, but mupdf is mess to keep
2021-10-07 17:00:50 <Hello71> poppler is so slow and doesn't even do a good job
2021-10-07 17:01:06 <mps> always need tweaks when upgrading
2021-10-07 17:01:09 <dalias> which does evince work? it's the only decently-behaved app i've found
2021-10-07 17:01:14 <mps> and patches
2021-10-07 17:01:18 <dalias> s/work/use/
2021-10-07 17:01:42 <mps> dalias: zathura have vi like ui
2021-10-07 17:01:51 <Hello71> dalias: poppler, and yes, evince is one of the less bad wrappers. it's good that it supports forms which most others don't
2021-10-07 17:03:19 <mps> right now working on mupdf upgrade and it makes me somewhat 'nervous'
2021-10-07 17:03:43 <nmeum> I use mupdf daily, I can also do the upgrade for you if you don't want to do it :p
2021-10-07 17:04:07 <Hello71> i think mupdf is ok to maintain if you take the easy way out of using all the bundled libraries
2021-10-07 17:05:28 <mps> nmeum: np if you want but I'm nearly finished. I had to go out and probably could finish later this night. but again do what you like
2021-10-07 17:07:03 <nmeum> nah, no need to do the work twice just offering my help because you suggested removing mupdf entirely
2021-10-07 17:07:57 <mps> that was 'joke' from losing nerves because I made mistake in one patch
2021-10-07 17:08:50 <mps> I don't think seriously, I added zathura-pdf-mupdf to alpine because I find it as best pdf viewer
2021-10-07 17:09:16 <mps> combo - mupdf and zathura I mean
2021-10-07 17:10:30 <dalias> maybe controversial opinion: if software ships bundled libraries, unless there's a compelling reason not to use them, distros should
2021-10-07 17:10:55 <dalias> trying to make it use system ones requires a lot more maintainer labor and has more chance of breakage on upgrade
2021-10-07 17:11:33 <dalias> only benefit is unified security update channel, but you could manage that just about as easily just tracking what bundled libs & versions are in use
2021-10-07 17:15:15 <valerius> trading one problem for another
2021-10-07 17:15:26 <valerius> in cases of "forked vendored" you are already stuck with that though
2021-10-07 17:15:37 <nmeum> even if you track the bundled libraries you still need to patch every bundled library in every software which uses bundled libraries for security fixes and such and sometimes the patch may not apply cleanly due for different version of the bundeled library etc pp
2021-10-07 17:16:07 <dalias> btw distros should be aware of: https://twitter.com/ladyaeva/status/1445834339917320194
2021-10-07 17:16:18 <nmeum> https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/
2021-10-07 17:16:49 <dalias> the firefox abuild should probably have some mechanism to watch for new phone-home junk and error out until it's patched out
2021-10-07 17:18:54 <ddevault> I think it's notable to mention that every time I install firefox on a new machine I spend 10 to 15 minutes turning off shit in the preferences and about:config
2021-10-07 17:19:01 <ddevault> this is not a good experience
2021-10-07 17:19:31 <valerius> increasingly, people are dissatisfied with the available browser options
2021-10-07 17:19:32 <ddevault> we shouldn't let software in aports spy on or advertise to our users
2021-10-07 17:19:35 <eris[m]> why, this is what nixos solves!
2021-10-07 17:19:35 <eris[m]> :^)
2021-10-07 17:19:46 <ikke> dalias: #13068
2021-10-07 17:20:11 <dalias> drop branding? no. patch out malicious stuff. yes
2021-10-07 17:20:28 <ikke> dalias: you are not allowed to ship it as firefox if you patch it
2021-10-07 17:21:05 <ikke> https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/
2021-10-07 17:21:33 <ikke> dalias: so if you want to patch out these things, you have to call it somethign different
2021-10-07 17:26:08 <dalias> no you don't
2021-10-07 17:26:17 <dalias> you don't actually have to follow that
2021-10-07 17:28:21 <dalias> you do need to follow the spirit, i.e. not bundling malware or doing other sketchy stuff
2021-10-07 17:28:40 <dalias> but you do not need to refrain from protecting your users from mozilla's malicious behaviors
2021-10-07 17:30:02 <dalias> are other distros shipping firefox with malware features??
2021-10-07 17:30:10 <ikke> Well, the explicitly mention not changing defaults for example
2021-10-07 17:30:14 <ikke> they*
2021-10-07 17:30:18 <valerius> how long until enough of us get frustrated enough to fork and actually actively develop a new browser?
2021-10-07 17:30:27 <dalias> yes that's CYA because the most common changes to default prefs would be to do malicious things
2021-10-07 17:30:33 <dalias> rather than protect user from malicious things
2021-10-07 17:30:47 <dalias> i do not want anyone to fork
2021-10-07 17:30:54 <dalias> i want folks to FIGHT MOZILLA on this shit
2021-10-07 17:30:58 <dalias> until they have to stand down
2021-10-07 17:31:09 <ddevault> moving to a fork is one way to fight mozilla
2021-10-07 17:31:13 <ddevault> this is hardly the first of their transgressions
2021-10-07 17:31:21 <Hello71> mozilla already sent lawyers after debian
2021-10-07 17:31:24 <valerius> I think when organizations go down this road they don't turn back
2021-10-07 17:31:26 <dalias> fight means refuse to stop using their trademark and make them be the bad guys
2021-10-07 17:31:27 <ddevault> I consider them a hostile upstream at this point
2021-10-07 17:31:35 <Hello71> they eventually backed down, but the tide seems to be turning back
2021-10-07 17:31:41 <ddevault> again: you ponying up for the lawyers?
2021-10-07 17:31:44 <ddevault> look at mozilla's behavior
2021-10-07 17:31:50 <ddevault> they haven't been the good guys for a looooong time
2021-10-07 17:31:52 <dalias> ddevault, i will organize getting lawyers if it's a problem
2021-10-07 17:31:58 <ddevault> can we have that in writing?
2021-10-07 17:32:44 <Hello71> and also proof of your enormous trust fund to pay for all those lawyers...
2021-10-07 17:33:56 <dalias> you're acting like this is google not mozilla
2021-10-07 17:34:17 <dalias> mozilla is not going to get away with trying to destroy a foss org over patching out their malware
2021-10-07 17:34:30 <dalias> if they even try there will be an abundance of pro bono
2021-10-07 17:34:44 <Hello71> people would have said that about putting ads in firefox a week ago, yet here we are
2021-10-07 17:35:04 <dalias> they won't get away with that either
2021-10-07 17:35:10 <dalias> they'll be forced to take them out upstream too
2021-10-07 17:35:27 <dalias> but we can be part of making that happen or part of caving
2021-10-07 17:35:38 <Hello71> i am hopeful but not optimistic
2021-10-07 17:35:58 <dalias> note also:
2021-10-07 17:36:04 <dalias> this feature is only in US firefox!!
2021-10-07 17:36:08 <dalias> because it's not GDPR compliant
2021-10-07 17:36:19 <dalias> if we are building and shipping an international one we're already matching their defaults
2021-10-07 17:36:23 <Hello71> why can't fedora do it first
2021-10-07 17:36:28 <Hello71> they have actual lawyers and big ibm money
2021-10-07 17:36:44 <dalias> does fedora even ship their own firefox?
2021-10-07 17:36:50 <dalias> i thought they just downloaded mozilla's binaries
2021-10-07 17:37:12 <Hello71> yes, there was a big dispute a couple years ago about using gcc vs clang
2021-10-07 17:37:17 <dalias> debian was the outlier who insisted on actually shipping binaries they control
2021-10-07 17:37:33 <dalias> anyway look at what the non-US build does
2021-10-07 17:37:38 <ddevault> you're crazy, dalias 
2021-10-07 17:37:44 <dalias> and make sure alpine is shipping a non-US build
2021-10-07 17:37:47 <ddevault> this is not the first time firefox has added ads to the browser
2021-10-07 17:37:50 <ddevault> this is just the latest time
2021-10-07 17:38:04 <ddevault> they have also done things like sending the user's complete browsing history to third-party companies for ads and analytics
2021-10-07 17:38:17 <ddevault> and they have been on a trend of firing engineers and increasing C-level salaries for years
2021-10-07 17:38:23 <ddevault> there are no lows to which I don't think mozilla will stoop at this point
2021-10-07 17:38:34 <ddevault> protecting their trademark is the obvious thing for them to do right now
2021-10-07 17:38:51 <dalias> anyway it's a non-issue because you can disable this just by shipping the non-US config
2021-10-07 17:39:01 <dalias> it's documented on their website that only the US version does this
2021-10-07 17:39:10 <dalias> (they don't say, but the reason is because GDPR :-p)
2021-10-07 17:39:15 <ddevault> do you want to put their feet to the fire or not
2021-10-07 17:39:38 <ddevault> what it seems like the only thing you want to do is not stop shipping firefox upstream in some form or another, and are coming up with contradictory reasons to justify it
2021-10-07 17:39:48 <dalias> anybody shipping their US defaults in a EU setting would be in violation of GDPR
2021-10-07 17:40:00 <ddevault> that fact alone is reason enough to distrust them
2021-10-07 17:40:13 <dalias> no i'm coming up with strategies to fight for the ability to
2021-10-07 17:40:31 <dalias> and "these are your defaults -- just not the US ones"
2021-10-07 17:40:36 <dalias> is such a strategy
2021-10-07 17:40:40 <PJ[m]> dalias is actually right, the config is not present at all
2021-10-07 17:40:51 <PJ[m]> you can't even enable it because that option is missing
2021-10-07 17:40:55 <ddevault> firefox /already/ ships with ads in alpine
2021-10-07 17:41:04 <dalias> ddevault, not ads that sniff your keystrokes
2021-10-07 17:41:08 <ddevault> ads nevertheless
2021-10-07 17:41:11 <ddevault> something we should be patching out
2021-10-07 17:41:15 <dalias> those should be disabled too
2021-10-07 17:41:21 <dalias> i want alpine to go further on this
2021-10-07 17:41:32 <ddevault> yeah, like switching to a fork or changing the branding
2021-10-07 17:41:36 <dalias> no
2021-10-07 17:41:47 <dalias> i am strongly against changing the branding
2021-10-07 17:41:50 <ddevault> this is not the only time it has been worth doing, but this is a good time to do it, because the public is against mozilla right now
2021-10-07 17:42:08 <dalias> it's caving and puts you in a worse position to make change
2021-10-07 17:42:16 <dalias> and makes you a laughing stock like iceweasel era
2021-10-07 17:42:39 <ddevault> iceweasel was pretty stupid on its own rights
2021-10-07 17:42:46 <ddevault> looked like FSF spastic shit and had terrible branding
2021-10-07 17:42:50 <ddevault> librefox is better in these regards
2021-10-07 17:42:57 <ddevault> but, I do like your idea, to be clear
2021-10-07 17:43:06 <ddevault> it just has risks and I don't see it as being much better than a fork
2021-10-07 17:43:20 <dalias> there are LOTS of levels of escalation involved between starting my idea and "zomg we owe lawyers $1B!"
2021-10-07 17:43:27 <ddevault> and debian was patching it for silly things, too
2021-10-07 17:43:44 <ddevault> it's a hell of a lot more reasonable if alpine says "we rebranded it because mozilla trademark policy prevents us from removing ads and spyware from the product"
2021-10-07 17:44:06 <ddevault> well, I also think it would go fine
2021-10-07 17:44:17 <ddevault> but I acknowledge the risk of it not going fine, and that's a risk that a fork does not have
2021-10-07 17:44:37 <dalias> i dont think there's any significant risk at the first few stages
2021-10-07 17:44:51 <dalias> it starts with nastygram only
2021-10-07 17:44:56 <ddevault> well, I think you're right
2021-10-07 17:44:59 <dalias> then public reaction to nastygram
2021-10-07 17:45:01 <ddevault> why don't we meet in the middle
2021-10-07 17:45:08 <ddevault> patch firefox without rebranding, but also package librewolf
2021-10-07 17:45:12 <dalias> then a few levels of back and forth, orange site, etc. over that
2021-10-07 17:45:29 <dalias> *sigh* librewolf sounds dumb
2021-10-07 17:45:41 <dalias> almos as bad as iceweasel
2021-10-07 17:45:44 <ddevault> are you saying we shouldn't package some useful software just because it sounds dumb
2021-10-07 17:45:58 <dalias> no, i thought that was your name for a new fork
2021-10-07 17:45:59 <ddevault> I have a hell of a lot of other projects on that list, we'd better start culling aports
2021-10-07 17:46:04 <dalias> is it something that already exists?
2021-10-07 17:46:04 <ddevault> https://librewolf-community.gitlab.io/
2021-10-07 17:46:07 <PJ[m]> Patching things out AND providing an alternative is not so bad idea
2021-10-07 17:46:36 <ikke> PJ[m]: we do not want to maintain 2 seperate firefox distributions
2021-10-07 17:46:39 <dalias> ok so i misunderstood. sorry
2021-10-07 17:46:50 <dalias> but yeah i think it's a lot of work to maintain two
2021-10-07 17:46:50 <ddevault> why not? the packaging is very similar
2021-10-07 17:47:10 <PJ[m]> ikke, I'm aware
2021-10-07 17:47:14 <dalias> and i don't want 'well we have librewolf' to be a gateway to 'removing firefox is nbd'
2021-10-07 17:47:18 <ddevault> and firefox is already in community anyway
2021-10-07 17:47:54 <ddevault> if we have a maintainer willing to take on the responsibility for it, that's justification enough
2021-10-07 17:48:21 <ikke> We have not at the moment
2021-10-07 17:48:23 <PJ[m]> Was about to say, if there is someone that has sheer will of not using firefox, they could maintain another one
2021-10-07 17:48:48 <nmeum> we are already packaging two firefox "flavours" already: firefox and firefox-lts and we are barely able to keep those up to date, case in point: community/firefox is currently not up to date
2021-10-07 17:48:50 <PJ[m]> ddevault: you sounded like you would like to do that :P
2021-10-07 17:48:58 <ddevault> I'm not saying no, but also not saying yess
2021-10-07 17:48:58 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13068#note_184115
2021-10-07 17:49:04 <ddevault> yes*
2021-10-07 17:49:30 <ddevault> I'd like to explore the feasibility of this approach as a kind of hedging our bets
2021-10-07 17:49:49 <ddevault> if we want to take the risk of snubbing mozilla and shipping packages in violation of their trademarks (which is illegal!)
2021-10-07 17:50:08 <ddevault> then we should be prepared to respond reasonably quickly if they start to take legal action
2021-10-07 17:50:18 <ddevault> or we could just not take the risk and switch
2021-10-07 17:50:24 <PJ[m]> Personally I would like the original FF to not be dropped or patched to so massive lengths that it's completely different since that impacts UX
2021-10-07 17:50:25 <ddevault> or we could just not take the risk, and switch *
2021-10-07 17:50:44 <dalias> it's not in violation of their trademarks
2021-10-07 17:50:46 <ddevault> librewolf does not patch it to any extent which affects the user experience
2021-10-07 17:50:56 <ddevault> have you read the trademark policy, dalias?
2021-10-07 17:51:14 <ddevault> https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/
2021-10-07 17:51:18 <dalias> yes i just did
2021-10-07 17:51:22 <PJ[m]> I think in case of the address bar advertisements they can't say anything since as distro maintainers you are responsible for reasonable config and the fact that Alpine is used globally
2021-10-07 17:51:24 <ikke> "You may not add to, remove, or change any part of the software, including the Mozilla trademarks themselves."
2021-10-07 17:51:26 <ddevault> >You may not add to, remove, or change any part of the software, including the Mozilla trademarks themselves. For example, you may not add any extensions to Firefox, change default settings, or alter search codes.
2021-10-07 17:51:57 <PJ[m]> right, ddevault, but if you ship default FF with ads then that violates GDPR
2021-10-07 17:52:13 <ddevault> the conclusion is that we cannot legally ship firefox
2021-10-07 17:52:18 <dalias> not even mozilla's source they distribute does that
2021-10-07 17:52:18 <ddevault> not that it's less illegal to violate the trademark
2021-10-07 17:52:28 <PJ[m]> I don't think that Mozilla would also want to have legal on their neck
2021-10-07 17:52:34 <dalias> it's only some US-only build configuration they use for their US binaries that has the keysniffing ads
2021-10-07 17:52:39 <ddevault> if you want to make the GDPR argument
2021-10-07 17:52:47 <ddevault> you should file a complaint with your EU representative
2021-10-07 17:52:58 <PJ[m]> Why?
2021-10-07 17:53:02 <ddevault> breaking a different law and appealing to the fact that they were already breaking this other law does not sound like a smart plan
2021-10-07 17:53:03 <PJ[m]> I don't see any violation
2021-10-07 17:53:04 <dalias> the EU version doesn't do that
2021-10-07 17:53:08 <dalias> only the US version does
2021-10-07 17:54:13 <ikke> How is it determined what version it is?
2021-10-07 17:54:16 <PJ[m]> going back to alternative FF, I won't mind bumping version and some small fixes/patches around build as much as my free time allows it
2021-10-07 17:54:39 <PJ[m]> ikke, country from which you connect (during download) most likely
2021-10-07 17:54:40 <dalias> ikke, the source just builds a standard international-safe version by default afaict
2021-10-07 17:54:47 <dalias> (no DOH by default, no trackers, etc.)
2021-10-07 17:55:17 <dalias> and yeah their download site just directs you to different localized versions based on your ip address & language settings
2021-10-07 17:56:18 <PJ[m]> in case of source build they definitely do it like Microsoft which means they have clean repo and lay config during release build
2021-10-07 18:29:05 <ddevault> is the TSC membership and bylaws written down anywhere
2021-10-07 18:31:21 <ikke> We're in the progress of doing that
2021-10-07 18:32:44 <minimal> ddevault: in addition to the policy.json I mentioned in the Issue ticket which controls global FF config, for individual users the users.js file inside each profile can also be customised in more ways. That's why there are projects that supply secure/privacy-oriented versions such as https://github.com/pyllyukko/user.js/
2021-10-07 18:33:49 <ddevault> if our package can modify user.js and policy.json to turn off everything we don't want, then that would be the lowest-risk, easiest approach
2021-10-07 18:34:14 <ddevault> but knowing mozilla, I think it's just a matter of time before that's not enough, if it even is now
2021-10-07 18:34:52 <ikke> And I wonder whether that counts as "changing defaults"
2021-10-07 18:35:53 <ddevault> it seems in contradiction that mozilla would provide a means of installing policies while simultaneously disallowing distributors from using it
2021-10-07 18:36:12 <ddevault> we could ask them to clarify but that could easily result in them closing the loophole instead of clarifying in our favor
2021-10-07 18:39:33 <minimal> PJ: GDPR does not prevent ads, it may have an effect on profiled-ads (depending on how the profiling is done)
2021-10-07 18:43:44 <PJ[m]> It does and it doesn't, GDPR requires for data collection to be absolutely clearly understandable by the user, it requires minimal data collected for the purpose of goal, users should be able to request that data for review and/or deletion at any time
2021-10-07 18:43:44 <minimal> ddevault: here's an idea, as their distribution policy does not allow defaults to be changed, what is there was a separate optional (i.e. Firefox did NOT depend on it) Alpine package, e.g. "firefox-reduced-config" that contained tailored policy.json and user.js (maybe with some sort of trigger to copy the user.js into place whenever a new Firefox user profile is created). Wonder if that would fly?
2021-10-07 18:43:59 <ddevault> NACK
2021-10-07 18:44:15 <ddevault> we should not require the user to take additional actions that they may or may not be informed about to avoid installing adware or spyware
2021-10-07 18:44:26 <ddevault> we simply should not distribute spyware or adware
2021-10-07 18:44:38 <PJ[m]> I'd say, look at what other distros do
2021-10-07 18:46:20 <minimal> PJ: an example that I was thinking of - if for example a webforum for Linux users shows ads for Alpine for example where the ads is not selected on criteria dependant on th user (i.e. IP address, browser user-agent, etc) then there's no personal data processing and therefore no issue with GDPR
2021-10-07 18:47:32 <minimal> from a brief look at icewolf earlier they seem to use a policy.json file
2021-10-07 18:47:50 <PJ[m]> right, but for some reason US has that option and EU doesn't
2021-10-07 18:50:32 <minimal> PJ: if their download is serving different software/settings based on IP that's a whole different kettle of fish - I've working in worldwide orgs where traffic in a EU office destined for a US-based website exited the corporate network in the US and so the end-site was a UK IP address, not a EU one. GDPR doesn't care if you "think" someone is/is not in the EU, its based on where the person actually is.
2021-10-07 18:50:49 <minimal> s/UK/USA/g
2021-10-07 18:55:08 <minimal> ddevault: do you consider the "Safe Browsing" functionality present in most browsers to be spyware? Firefox, Chrome (and I assume Chromium), and I think Safari amongst other all have it - the Safe Browsing "database" is run by Google and they query out to it before going to URLs. How from memory the actual URL is not sent to Google, there's some sort of hashing going on
2021-10-07 18:56:46 <ddevault> yes, I consider that a problem
2021-10-07 18:56:53 <ddevault> I've disabled it in my firefox settings
2021-10-07 18:57:42 <Ariadne> i mean, worst case
2021-10-07 18:57:48 <Ariadne> if a mozilla lawyer shows up
2021-10-07 18:57:52 <Ariadne> we just disable the branding
2021-10-07 18:58:04 <Ariadne> by removing `--enable-official-branding` from mozconfig, no?
2021-10-07 18:58:29 <PJ[m]> does that change functionality?
2021-10-07 19:04:32 <ikke> Writeup about the debian history around iceweasel https://lwn.net/Articles/676799/
2021-10-07 19:07:01 <dalias> minimal, re: their way of figuring out whether to give you the malware-laden US version, yes it's utter BS. they'd have to *ask you* which you want, and warn you that the US one has tracking that's illegal in the EU :-p
2021-10-07 19:07:32 <dalias> but of course they won't do that because it would be horribly embarrassing
2021-10-07 19:10:08 <minimal> dalias: well I was making a point about orgs in general thinking they can lookup your location from IP address and decide based on that whether GDPR impacts on what they want to do, which, especially in this age of VPNs, is a fallacy
2021-10-07 19:10:28 <dalias> *nod*
2021-10-07 19:10:58 <dalias> basically unless you have no presence in the EU and never intend to set foot in the EU, you must assume GDPR applies to all users/visitors
2021-10-07 19:11:30 <ddevault> any organization which decides how much spyware to ship based on whether or not the user lives somewhere that hasn't outlawed it yet
2021-10-07 19:11:33 <ddevault> is not an organization I trust
2021-10-07 19:11:42 <dalias> :-p
2021-10-07 19:11:42 <minimal> I've taken action again several orgs regarding failures to comply with GDPR (and previous laws) and its slow going and, with a reluctant/uncaring/incompetant regulator its now very effective :-(
2021-10-07 19:11:52 <minimal> s/now/not/
2021-10-07 19:11:52 <dalias> :/
2021-10-07 19:12:24 <dalias> GDPR should have specified the mandatory huge fines for regulators who refuse to take violations seriously
2021-10-07 19:12:38 <minimal> dalias: don't forget the UK - there is now the UK-GDPR in addition to the (EU)GDPR
2021-10-07 19:13:17 <dalias> :-p
2021-10-07 19:15:33 <minimal> dalias: I'm now 7 months into a privacy case (multiple GDPR compliance failures in health sector) I raised with the regulator and they only just wrote to the org in question 2 weeks ago...
2021-10-07 19:16:17 <ikke> https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-346372756 Someone from mozilla commenting on NixOS build: "Therefor, as long as you keep the patch queue sane and you don't alter the experience of Firefox users, you won't have any issues using the official branding."
2021-10-07 19:16:57 <minimal> ikke: I assume "experience" would cover config settings
2021-10-07 19:17:05 <ddevault> the LWN article brings up a good point about special treatment for Debian not being desirable
2021-10-07 19:17:06 <ikke> "To be clear, we expect the same level of quality for the patches and not making features changes.
2021-10-07 19:17:07 <ikke> Should be about portability and tiny changes."
2021-10-07 19:17:29 <ddevault> and I don't like offhand comments from mozilla employees in random forums contradicting written down official legal documents
2021-10-07 19:18:12 <PJ[m]> silly question but have anyone actually tried to build latest FF and see if it has those "features" or not :P 
2021-10-07 19:19:33 <ddevault> it's certainly not in the spirit of, and perhaps not even in the letter of, preventing someone from forking alpine linux without making their own separate legal agreement with mozilla
2021-10-07 19:19:46 <minimal> dalias: EDPB is central regulator for per-EU-country GDPR regulators........however once UK left the EU then the EDPB ceased to police the UK Information Commissioner's Office (ICO) :-(
2021-10-07 19:20:09 <ddevault> spirit/letter of free software*
2021-10-07 19:20:31 <Hello71> dalias: "Please accept cookies to use our site! [ACCEPT ALL] [manage]"
2021-10-07 19:21:17 <dalias> hello71, [manage] must set them all initially to no
2021-10-07 19:21:23 <dalias> and even then it might not suffice
2021-10-07 19:21:28 <dalias> there's currently a court case over this
2021-10-07 19:21:49 <dalias> i dont recall the name/venue/details
2021-10-07 19:22:03 <PJ[m]> *clicks manage*
2021-10-07 19:22:03 <PJ[m]> *in very tiny font size* [reject all]
2021-10-07 19:22:03 <PJ[m]> [Accept all] [Accept non-essential] [Leave unchanged]
2021-10-07 19:22:32 <minimal> dalias: the 1st problem is the all-caps for "ACCEPT ALL" (if that's how it actually appears - the "yes" and "no" options must appear the same (i.e. colour, fonts, etc) so no "dark patterns" to lead people to pick the option you want
2021-10-07 19:23:21 <PJ[m]> it is a must but reality looks different ;)
2021-10-07 19:23:54 <dalias> <ddevault> and I don't like offhand comments from mozilla employees in random forums contradicting written down official legal documents
2021-10-07 19:23:58 <dalias> be sure to archive them :)
2021-10-07 19:24:24 <ddevault> Ariadne: what does it change the name to?
2021-10-07 19:24:43 <Ariadne> i can check, it used to be "bon echo" or something
2021-10-07 19:25:02 <minimal> PJ: the ICO (UK body that enforces GDPR) has at least twice since GDPR came into effect been found to breach GDPR and had to take action - of of these was that their cookie handling was not compliant with the law (took at least 1 year for that to be highlighted)
2021-10-07 19:25:48 <ddevault> what an awful name
2021-10-07 19:25:59 <dalias> i think the argument should be established that they've let other distros make minor patches that are not about undermining the firefox brand but conforming to their own distro policies
2021-10-07 19:26:04 <ddevault> no worse than IceCat I guess
2021-10-07 19:26:12 <dalias> and this nullifies their ability to enforce trademark against others who do the same
2021-10-07 19:27:24 <dalias> and i think there should be an effort to engage with mozilla to figure out how they can improve their policy to prevent malware forks (which is what it's nominally about -- think fake downloads from sourceforge ads, play store, etc)
2021-10-07 19:27:46 <dalias> while not leading distros to believe they can't follow their own security and privacy policies
2021-10-07 19:28:22 <dalias> it might turn out they would be amenable to something like still having the binary name be firefox but the app title being "Alpine Firefox", "Debian Firefox", etc.
2021-10-07 19:29:11 <ddevault> that's a nice idea
2021-10-07 19:29:27 <dalias> but i really think they should just make it explicit that it's fine for linux distros to use the name as long as they're not bundling affiliate stuff, malware, etc. that would tarnish the brand
2021-10-07 19:29:31 <PJ[m]> one could write to their trademark something mail address and ask what does constitute a violation of their terms
2021-10-07 19:29:48 <ikke> 'Confusingly enough, the Community Edition rules would have allowed Debian to use the name "Firefox" but not to use the name "Mozilla Firefox" nor to use the Firefox logo. '
2021-10-07 19:30:19 <Ariadne> https://hg.mozilla.org/mozilla-central/raw-file/tip/browser/branding/unofficial/content/about.png
2021-10-07 19:30:25 <Ariadne> "Nightly"
2021-10-07 19:30:37 <dalias> ikke, "would have" ?
2021-10-07 19:30:42 <dalias> is this something that's gone?
2021-10-07 19:31:00 <Ariadne> yes
2021-10-07 19:31:17 <Ariadne> replaced by https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/
2021-10-07 19:31:19 <Ariadne> which says:
2021-10-07 19:31:36 <Ariadne> "You may not add to, remove, or change any part of the software, including the Mozilla trademarks themselves. For example, you may not add any extensions to Firefox, change default settings, or alter search codes."
2021-10-07 19:32:07 <ikke> Ariadne: wouldn't shipping a policy.json file mean 'change default settings'?
2021-10-07 19:32:29 <Ariadne> that is the basic question being discussed yes
2021-10-07 19:32:58 <ikke> Right, but I get the feeling it's being seen as an alternative to debranding + patching
2021-10-07 19:33:18 <minimal> ikke: that's why I wondered if a "trick" of shipping it in a seperate package would be in line with the word of the policy, if not in the spirit of it
2021-10-07 19:33:22 <Ariadne> if the policy file is separate like pmOS, i think it is "ok"
2021-10-07 19:33:40 <Ariadne> because they could just do `apk add !firefox-alpine-config`
2021-10-07 19:33:43 <Ariadne> to opt out
2021-10-07 19:34:16 <ericonr> > dalias: [...] that would tarnish the brand <-- the policy needs an item for distros cleaning up the brand :P
2021-10-07 19:34:39 <minimal> Ariadne: so you're thinking of a Depends being in place with such a package? I guessed that might be stretching things too far lol
2021-10-07 19:34:43 <Ariadne> yes, in this case we are removing functionality that is detrimental to the brand
2021-10-07 19:34:49 <Ariadne> minimal: no.  an `install_if`.
2021-10-07 19:35:05 <minimal> Ariadne: right, logically that's a dep
2021-10-07 19:35:35 <dalias> ericonr, well yes :-)
2021-10-07 19:35:39 <Ariadne> in practice, yes, but in legal sense, i do not think it is
2021-10-07 19:35:42 <dalias> but i'm trying to make it sound diplomatic
2021-10-07 19:35:51 <ikke> Ariadne: why would it make a difference?
2021-10-07 19:35:55 <Ariadne> it is just a package which happens to be selected by apk if you happen to request firefox
2021-10-07 19:36:16 <Ariadne> ikke: because you can opt-out by installing a conflicts on the package.  install_if is optional
2021-10-07 19:36:31 <minimal> Ariadne: and what about the idea of additionally copying per-profile user.js in place as well for the stuff policy.json can't handle?
2021-10-07 19:36:55 <dalias> i think that's a flaky way to fix it
2021-10-07 19:36:56 <Ariadne> that one i do not have an answer for
2021-10-07 19:37:03 <ikke> Like you can opt-out of cookies by removing them?
2021-10-07 19:37:12 <Ariadne> yes, exactly
2021-10-07 19:37:13 <dalias> btw non-joke solution:
2021-10-07 19:37:14 <Ariadne> GDPR logic
2021-10-07 19:37:15 <Ariadne> :)
2021-10-07 19:37:43 <dalias> /usr/bin/firefox is a script that runs a namespace with a nameserver where mozilla domains are blocked and DOH IPs are firewalled
2021-10-07 19:37:55 <ikke> "These cookies are optional, just remove them after you visited our site" :P
2021-10-07 19:38:30 <ikke> IANAL, but I wonder if that would hold
2021-10-07 19:38:37 <Ariadne> well, my point is, we could argue, plausibly, that `firefox` does *not* depend on `firefox-config-alpine`, if it is an `install_if`
2021-10-07 19:38:46 <ikke> technical trickery
2021-10-07 19:38:54 <ikke> it's a dependency, but set from the other side
2021-10-07 19:38:58 <dalias> :-p
2021-10-07 19:38:59 <minimal> Ariadne: "By continuing to use this package you agree to us scavenging through your hard disk"
2021-10-07 19:39:01 <Ariadne> technical trickery keeps the world moving
2021-10-07 19:39:05 <minimal> :-)
2021-10-07 19:39:13 <kunkku> the config package could have a different maintainer
2021-10-07 19:39:38 <Ariadne> exactly
2021-10-07 19:39:42 <dalias> i'd still strongly prefer to have the spyware compiled out, not just disabled via policy/prefs
2021-10-07 19:39:51 <dalias> so it can't inadvertently get activated
2021-10-07 19:40:13 <Ariadne> same, but i think that does get the lawyers to show up
2021-10-07 19:41:03 <Ariadne> and yes, i think their lawyers are stupid enough to actually raise a stink
2021-10-07 19:41:10 <dalias> i really think 'it's OS privacy and security policy' mostly shuts that up
2021-10-07 19:41:34 <Ariadne> i mean, this is the company that decided putting ads in the address bar is a good plan moving forward
2021-10-07 19:41:37 <ikke> btw, we're already patching firefox, so we would already fall under the 'portability and minor change patches' category
2021-10-07 19:41:47 <dalias> what ikke said
2021-10-07 19:41:56 <dalias> this was debian's original argument too
2021-10-07 19:42:01 <Ariadne> haha your adware is non-portable so we removed it
2021-10-07 19:42:03 <Ariadne> :D
2021-10-07 19:42:13 <ikke> dalias: Yes, but patching out functionality is another level
2021-10-07 19:42:16 <dalias> that they're not changing the product just making it follow OS policy
2021-10-07 19:42:42 <minimal> I guess it depends on whether Mozilla care for/target corporate "market" anymore - policy.json was aimed in that direction and corporates in EU/UK need to be able to push out automated configuration for their own GDPR compliance so "in theory" Mozilla can't really remove that functionality from a future release if they still want to target EU/UK business customers...
2021-10-07 19:42:44 <Ariadne> the problem, then is that while alpine has been anti-telemetry, anti-ads, etc
2021-10-07 19:42:49 <Ariadne> we don't have written policy
2021-10-07 19:43:00 <Ariadne> that would be a TSC issue i guess
2021-10-07 19:43:01 <kunkku> portability to EU?
2021-10-07 19:43:05 <dalias> that really needs to be remedied imo
2021-10-07 19:43:25 <ikke> Much of Alpine has always been informal
2021-10-07 19:43:40 <dalias> there should be a written policy that the distro is intended to be GDPR-compliant and does not ship phone-home/spyware
2021-10-07 19:43:54 <Ariadne> yeah there should be, we just haven't ever gotten around to it :P
2021-10-07 19:44:10 <Ariadne> more important work has always been priority
2021-10-07 19:44:40 <ikke> And there was never a lack of that :P
2021-10-07 19:44:49 <minimal> I'm willing to help with GDPR-related stuff but I'm not volunteering to lead things :-)
2021-10-07 19:45:11 <Ariadne> anyway if the plan is to "make it follow OS policy" then we need to document the policy
2021-10-07 19:45:25 <Ariadne> because if we don't, mozilla's lawyers will be like "oh yeah, what policy?"
2021-10-07 19:45:59 <minimal> Ariadne: points to where the leopard is ;-)
2021-10-07 19:46:06 <Ariadne> and if we make it follow OS policy first, and document second, they could argue we implemented the policy after the change was made
2021-10-07 19:46:25 <Ariadne> yes, feeding lawyers to leopards makes the world a better place
2021-10-07 19:46:38 <Ariadne> :)
2021-10-07 19:47:05 <minimal> was thinking of the Douglas Adams HHGTG quote about it being on display is a basement with a "beware of the leopard" sign
2021-10-07 19:48:57 <minimal> re policy, its not just about GDPR, there's a (weaker) law in California, and I seem to remember Canada passed a similar law not that long ago, and some other countries have/or are about it introduce similar laws
2021-10-07 19:53:05 <dalias> yes
2021-10-07 19:56:00 <minimal> Ariadne: relevant to the user.js stuff: https://www.ghacks.net/2020/01/06/please-mozilla-dont-touch-the-user-js-functionality-in-firefox/
2021-10-07 20:08:15 <Ariadne> they want to remove user.js it seems: https://bugzilla.mozilla.org/show_bug.cgi?id=1543752
2021-10-07 20:19:47 <Ariadne> i also think dalias makes a good point with patching being a more robust way forward, mozilla could just decide to remove support for the preference entirely
2021-10-07 20:28:02 <dalias> it's like the bootmisc rm -rf
2021-10-07 20:28:12 <dalias> i dont want to trust that configuration keeps it from executing on /
2021-10-07 20:28:14 <dalias> i just want it gone
2021-10-07 20:36:58 <Ariadne> yep
2021-10-07 20:44:50 <kunkku> 
ACTION went on to examine /etc/init.d/bootmisc and will not sleep tonight

2021-10-07 20:44:59 <ikke> lol
2021-10-07 20:52:28 <mps> 
ACTION drink enough wine and will sleep very well :)

2021-10-07 20:53:30 <dalias> is there a tracker item for this yet?
2021-10-07 20:53:35 <dalias> i couldnt find it last time i looked
2021-10-07 20:53:58 <ikke> There is not afaik
2021-10-07 20:54:01 <dalias> :/
2021-10-07 20:54:07 <ikke> dalias: maybe you should create it 
2021-10-07 21:04:34 <dalias> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13070
2021-10-07 21:05:24 <ikke> 👍
2021-10-07 21:07:20 <dalias> i dont have the character, what is that? :-p
2021-10-07 21:07:43 <ikke> :thumbsup:
2021-10-07 21:07:46 <dalias> :)
2021-10-07 21:08:24 <dalias> i need a bug number to add to the greetz for bakelite :)
2021-10-07 21:11:26 <ikke> ?¿
2021-10-07 21:26:30 <dalias> ikke, my current project, tangentially inspired by bootmisc :)
2021-10-07 21:28:43 <ikke> aha  
2021-10-07 21:38:55 <kunkku> btw what's the point in not deleting files starting with a, j, l, and q?
2021-10-07 21:41:47 <Hello71> scroll down ten lines
2021-10-07 21:42:53 <Hello71> it's also nice that they specify "faster than raw find" then proceed to call find immediately after
2021-10-07 22:51:36 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/commit/c4e4f97afc4edd1d73000ab8d3491ed1125d5b42 :|
2021-10-07 23:42:54 <Ariadne> indeed, :|
2021-10-08 06:46:15 <mps> valerius: re: why we (foss community) can't build browser. communities can't build anything, but communities are good at destroying everything
2021-10-08 06:47:44 <mps> communities can build something only under rule of strong, smart and benevolent dictator
2021-10-08 06:50:16 <mps> valerius: I know you very well know history, and if you look back (without modern mindset) you will clearly notice that everything 'big' is built in that way and everything big is destroyed when communities takes these
2021-10-08 06:51:13 <mps> (sorry, you know I'm bad in english and cannot experess my thinking clearly but I think you understand)
2021-10-08 06:51:54 <ncopa> I think we need a commit message linter
2021-10-08 06:52:09 <ncopa> good morning
2021-10-08 06:52:10 <mps> ncopa: I fully agree
2021-10-08 06:52:20 <mps> and good morning
2021-10-08 06:56:29 <Ariadne> rhatr gave a nice status update on alpine riscv64 and what he's doing with it at p99conf: https://www.youtube.com/watch?v=JvaIZzjvn2M
2021-10-08 07:30:26 <ikke> ncopa: I think I can work on that. 
2021-10-08 07:34:20 <ddevault> "Alpine actually feels a lot more like a set of tools that you're using than an operating system that a vendor gave you"
2021-10-08 07:34:22 <ddevault> from that video
2021-10-08 07:34:24 <ddevault> +1
2021-10-08 07:38:13 <Ariadne> well, it's both, but its intended to feel like the former yes
2021-10-08 07:38:34 <ddevault> well, yes
2021-10-08 07:38:38 <Ariadne> largely because, well, i think we all like it when our OS stays the fuck out of the way
2021-10-08 07:38:47 <ddevault> it's less of a vendor and more of a community of people using these tools on a common goal
2021-10-08 07:39:02 <ddevault> outside of institutional matters like security
2021-10-08 07:39:36 <Ariadne> well, there are vendored versions of alpine, the guy in that video sells one
2021-10-08 07:39:37 <Ariadne> :p
2021-10-08 07:39:52 <ddevault> hah, well, yeah, but it does not describe alpine upstream
2021-10-08 07:43:01 <Ariadne> right, and that's the point of alpine.  for people who want the vendor experience, pick the one you like
2021-10-08 07:43:11 <Ariadne> maybe someday there will be sourcehut enterprise linux :P
2021-10-08 07:43:49 <Ariadne> and, if there is, it proves that things work as they are supposed to
2021-10-08 08:23:24 <ncopa> im reading the mozilla trademark thingy
2021-10-08 08:24:07 <ncopa> and i think we can just ship policy.json as /etc/firefox/policies.json
2021-10-08 08:24:19 <ncopa> in the firefox package itself
2021-10-08 08:30:35 <ncopa> hmpf... my audio no longer works. i guess somethign changed in pipewire last month
2021-10-08 08:36:02 <ncopa> actually, audio works with mpv, but not from chromium
2021-10-08 09:03:48 <Habbie> for the packages i maintain, I update them in aports master whenever upstream does a release. What's the policy for updating in older aports branches? minor updates? security updates? minimal patches for CVEs?
2021-10-08 09:07:30 <mps> Habbie: only security updates goes to stable alpine releases
2021-10-08 09:07:56 <mps> and bug fixes
2021-10-08 09:08:26 <mps> in exceptional cases new release of pkg could be 'backported'
2021-10-08 09:08:48 <Habbie> and i see currently 3.11 and up are stable
2021-10-08 09:08:58 <mps> but that have to be done carefully
2021-10-08 09:09:21 <Habbie> understood - we also deal with Debian so we are aware of some of the pain
2021-10-08 09:09:22 <mps> Habbie: yes, main repo
2021-10-08 09:09:36 <Habbie> oh, and what about community?
2021-10-08 09:09:43 <mps> community is about 6 months
2021-10-08 09:10:05 <Habbie> right, so community users would be expected to be running 3.14 already
2021-10-08 09:10:13 <mps> yes
2021-10-08 09:10:28 <Habbie> but if i have a big CVE, i might make an exception and try an MR for an older one
2021-10-08 09:10:41 <mps> yes
2021-10-08 09:10:46 <Habbie> but if no big CVE, only master and latest stable
2021-10-08 09:10:48 <Habbie> awesome, thank you
2021-10-08 09:11:21 <mps> it is like this you wrote
2021-10-08 09:11:59 <mps> but to repeat, in reasonable cases backporting is ok
2021-10-08 09:12:13 <Habbie> yep, same as openwrt then, just on a shorter timeframe
2021-10-08 09:13:11 <mps> heh, I switched from openwrt to alpine for my routers and APs
2021-10-08 09:13:22 <Habbie> that does not sound weird to me
2021-10-08 09:13:31 <Habbie> i maintain our packages (pdns/pdns-rec/dnsdist) in both
2021-10-08 09:13:50 <mps> it's a pity we don't have mips32 arch
2021-10-08 09:14:13 <mps> Habbie: yes, I see you on irc channel
2021-10-08 09:14:34 <Habbie> my primary openwrt testing box is mips32, indeed
2021-10-08 09:15:28 <mps> few days ago I bought one mips32 router with openwrt preinstalled by manufacturer
2021-10-08 09:15:56 <mps> had to upgrade to proper openwrt
2021-10-08 09:16:50 <mps> though I don't want to waste time to cross build alpine for mips32
2021-10-08 09:18:11 <mps> router I bought use musl
2021-10-08 09:18:53 <mps>  /lib/ld-musl-mipsel-sf.so.1 -> libc.so
2021-10-08 10:04:00 <ncopa> im workign on llvm12 update now
2021-10-08 10:05:01 <ncopa> im running out of diskspace
2021-10-08 10:05:13 <ncopa> LLVM ERROR: IO failure on output stream: No space left on device
2021-10-08 10:31:39 <ddevault> ncopa: no space on your hard drive or in /tmp
2021-10-08 10:31:45 <ddevault> I had to unmount /tmp for a build the other day
2021-10-08 10:37:23 <ncopa> on the remote dev box. i cleaned up a few gigs
2021-10-08 11:46:59 <PureTryOut> Shit, I have a package that has both a dep using openssl 3.0, and a dep using openssl 1.1 compat still...
2021-10-08 12:09:41 <dalias> :)
2021-10-08 12:10:41 <dalias> ncopa, for particularly egregious spyware it should be compiled out entirely though not just controlled by policy settings
2021-10-08 12:16:01 <PureTryOut> Ariadne: why was mariadb built with openssl 1.1 rather than 3.0? It builds fine with 3.0 for me and only 2 out of 65 tests fail, maybe that's patchable?
2021-10-08 12:17:13 <psykose> i believe upstream explicitly say they don't support it in current release and will on next
2021-10-08 12:17:17 <psykose> or maybe that was someone else
2021-10-08 12:17:31 <psykose> better to wait for said support than run self patches
2021-10-08 12:18:35 <PureTryOut> Oh, hmm
2021-10-08 12:19:00 <PureTryOut> Hopefully that release will be quick then, as it has now started blocking other packages implicitely
2021-10-08 12:19:20 <ikke> It already did 
2021-10-08 12:19:39 <psykose> yeah, there was a big thing around this back on the 3.0 migration
2021-10-08 12:19:39 <PureTryOut> True
2021-10-08 12:19:52 <psykose> i think like 50% of packages got blocked by mariadb revdep for 3.0
2021-10-08 12:20:01 <PureTryOut> Yeah...
2021-10-08 12:20:04 <psykose> mostly because of curl
2021-10-08 12:20:13 <PJ[m]> https://jira.mariadb.org/browse/MDEV-25785
2021-10-08 12:21:52 <PureTryOut> Yeah that's why I looked into mariadb just a moment ago, damn curl
2021-10-08 12:22:12 <psykose> should be done Eventually™
2021-10-08 12:22:47 <PureTryOut> I'm not sure how to properly upgrade this particular package now though, having 2 deps depend on different versions of openssl
2021-10-08 12:23:06 <psykose> if it depends on something with 1.1 make it 1.1 as well
2021-10-08 12:23:13 <psykose> if it /needs/ 3.0 then no idea :)
2021-10-08 12:23:23 <Habbie> PureTryOut has 1.1 -and- 3.0 deps
2021-10-08 12:23:50 <ikke> Those deps would need to be switched to 1.1
2021-10-08 12:23:51 <psykose> ah, then those deps have to be bumped back to 1.1
2021-10-08 12:24:19 <PJ[m]> from what I read from release notes they should be mostly compatible so for now it should be built with 1.1
2021-10-08 12:25:19 <PureTryOut> 😢 ok
2021-10-08 15:24:42 <ncopa> seems like gvm-libs does not build due to openssl 1.1 and 3.0 conflict
2021-10-08 15:41:01 <mps> got alpine running on olimex A64olinuxino SBC
2021-10-08 15:41:12 <mps> arm64
2021-10-08 15:42:02 <mps> Cortex-A53 cpu with 2GB ram
2021-10-08 15:43:15 <donoban> nice
2021-10-08 15:49:51 <minimal> mps: does it have an RNG?
2021-10-08 15:56:29 <durrendal> mps: what's your usual process for getting alpine onto a new SBC?
2021-10-08 16:24:54 <minimal> Related to yesterday's discussion, https://www.theregister.com/2021/10/08/mozilla_adding_sponsored_search_results/
2021-10-08 16:59:31 <ncopa> i wonder if we should revert the openssl 3.0 upgrade. packages no longer build due to conflicts. its a huge mess
2021-10-08 17:02:24 <ncopa> gvm-libs, greenbone, gvmd and openvas does not build
2021-10-08 17:07:38 <mps> minimal: I didn't finished with all drivers and options for kernel so not sure, but I think it have rng
2021-10-08 17:08:14 <minimal> mps: ok, didn't see any mention either way on their specifications page
2021-10-08 17:08:48 <mps> durrendal: I don't have some pattern to get new board working, depends on docs about board, support in u-boot and kernel, and talk,talk, talk on irc or mailing lists
2021-10-08 17:09:31 <mps> minimal: it is Allwinner A64 soc so sunxi.org could have more info
2021-10-08 17:11:47 <ncopa> ok... seems like part of the problem was that hiredis 1.0.1 erroneously bumped soname
2021-10-08 17:14:13 <durrendal> mps: fair enough, I just see you tinkering with different boards a lot so didn't know if you had a method :)
2021-10-08 17:15:37 <ncopa> gvm-libs depends on both libssh, which needs openssl3, and openldap which needs openssl1.1
2021-10-08 17:16:47 <mps> durrendal: I'm not went to IT schools, but learned by doing and hacking, so I'm not man of methods
2021-10-08 17:17:27 <mps> if only 'try and see will it smoke' is method :)
2021-10-08 17:34:01 <durrendal> mps: you and me both! I'm very much a learn by breaking person haha
2021-10-08 17:47:04 <mps> durrendal: 'experience my dear is most brutal teacher, but you will learn, you will learn dear' - Lewis Carrol in 'Alice in wonderland'
2021-10-08 19:02:03 <Misthios> Oh thats why all of those fail in my rebuilds
2021-10-09 10:12:17 <mps> pine64 tab is allwinner A64 iirc. it is supported in pmOS I think. anyone from pmOS could tell does xorg works on it
2021-10-09 10:13:05 <mps> I got olimex teres notebook (also A64 SBC) and managed to boot alpine but xorg doesn't start
2021-10-09 10:14:23 <mps> actually, what is pmOS url where can be downloaded pkgs
2021-10-09 10:32:52 <PJ[m]> Is it possible to provide multiple depends packages but only require one?
2021-10-09 10:33:45 <PJ[m]> I've a package that requires container runtime but I don't want to force `docker` upon everyone 🤔
2021-10-09 10:37:39 <ikke> PJ[m]: The way to do it is have a common 'provides' for all those runtimes, and then depend on that
2021-10-09 10:38:16 <ikke> And a provider_priority to make apk able to choose one
2021-10-09 10:41:43 <PJ[m]> mhm, that makes sense, thanks
2021-10-09 11:53:59 <PureTryOut> mps: you mean where is the binary repo? https://mirror.postmarketos.org/postmarketos/
2021-10-09 11:55:40 <mps> PureTryOut: thanks, but found it in meantime
2021-10-09 11:55:57 <PureTryOut> 👍️
2021-10-09 11:58:00 <mps> and fyi, pmOS allwinner kernel boots fine on olimex teres, though xorg don't start
2021-10-09 12:04:14 <PureTryOut> xorg works fine on the PineTab at least
2021-10-09 12:04:31 <PureTryOut> But we mainly care about Wayland ourselves so don't really test it often, maybe something broke since the original port
2021-10-09 12:08:31 <mps> PureTryOut: I don't use pmOS but alpine, only tested with pmOS kernel
2021-10-09 12:10:21 <PureTryOut> I realize that
2021-10-09 12:10:25 <mps> heh, if I install xf86-video-fbdev it works
2021-10-09 13:44:28 <ncopa> we cannot release alpine 3.15 with the current mess of openssl 1.1 / 3.0. https://gitlab.alpinelinux.org/alpine/aports/-/issues/13075
2021-10-09 13:46:40 <Hello71> aiui if we get mariadb to 3.0, and all its deps, and nothing else breaks, then we will be mostly on 3.0
2021-10-09 13:46:58 <ncopa> can we get marinade to 3.0 within a few days?
2021-10-09 13:47:08 <ncopa> mariadb.
2021-10-09 13:47:28 <Hello71> i like marinade better than anything to do with mysql :p
2021-10-09 13:47:41 <ncopa> so does macOS apparently...
2021-10-09 13:47:42 <ikke> Officially they only support in the next release from what I udnerstood
2021-10-09 13:47:53 <ikke> but someone managed to build it except for a few failing test cases
2021-10-09 13:48:20 <ncopa> question is if we can use that, and make that work before the release
2021-10-09 13:49:40 <Hello71> ikke: i also vaguely remember hearing that, but https://jira.mariadb.org/browse/MDEV-25785 is still open, and i couldn't find anything relevant from googling "mariadb openssl 3"
2021-10-09 13:50:19 <ncopa> are there other distress that has done the openssl 3.0 jump? could we reuse their patches?
2021-10-09 13:50:31 <ncopa> oh.. man.. this autocorrect...
2021-10-09 13:50:45 <linearcannon> relevant mr with partial fix is https://gitlab.com/redhat/centos-stream/rpms/mariadb/-/merge_requests/4
2021-10-09 13:51:00 <linearcannon> this is a red-hat specific thing afaik
2021-10-09 13:51:14 <ncopa> would be great if we can use that
2021-10-09 13:51:50 <Hello71> based on https://mariadb.com/kb/en/mariadb-server-release-dates/, https://jira.mariadb.org/secure/Dashboard.jspa has the list of release dates. it doesn't scroll down to 10.7 but seems like it will probably be released on 2021-10-28
2021-10-09 13:52:03 <ncopa> anyway, I'm dropping this here and leaving. We need to get the 3.15 builders up asap
2021-10-09 13:52:29 <ncopa> currently abuild has both openssl1.1 and 3.0 in the dependency chain
2021-10-09 13:52:52 <ncopa> I don't think we should bootstrap 3.15 builders til at least that is solved
2021-10-09 13:53:09 <ncopa> the llvm12 upgrade has been significantly timeconsuming
2021-10-09 13:53:23 <ncopa> the build to more than the entire Friday and I bumped into openssl issues
2021-10-09 13:53:37 <ncopa> this is absolutely slowing down the 3.15 release
2021-10-09 13:54:12 <Hello71> yes, i agree we will need to back out openssl 3.0 if we can't fix mariadb in next few days
2021-10-09 13:54:15 <ncopa> also boost 1.76 + 1.77 seems to block the llvm12 upgrade
2021-10-09 13:55:00 <ncopa> there there is python3.10. but I don't think we want open that can of worms til after 3.15 release
2021-10-09 13:55:13 <ikke> yes, agreed
2021-10-09 13:55:24 <ncopa> I would want libffi update and llvm12 in before 3.15 release
2021-10-09 13:55:38 <ncopa> libffi requires fix of ghc
2021-10-09 13:55:56 <ncopa> and I think we should use bundled/static libffi for ghc
2021-10-09 13:56:20 <ncopa> but its time-consuming. requires significant amount of time to solve 
2021-10-09 13:56:42 <ncopa> ok need to go. have a nice weekend!
2021-10-09 13:57:13 <ikke> o/
2021-10-09 13:59:28 <Hello71> python 3.10 is definitely a no-go, many packages still don't work with it. firefox only got fixed in 93 i think, and not sure if those patches were backported to lts. chromium still doesn't work but i think alpine is still using python 2 anyways
2021-10-09 15:03:47 <Ariadne> ncopa: i think we go back to 1.1 for 3.15 release and try again in 3.16
2021-10-09 16:05:44 <dalias> see latest reply to the openrc thing
2021-10-09 16:05:53 <dalias> TL;DR: WONTFIX
2021-10-09 16:06:06 <dalias> so imo alpine should just patch this nonsense out
2021-10-09 16:06:40 <psykose> to be fair it almost never happens and as you predict is probably some weird fs corruption edgecase
2021-10-09 16:06:46 <psykose> but +1 for patch regardless
2021-10-09 16:06:55 <dalias> i think it was a major fluke
2021-10-09 16:07:07 <dalias> but i also think having the string "rm -rf" anywhere in bootscripts is a huge red flag
2021-10-09 16:15:00 <orbea> looking at the function is does seem a bit too much like a blunt hammer
2021-10-09 16:15:54 <orbea> at least it needs some kind of better protection from working outside of /tmp/ by some kind of fluke
2021-10-09 16:47:46 <nmeum> I think we also need to do the icu upgrade + rebuild before the 3.15 release, otherwise we ship an EOL firefox-esr in community
2021-10-09 16:53:04 <ikke> nmeum: What needs to happen for ICU?
2021-10-09 16:54:04 <nmeum> ikke: not sure what the current status is (andypost[m] is working on it iirc) but the upgrade seems to cause a lot of test failures in packages using libicu (see icu gitlab mrs)
2021-10-09 16:54:40 <nmeum> but without icu 69.1 we can't upgrade to firefox 91.X and the 91.X release is the current ESR release
2021-10-09 17:24:11 <minimal> switching to a tmpfs for /tmp seems like the way to go, I guess I assumed that already was the case
2021-10-09 17:29:58 <PureTryOut> Ugh the protobuf upgrade was a mess, I keep finding packages that still need rebuilds
2021-10-09 18:28:33 <PJ[m]> could someone review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26287 ?
2021-10-09 18:32:40 <ikke> Waiting a bit to give the maintainer time to respond
2021-10-09 19:14:56 <Newbyte> how do I properly remove keys generated by abuild-keygen?
2021-10-09 19:17:37 <ikke> just remove them from disk? The keys are put in ~/.abuild, and the public key in /etc/apk/keys if you installed it
2021-10-09 19:19:27 <Newbyte> so there are no other traces of them=
2021-10-09 19:19:29 <Newbyte> ?*
2021-10-09 19:19:44 <ikke> Not that I'm aware of
2021-10-09 19:19:50 <Newbyte> thanks!
2021-10-09 19:58:03 <Misthios> Cogitri i will look at ur comments on !25551 tmr when i have time
2021-10-09 19:58:12 <Newbyte> how can I debug "unable to select packages"? I don't understand what it needs me to do
2021-10-09 19:59:08 <Newbyte> it says installing networkmanager-elogind would break networkmanager-dev (and satisfy a bunch of GNOME packages), but I don't understand why
2021-10-09 21:08:57 <ncopa> Ariadne: what are the issues with apk-tools?
2021-10-09 21:17:04 <ikke> ncopa: You mean this one? https://github.com/openssl/openssl/issues/16660
2021-10-09 21:25:28 <ncopa> Ugh. I was not aware of that
2021-10-09 21:26:00 <ikke> ddevault ran into a segfault
2021-10-09 21:26:55 <ncopa> i would actually prefer to try fix OpenSSL 3.0, but now I’m not sure
2021-10-09 21:28:23 <ncopa> Ariadne: maybe we could have a call tomorrow or Monday? I will be unavailable Tuesday and rest of next week 
2021-10-09 21:28:39 <ncopa> Good night 
2021-10-09 21:28:46 <Ariadne> on monday
2021-10-09 21:28:53 <Ariadne> or tomorrow
2021-10-09 21:28:56 <Ariadne> either is fine
2021-10-09 22:19:03 <Thalheim> is --allow-untrusted required during bootstrap or am I not pointing it to the right keys somehow?
2021-10-09 22:21:01 <ikke> Thalheim: If the keys are present, it should not be required.
2021-10-09 22:21:04 <PJ[m]> ikke, package maintainer can be anyone, I was more hoping for an opinion from person who does that constantly for various packages
2021-10-09 22:21:29 <ikke> PJ[m]: The change itself is prettry trivial
2021-10-09 22:22:15 <ikke> nothing to remark
2021-10-09 22:22:23 <PJ[m]> ok :)
2021-10-09 22:50:33 <Thalheim> it looks like there's a bit of hard-coded /etc/apk/keys and similar; I'm using nonstandard paths. digging...
2021-10-09 23:37:06 <xkrz> is the latest flatpak release (1.12.0) having trouble with syscalls for anyone else?
2021-10-09 23:42:08 <dalias> some awful seccomp thing? :-p
2021-10-09 23:44:07 <xkrz> seems so
2021-10-09 23:45:21 <dalias> what are they blocking?
2021-10-09 23:47:02 <xkrz> error: Failed to block syscall 442 Warning: Missing charsets in String to FontSet conversion
2021-10-09 23:51:41 <ericonr> seems to be mount_setattr
2021-10-09 23:56:25 <dalias> yeah seems like it might not be the relevant error tho
2021-10-09 23:57:03 <ericonr> would seccomp print something like that if the kernel didn't support the given syscall?
2021-10-09 23:57:08 <ericonr> *libseccomp
2021-10-09 23:58:55 <dalias> i dunno. maybe a libseccomp version skew vs flatpak
2021-10-10 00:05:44 <ericonr>             r = seccomp_rule_add (seccomp, SCMP_ACT_ERRNO (errnum), scall, 0);
2021-10-10 00:06:01 <ericonr> if errno==EFAULT, it prints             flatpak_debug2 ("Unable to block syscall %d: syscall not known to libseccomp?", scall);
2021-10-10 00:06:15 <ericonr> otherwise, if r<0             return flatpak_fail_error (error, FLATPAK_ERROR_SETUP_FAILED, _("Failed to block syscall %d"), scall);
2021-10-10 00:06:56 <ericonr> so yeah, either they're probably holding seccomp
2021-10-10 00:06:58 <ericonr> ...wrong
2021-10-10 00:10:25 <ericonr> or seccomp is having issues
2021-10-10 00:39:48 <Hello71> strace would be useful
2021-10-10 06:59:04 <Cogitri[m]> Newbyte: Probably broken provides/replaces on network-manager-elogind-dev
2021-10-10 06:59:37 <Cogitri[m]> As in it can’t install network-manager-dev when nm-elogind-dev is installed and the other way around
2021-10-10 08:26:57 <nmeum> s390x is the only big-endian architecture we support officially, right?
2021-10-10 08:30:49 <ikke> mips64 is big-endian as well
2021-10-10 08:47:01 <ikke> https://www.waterfox.net/
2021-10-10 08:47:49 <ikke> Not open source sadly
2021-10-10 08:48:37 <ikke> oh, it is: https://github.com/WaterfoxCo/Waterfox
2021-10-10 08:49:20 <ikke> They just do not link to it on their website
2021-10-10 08:56:16 <mps> firefox trimmed down?
2021-10-10 09:04:04 <clandmeter> So i finally received the HiFive unmatched and ordered an m.2 from amazon. But DHL returns it undelivered due to address not found...
2021-10-10 09:04:25 <ikke> ugh
2021-10-10 09:04:41 <clandmeter> guess we will have to wait a little longer for "real" rv64 in our infra...
2021-10-10 09:42:45 <nmeum> clandmeter: nice, you can also just use it with the sdcard for now. at least if you just want to play around with it a bit
2021-10-10 09:47:48 <PureTryOut> Oh, will that be the first Alpine bare metal install on riscv64 hardware?
2021-10-10 09:48:53 <liske> I have a problem with CI in !26176 - the pypy-bootstrap package is build fine, but for some reasons CI tries to build the pypy package, although the MR does not contain any changes on it
2021-10-10 09:49:07 <liske> the log for x86_64: https://gitlab.alpinelinux.org/liske/aports/-/jobs/507630#L4125
2021-10-10 09:50:06 <ikke> Will check in a bit
2021-10-10 09:55:18 <psykose> PureTryOut: a number of people have installed it on that same board already, as well as the "unleashed" (predecessor)
2021-10-10 09:56:40 <ikke> nmeum is one of them
2021-10-10 09:57:22 <nmeum> PureTryOut: I already did two :p
2021-10-10 09:57:25 <PureTryOut> ah cool stuff
2021-10-10 10:05:58 <psykose> it's a funny board, the cpu is about the same as an rpi3b in benchmarks but it has nvme and 16gb of ram
2021-10-10 10:29:00 <liske> ikke: using a stripped down MR (using `true` in build) with CI_DEBUG_BUILD shows that changed_aports is wrong https://gitlab.alpinelinux.org/liske/aports/-/jobs/509301#L446
2021-10-10 10:32:05 <ikke> Hmm, the merge-base is correct and connected, so that's not wrong
2021-10-10 10:32:33 <ikke> ap builddirs -d /builds/liske/aports/testing pypy-bootstrap
2021-10-10 10:32:40 <ikke> changed_aports='pypy-bootstrap pypy'
2021-10-10 10:32:46 <liske> exactly
2021-10-10 10:32:54 <liske> what is `ap` ?
2021-10-10 10:32:55 <ikke> so it's ap builddirs that adds pypy
2021-10-10 10:33:05 <ikke> It's a tool from lua-aports
2021-10-10 10:35:10 <ikke> Wonder why ap builddirs adds a package to the list that was not there
2021-10-10 10:35:40 <ikke> ap builddirs is used to order the packages in build order (dependencies built before packages that need them)
2021-10-10 10:36:07 <liske> pypy depends on pypy-bootstrap
2021-10-10 10:37:01 <ikke> yes, and you see it's added as last, so that makes sense, but why is it listed in the first place
2021-10-10 10:38:16 <ikke> desc = "Print the build dirs for given packages in build order"
2021-10-10 10:38:20 <ikke> 'given packages'
2021-10-10 10:38:35 <ikke> I don't see pypy being 'given'
2021-10-10 10:40:12 <ikke> Not sure, but maybe to do with provides="$pkgname-bootstrap=$pkgver-r$pkgrel" in pypy?
2021-10-10 10:44:21 <liske> could ap somehow debugged (in CI)? /me being a lua noob
2021-10-10 10:45:25 <ikke> You should be able to run it locally as well
2021-10-10 10:49:20 <ikke> liske: just curious, how did you find CI_DEBUG_BUILD btw?
2021-10-10 10:50:14 <liske> looked at .gitlab-ci.yml => found the docker repo => reading build.sh
2021-10-10 10:51:16 <ikke> ok, cool
2021-10-10 10:51:26 <liske> having ap builddirs running local: prints both packages
2021-10-10 10:51:52 <ikke> and if you remove the provides from pypy?
2021-10-10 10:52:44 <liske> oO
2021-10-10 10:53:08 <liske> pypy is vanished from builddirs
2021-10-10 10:54:38 <liske> but I need it in pypy - I don't want to use pypy-boostrap when pypy is available (reduces build in a order of magnitude)
2021-10-10 10:55:17 <liske> it is a bug in ap, isn't it?
2021-10-10 10:56:50 <ikke> Probably
2021-10-10 10:57:11 <ikke> https://github.com/jirutka/lua-aports
2021-10-10 10:57:20 <ikke> Could you open an issue there?
2021-10-10 10:57:30 <liske> yes
2021-10-10 10:58:07 <ikke> I could work around it by filtering the list returned again against the provided packages, but would be nice it that's not necessary
2021-10-10 10:58:28 <liske> can !26176 be proceeded or would it also affect the builders?
2021-10-10 10:59:23 <ikke> I don't think it affects the builders
2021-10-10 11:00:14 <ikke> The builders don't look at the changes APKBUILD files, but look what packages still need to be built
2021-10-10 11:03:21 <liske> it is https://github.com/jirutka/lua-aports/blob/master/aports/db.lua#L262 - each_pkg_with_name
2021-10-10 11:03:22 <ikke> liske: oh, I see jirutka disabled issues there
2021-10-10 11:03:51 <liske> the functions sounds like also reporting packages with provides
2021-10-10 11:04:00 <liske> s/functions/function name/
2021-10-10 11:04:03 <ikke> right
2021-10-10 11:04:26 <ikke> ah, lua-aports was already moved to gitlab
2021-10-10 11:04:30 <ikke> https://gitlab.alpinelinux.org/alpine/lua-aports
2021-10-10 11:06:28 <liske> isn't it https://gitlab.alpinelinux.org/alpine/lua-aports/-/issues/1 ?
2021-10-10 11:07:04 <ikke> aha, yes
2021-10-10 11:07:24 <ikke> So it was already encountered before
2021-10-10 11:12:54 <liske> ikke: thanks for looking into it :-)
2021-10-10 11:21:52 <ikke> NP
2021-10-10 11:28:52 <ikke> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2021-10-10 11:28:56 <ikke> ups :P
2021-10-10 11:32:27 <skarnet> you missed one 0
2021-10-10 11:32:32 <ikke> drats
2021-10-10 11:34:54 <psykose> hmm
2021-10-10 12:44:20 <krystianch> hey, I'm not sure, but shouldn't testing/ledger be rebuilt after merging  !21416 ? it seems still wants boost 1.75 when 'apk add'ing it
2021-10-10 12:45:01 <krystianch> (boost 1.75 is gone from edge)
2021-10-10 12:47:25 <ikke> hmm, yes, it seems to be still built against boost1.75
2021-10-10 12:47:48 <krystianch> should I submit a MR for this?
2021-10-10 12:48:06 <ikke> yes
2021-10-10 12:48:08 <krystianch> I mean for bumping pkgrel
2021-10-10 12:48:10 <krystianch> ok
2021-10-10 13:03:05 <krystianch> thanks ikke, !26305
2021-10-10 13:06:09 <ikke> krystianch: oh, apparently it's boost 1.77 now
2021-10-10 13:09:15 <krystianch> ah, yes, I'll amend the message
2021-10-10 15:14:08 <ncopa> I had a call with Ariadne and discussed how to deal with the openssl 3.0/1.1 situation. we will try revert to 1.1 for the alpine 3.15 release.
2021-10-10 15:14:49 <Ariadne> yes, i think its for the best with the apk-tools regression
2021-10-10 15:14:53 <Ariadne> we can try again in 3.16
2021-10-10 15:14:59 <PureTryOut> Oh yes please, thanks 🤗
2021-10-10 15:15:25 <ncopa> ikke: I wonder if you could help me setting up 3.15 builders next week? I can probably help you a bit on Monday setting up the first
2021-10-10 15:15:38 <ncopa> I will be unavailable Tuesday to friday
2021-10-10 15:15:42 <PureTryOut> Will 3.15 have the first riscv64 release as well?
2021-10-10 15:15:49 <ncopa> yes, hopefully
2021-10-10 15:15:53 <PureTryOut> Awesome!
2021-10-10 15:16:00 <Ariadne> since we are able to boot it on real hardware
2021-10-10 15:16:03 <Ariadne> i think so
2021-10-10 15:16:07 <Ariadne> it seems to be basically there
2021-10-10 15:16:24 <Ariadne> though i don't like the whole building on qemu thing so much yet
2021-10-10 15:16:33 <Ariadne> it has worked, but meh :p
2021-10-10 15:16:48 <Ariadne> server grade chips should be coming in 2022
2021-10-10 15:17:39 <ncopa> what I'd want prioritised for 3.15 release: downgrade openssl 1.1, libffi upgrade, boost upgrade and llvm12
2021-10-10 15:17:42 <Ariadne> PureTryOut: fwiw i prefer openssl 3, but i made the point that EVP_md_null() issue is a bad regression, and the mariadb patches from redhat are basically a hackfix
2021-10-10 15:17:52 <ncopa> libffi depends on fixing ghc which is broken
2021-10-10 15:18:02 <PureTryOut> Oh I just hate the "half-half" situation we have now
2021-10-10 15:18:18 <ncopa> I think ghc should use the bundled libffi instead os link system lib dynamically
2021-10-10 15:18:23 <ikke> ncopa: certainly!
2021-10-10 15:18:28 <Ariadne> well you are going to have that situation any time during a transitional period
2021-10-10 15:18:58 <ikke> ncopa: I'll make issues for those to track it
2021-10-10 15:19:03 <Ariadne> its not avoidable :(
2021-10-10 15:19:15 <ncopa> would also be great if we could get rid of boost 1.76 so we only have a single boost version, 1.77
2021-10-10 15:19:19 <ncopa> for the 3.15 release
2021-10-10 15:19:24 <ncopa> but I'm not sure its possible
2021-10-10 15:19:25 <Ariadne> but, we think that openssl 3 can be done in 3.16 release cycle
2021-10-10 15:19:29 <Hello71> or you can pull a gentoo/debian and just wait... and wait... and wait... gentoo is still on java 8...
2021-10-10 15:20:04 <ncopa> it is increasingly difficult to upgrade things
2021-10-10 15:20:10 <psykose> think icu was also supposed to be on that list
2021-10-10 15:20:20 <ncopa> right.. icu would be good too
2021-10-10 15:20:27 <PJ[m]> hello71, but look how stable those are ;)
2021-10-10 15:20:35 <ncopa> oh.. icu is probably required
2021-10-10 15:20:37 <ncopa> ugh
2021-10-10 15:20:42 <ncopa> this is gonna be tricky
2021-10-10 15:20:47 <psykose> it blocks multiple things i believe, firefox included
2021-10-10 15:21:15 <ncopa> maybe we should wait with boost 1.77
2021-10-10 15:21:20 <ncopa> so we don't bite off to much
2021-10-10 15:22:11 <ncopa> it means that fixing ghc is probably first on the list
2021-10-10 15:22:25 <ikke> ncopa: what is the issue with ghc?
2021-10-10 15:22:28 <ncopa> update ghc and make it use bundled libffi
2021-10-10 15:22:29 <ikke> libffi?
2021-10-10 15:22:31 <ikke> ok
2021-10-10 15:22:32 <ncopa> yes
2021-10-10 15:22:41 <ncopa> it also does not build currently
2021-10-10 15:22:49 <Ariadne> we should try to get ghc running on all archs at some point too
2021-10-10 15:22:58 <ncopa> I think it is a problem we ld.gold
2021-10-10 15:23:28 <ncopa> I spent a couple of days on ghc some week ago
2021-10-10 15:23:43 <psykose> does ghc work well on other archs? i remember reading recently that they were only just now getting/got a native aarch64 backend, though it did have llvm for aarch64 before
2021-10-10 15:23:51 <ncopa> the test suite fails. I reported upstream, they think it is ld.gold bug
2021-10-10 15:24:58 <ncopa> I think was something with PIE or similar
2021-10-10 15:25:10 <ncopa> needed -fno-PIE linker flag
2021-10-10 15:25:28 <ncopa> they do have alpine build upstream so ghc should be fixable
2021-10-10 15:26:36 <ncopa> I ran into some weirdness. the test suite failed when running abuild, but when trying to re-run the tests from command line it passed, so it might be something his environment. maybe its enough to just unset LDFLAGS or something
2021-10-10 15:26:45 <ncopa> I never had the time to complete that
2021-10-10 15:27:16 <ncopa> on Monday I will also need to tag a new release of abuild.
2021-10-10 15:29:55 <Hello71> why are we forcing gold for ghc anyways
2021-10-10 15:30:00 <ikke> ncopa: link to issue?
2021-10-10 15:30:31 <Hello71> smells like we can fix it by just using default bfd
2021-10-10 15:32:28 <Hello71> ikke: cf0b33112cd566332be4376233f1c297f03255e7 i guess
2021-10-10 15:32:32 <Hello71> er, https://gitlab.haskell.org/ghc/ghc/-/issues/20355
2021-10-10 15:32:40 <ikke> Hello71: thanks
2021-10-10 15:34:13 <Hello71> according to https://gitlab.haskell.org/ghc/ghc/-/issues/17508 the problem is that gold requires pie and ghc doesn't support pic
2021-10-10 15:34:40 <Hello71> or something vaguely along those lines
2021-10-10 15:35:21 <Hello71> i think the best solution is to just not force gold. i don't know why we do it in the first place, i bet it is some obsolete "optimization"
2021-10-10 15:35:38 <Hello71> because it is all the way from cf0b33112cd566332be4376233f1c297f03255e7 with no explanation
2021-10-10 15:38:26 <ncopa> Hello71: actually tried using the default bfd linker but it didn't solve it
2021-10-10 15:39:22 <Ariadne> it would be nice to get newer musl release for alpine 3.15
2021-10-10 15:39:26 <Ariadne> 
ACTION looks at dalias

2021-10-10 15:39:52 <ncopa> IIRC my next step was to figure out if I could add -fno-PIE together with gold.
2021-10-10 15:40:04 <ncopa> new must release would be great!
2021-10-10 15:40:20 <ncopa> dalias: what's blocking a new muse release?
2021-10-10 15:43:10 <psykose> your autocorrect gives me life
2021-10-10 15:43:54 <ikke> 0:D
2021-10-10 15:51:56 <dalias> i dont think anything
2021-10-10 15:52:04 <dalias> i'll be back to look at it in a few hours
2021-10-10 15:52:14 <dalias> if all is good let's release this week
2021-10-10 16:49:15 <mps> so, how we will now use openssl in makedepends
2021-10-10 16:49:40 <mps> openssl-dev or openssl1.1-compat-dev
2021-10-10 16:50:39 <psykose> i think the latter makes more sense as then openssl-dev doesn't have to be reverted to 1.1
2021-10-10 16:50:57 <psykose> so everything just explicitly marks the latter
2021-10-10 16:51:49 <psykose> but maybe there would be an upgrade issue since openssl->openssl1.1 gets suddenly renamed
2021-10-10 20:09:26 <piraty> maxice8: thanks for the quick merge of chatty rebuild the other day
2021-10-10 20:09:55 <ikke> Hmm, ghc seems to build for me, but it segfaulted on split-dev
2021-10-10 20:10:04 <ikke> 1541439 blocks
2021-10-10 20:10:05 <ikke> Segmentation fault
2021-10-10 20:10:14 <psykose> yes, same for me or so
2021-10-10 20:10:17 <psykose> the tests passed fine
2021-10-10 20:28:08 <ikke> so it's cpio that is segfaulting
2021-10-10 20:36:33 <ikke> i[Inferior 1 (process 1559) exited normally]
2021-10-10 20:36:35 <ikke> typical
2021-10-10 20:37:40 <ikke> it does not segfault if I use a file for stdin
2021-10-10 20:44:31 <ikke> Cannot find a way to reproduce it under gdb :(
2021-10-10 21:04:02 <Hello71> r < file
2021-10-10 21:04:36 <ikke> Hello71: yes, but that does not segfault
2021-10-10 21:04:39 <Hello71> mm.
2021-10-10 21:04:42 <ikke> same if I run cpio <file
2021-10-10 21:04:51 <ikke> it only segfaults with the find ,, 
2021-10-10 21:04:51 <Hello71> try set randomize-layout on?
2021-10-10 21:05:02 <ikke> it only segfaults with the find ,, | cpio ..
2021-10-10 21:05:24 <Hello71> or use strace -k, that's in now
2021-10-10 21:05:26 <ikke> I tried find into a fifo and read from that, no segfault
2021-10-10 21:05:50 <Hello71> 1541439 is a lot of blocks, is it trying to archive itself
2021-10-10 21:06:27 <Hello71> yeah, it's trying to archive itself
2021-10-10 21:07:24 <Hello71> actually what command is it exactly? community/ghc/APKBUILD on master uses local files=$(find ...); echo "$files" | cpio
2021-10-10 21:07:37 <ikke> yes, indeed
2021-10-10 21:07:49 <ikke> but it also happens if I pipe find directly into cpio
2021-10-10 21:09:01 <ikke> Hello71: how can it archive itself? The filelist is generated before, and the destination is a different path
2021-10-10 21:09:43 <Hello71> so what are you saying segfaults?
2021-10-10 21:09:54 <Hello71> the apkbuild has echo "$pfiles" | cpio -pamVd "$subpkgdir"
2021-10-10 21:11:26 <ikke> ind . \( -type f -o -type l \) \( -name "*.p_*" -o -name "lib*_p.a" \) | cpio -pamVd $PWD/../ghc-dev
2021-10-10 21:11:33 <ikke> find*
2021-10-10 21:11:45 <ikke> in the pkg/ghc dir
2021-10-10 21:12:51 <Hello71> but the apkbuild has echo "$pfiles" | cpio -pamVd "$subpkgdir"? i don't understand
2021-10-10 21:13:18 <Hello71> is this on an MR?
2021-10-10 21:13:28 <ikke> no
2021-10-10 21:13:39 <ikke> I just did it as a single command
2021-10-10 21:13:50 <ikke> instead of first storing it in a variable
2021-10-10 21:14:06 <ikke> single pipe, I Must say
2021-10-10 21:14:57 <ikke> local pfiles=$(find ..)
2021-10-10 21:15:27 <ikke> Hello71: what part are you confused about?
2021-10-10 21:15:43 <Hello71> why did you change it
2021-10-10 21:16:24 <ikke> I just tried to reproduce it
2021-10-10 21:16:41 <ikke> The code in the APKBUILD segfaulted
2021-10-10 21:16:46 <Hello71> i see
2021-10-10 21:17:29 <ikke> so echo "$pfiles" | cpio .. segfaults as well
2021-10-10 21:19:09 <ikke> Ok, now it does segfault for me when I run it with <files.txt
2021-10-10 21:21:18 <ikke> Hello71: what did you mean with randomize-layout?
2021-10-10 21:22:15 <Hello71> er, disable-randomization. not sure if they renamed it
2021-10-10 21:22:33 <Hello71> gdb disables aslr by default
2021-10-10 21:22:52 <Hello71> it is probably the main cause of "it only breaks outside gdb"
2021-10-10 21:23:31 <ikke> Hello71: compare: https://tpaste.us/PrbK 
2021-10-10 21:23:58 <Hello71> strange. but why don't you just get a core dump instead?
2021-10-10 21:24:07 <ikke> good question :)
2021-10-10 21:24:57 <ikke> forgot about it
2021-10-10 21:26:17 <ikke> need to add a dbg package
2021-10-10 21:26:19 <ikke> for cpio
2021-10-10 21:28:34 <ikke> Hello71: ok, I now have a backtrace
2021-10-10 21:28:40 <Hello71> :)
2021-10-10 21:29:01 <ikke> https://tpaste.us/6WLW 
2021-10-10 21:29:49 <ikke> seems like mallocng hardening?
2021-10-10 21:31:12 <Hello71> try it in gdb with set disable-randomization off
2021-10-10 21:32:37 <ikke> ok, that works\
2021-10-10 21:33:05 <ikke> I have a bt now in gbd
2021-10-10 21:33:18 <ikke> gdb*
2021-10-10 21:34:30 <ikke> https://tpaste.us/VE9v 
2021-10-10 22:04:50 <Hello71> i wonder why it's got two values of reserved
2021-10-10 22:05:03 <Hello71> actually, valgrind can probably figure this out
2021-10-10 23:03:20 <adamplumb[m]> Is it possible to build a package from a git repo directly?  I'm trying to build from a gitlab archive from a repo that contains a subpackage, but apparently the generated archives don't include subpackages
2021-10-10 23:15:10 <Hello71> use multiple sources
2021-10-11 01:13:21 <sam_> ncopa: you've mentioned libffi a few times
2021-10-11 01:13:28 <sam_> you don't necessarily have to hold offo n the upgrade
2021-10-11 01:13:36 <sam_> you can disable the new trampoline behaviour for now, if you wish
2021-10-11 01:14:17 <sam_> (and we have in gentoo, given that at last check, neither ghc nor glib(-introspection?) were fixed for it)
2021-10-11 01:41:58 <andypost[m]> sam_ thanks for good news - I just rebased !24886 and related - lets see what ci will ahow
2021-10-11 01:42:20 <sam_> np!
2021-10-11 01:42:57 <sam_> you will need to pass --disable-exec-static-tramp i think
2021-10-11 01:43:04 <andypost[m]> Btw ghc needs upgrade before bump I guess
2021-10-11 01:43:16 <sam_> (if you want to take our route)
2021-10-11 01:44:19 <andypost[m]> I bet it help to !20134
2021-10-11 01:44:53 <sam_> btw the only two upstream bugs I know are https://gitlab.haskell.org/ghc/ghc/-/issues/20051 and https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/283
2021-10-11 01:44:56 <sam_> let me know if you find out any others
2021-10-11 01:45:14 <sam_> (hopefully you won't!)
2021-10-11 01:45:52 <andypost[m]> I will check tomorrow morning for sure cos it blocker for release
2021-10-11 01:48:17 <sam_> coo
2021-10-11 01:48:19 <sam_> cool
2021-10-11 01:48:32 <sam_> i see now that development ghc is fixed with the new trampoline but not released it seems
2021-10-11 01:52:08 <andypost[m]> Any schedule?
2021-10-11 02:24:56 <andypost[m]> sam_ as I get it all about https://github.com/libffi/libffi/pull/647
2021-10-11 02:39:21 <sam_> yes
2021-10-11 02:52:27 <Thalheim> in attempting to bootstrap from nothing, does a --repositories-file need to be somehow specified, or /etc/apk/repositories, or is that not required? I'm essentially at the step of 'abuild -r' with binutils following bootstrap.sh
2021-10-11 02:52:52 <Thalheim> not sure what else I need; doing this in a handmade non-alpine chroot with apk-tools and all the other fun stuff
2021-10-11 02:53:26 <Thalheim> I am seeing e.g. ERROR: Unable to read database state: No such file or directory
2021-10-11 03:38:15 <Thalheim> past that now, nvm. CBUILDROOT needed to be set to / in my case
2021-10-11 06:41:14 <mps> nmeum: if you find time would you look at !26310 
2021-10-11 06:41:38 <mps> it works fine on my aarch64
2021-10-11 06:42:34 <mps> ikke: your final opinion or objection to !26059 ?
2021-10-11 06:44:22 <mps> clandmeter: !25043 I can't find any way to improve this, except to merge it before freeze
2021-10-11 07:15:19 <Misthios> ncopa was the gvmd opensll situation resolved or?
2021-10-11 07:36:52 <ncopa> Misthios: not yet. i think the current plan is to revert openssl back to 1.1. it should solve the gvmd
2021-10-11 07:37:26 <Misthios> ah okay
2021-10-11 07:56:26 <ikke> mps: no objection against splitting gvim
2021-10-11 08:02:26 <mps> ikke: thanks
2021-10-11 09:02:17 <markand> can we do something regarding my last comment in !22933
2021-10-11 09:06:11 <darkdragon> Do I see it correctly, that static packages (e.g. libzmq-static) are statically linked to libstdc++ libgcc etc.? So shouldn't the resulting license then be GPL and not LGPL with link exception?
2021-10-11 10:21:09 <ikke> ncopa: regarding ghc, what was the build failure you were running into? For me (without libffi upgrade), it seems to build fine, though cpio in dev() is segfaulting
2021-10-11 11:13:48 <ncopa> ikke: the tests are failing
2021-10-11 11:13:52 <ncopa> some of the tests
2021-10-11 11:14:13 <ncopa> ncopa-edge-x86_64:~/aports/community/ghc/src/ghc-9.0.1 (ghc)$ make test TEST="callstack001"
2021-10-11 11:14:23 <ncopa> seems to be flaky
2021-10-11 11:16:09 <ncopa> I did: curl -L https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20134.patch | git am -3
2021-10-11 11:16:45 <ncopa> and then added this on top: https://tpaste.us/mqKg
2021-10-11 11:38:10 <ncopa> I also get the cpio segfault
2021-10-11 11:38:23 <ncopa> looks like malloc-ng is catching somthing nasty
2021-10-11 11:46:14 <ikke> Yes, I had the same feeling 
2021-10-11 12:01:37 <dalias> O_O
2021-10-11 12:02:02 <dalias> cpio segfault? that sounds bad -- cpio should not be doing anything complex
2021-10-11 12:02:40 <ikke> I pasted gdb output yesterday 
2021-10-11 12:02:43 <dalias> like it has no business dealing with dynamic buffers at all. it's basically just a loop of [read fixed form header, act on it, copy stream of data]
2021-10-11 12:03:11 <ikke> https://tpaste.us/VE9v 
2021-10-11 12:04:11 <ncopa> it happens here: i tried https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/ghc/APKBUILD#L181
2021-10-11 12:04:46 <dalias> that's cpio?
2021-10-11 12:04:51 <ikke> Yes
2021-10-11 12:05:08 <dalias> it says ghc tho
2021-10-11 12:05:24 <ikke> See what ncopa linked to
2021-10-11 12:05:42 <skarnet> it says "-pam"
2021-10-11 12:05:46 <skarnet> that's obviously the problem :P
2021-10-11 12:06:08 <ikke> 😑
2021-10-11 12:06:20 <dalias> ok but the backtrace was in a binary that's using ghc source files. not the system cpio utility
2021-10-11 12:06:29 <dalias> so i'm confused
2021-10-11 12:06:48 <dalias> ohhh no sorry i'm dumb
2021-10-11 12:07:03 <dalias> that string not from gdb it's a string in the traced program
2021-10-11 12:07:05 <dalias> now i get it
2021-10-11 12:07:53 <ncopa> i had a similar backtrace
2021-10-11 12:08:22 <Hello71> ikke: i guess you didn't get around to trying valgrind?
2021-10-11 12:08:55 <ikke> Hello71: I did try it, but I didn't see it segfaulting 
2021-10-11 12:09:09 <dalias> did you see any invalid writes?
2021-10-11 12:09:22 <dalias> valgrind aims to report not segfault
2021-10-11 12:09:24 <Hello71> hm. i would think that valgrind should catch this invalid write, but it could depend on the memory layout
2021-10-11 12:09:27 <ikke> I believe so
2021-10-11 12:09:38 <dalias> well then valgrind probably told you why it's happening :-p
2021-10-11 12:09:40 <ncopa> i will try test it in valgrind if i get time today
2021-10-11 12:09:54 <ncopa> im rerunning the ghc tests now
2021-10-11 12:13:36 <ikke> https://tpaste.us/RE1o
2021-10-11 12:15:45 <ncopa> off-by-one!
2021-10-11 12:22:16 <Hello71> i bet https://gitlab.alpinelinux.org/alpine/aports/-/commit/6d7b493eceb77189ebd3316fbe7788d630a306b2 is broken
2021-10-11 12:22:44 <Hello71> yup
2021-10-11 12:23:06 <Hello71> https://git.savannah.gnu.org/cgit/cpio.git/log/:  Rewrite dynamic string support. Fix previous commit. Fix dynamic string reallocations
2021-10-11 12:23:19 <Hello71> and we cherry-picked the first one
2021-10-11 12:24:13 <Hello71> the cve isn't even the right number, it's CVE-2021-38185
2021-10-11 12:24:33 <Hello71> oh it's right in the apkbuild, just not the commit description
2021-10-11 12:24:40 <Hello71> :|
2021-10-11 12:26:37 <ncopa> Hello71: do you have time to come with a fix for cpio?
2021-10-11 12:27:03 <Hello71> i think debian just cherry-picked the next two
2021-10-11 12:30:40 <Hello71> i don't understand why ghc apkbuild needs to use cpio -p in the first place
2021-10-11 12:30:53 <ncopa> neither do i
2021-10-11 12:37:18 <Hello71> i wonder what will happen if we just replace it with amove
2021-10-11 12:37:48 <Hello71> i think the maintainer has been MIA for some time
2021-10-11 12:37:56 <Hello71> we should still fix cpio but then it will not be blocking anything
2021-10-11 12:38:06 <ncopa> we still need fix cpio
2021-10-11 12:38:21 <dalias> the comment suggests it's to prevent installing something gratuitously large
2021-10-11 12:38:41 <ncopa> ghc can help us verfiy that we actually fixed cpio
2021-10-11 12:39:14 <dalias> lovely, the cve fix introduced a new buffer overflow?
2021-10-11 12:39:25 <ncopa> seems so yes
2021-10-11 12:39:44 <psykose> it's overflows all the way down
2021-10-11 12:39:54 <jvoisin> "C is short for CVE"
2021-10-11 12:39:55 <skarnet> yo dawg I herd u like CVEs
2021-10-11 12:40:46 <dalias> did alpine just cherry pick the fix wrong tho?
2021-10-11 12:40:56 <dalias> or was it a real new overflow upstream?
2021-10-11 12:41:17 <ncopa> alpine cherrypicked a bad upstream commit i think
2021-10-11 12:41:36 <ncopa> and did not cherry pick the needed follow up fixes
2021-10-11 12:44:17 <psykose> yeah just need to add two more patches, for the 2 commits after the existing one from the above savannah link
2021-10-11 12:44:19 <markand> 
ACTION throws a let's rewrite all in rust 

2021-10-11 12:44:19 <psykose> that should fix it
2021-10-11 12:45:01 <psykose> the fix happened 3 days after the cve patch in alpine
2021-10-11 12:45:12 <psykose> makes sense someone just missed it
2021-10-11 12:50:58 <dalias> this whole dynamic string thing is idiotic
2021-10-11 12:51:07 <dalias> cpio supports what? pathnames up to 100 bytes?
2021-10-11 12:51:39 <dalias> there is utterly no reason to use dynamic pathname strings in a program whose only data format intentionally has a tiny path limit
2021-10-11 12:52:00 <dalias> except gnu dogma
2021-10-11 12:55:37 <Hello71> gnu cpio supports six kinds of cpio and two kinds of tar
2021-10-11 12:58:46 <Hello71> https://www.gnu.org/software/tar/manual/html_section/cpio.html: "The cpio archive formats, like tar, do have maximum file name lengths. The binary and old ASCII formats have a maximum file length of 256, and the new ASCII and CRC ASCII formats have a max file length of 1024. GNU cpio can read and write archives with arbitrary file name lengths, but other cpio implementations may
2021-10-11 12:58:48 <Hello71> crash unexplainedly trying to read them."
2021-10-11 13:00:26 <Hello71> of course it raises the question of what is the point of a gnu-specific cpio extension, why don't you use a better format
2021-10-11 13:03:52 <dalias> gnu dogma
2021-10-11 13:04:12 <dalias> also i wonder why anyone is using the gnu implementation of this utility
2021-10-11 13:04:26 <dalias> the busybox one has always been perfectly suitable to me, and i'm sure there are good bsd ones
2021-10-11 13:06:59 <Hello71> i guess because it doesn't support the dubious -a feature
2021-10-11 13:09:18 <dalias> eew
2021-10-11 13:09:39 <Hello71> which isn't even useful here because we delete the source files
2021-10-11 13:09:40 <dalias> my eyes
2021-10-11 13:10:10 <dalias> an O_NOATIME would be nice, but resetting it with a race condition is awful
2021-10-11 13:52:19 <PureTryOut> Ariadne: so should we move packages using openssl 3.0 back to 1.1 for now?
2021-10-11 14:02:14 <ncopa> Yes
2021-10-11 14:08:01 <PureTryOut> Great, will do when I encounter them then
2021-10-11 14:24:48 <ncopa> Hello71: are you following up cpio bug or should I do so now? I have 20 min
2021-10-11 14:46:41 <Hello71> i can do it today
2021-10-11 14:49:33 <ncopa> great. thanks!
2021-10-11 14:49:51 <Hello71> !26330
2021-10-11 14:50:09 <ncopa> ikke: i have approved a number of MRs in abuild repo. I wonder if you could help rebase and merge then they pass the CI?
2021-10-11 14:50:11 <Hello71> er, oops
2021-10-11 14:50:29 <ncopa> once they all are merged you can tag a _rc release
2021-10-11 14:51:08 <Hello71> s/then/when/?
2021-10-11 14:51:43 <ncopa> yes. when they pass the CI
2021-10-11 14:51:49 <ncopa> tag 3.9.0_rc1
2021-10-11 14:52:23 <ncopa> there are a few that are quite significant like the one that adds version to cmd: provides
2021-10-11 14:52:34 <ncopa> needs to be done before bootstrapping sports repo
2021-10-11 14:52:42 <ncopa> ok. I need to run now. Have fun!
2021-10-11 15:01:42 <ikke> ncopa: yes, will do that
2021-10-11 16:02:53 <Hello71> would be nice to get https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/122 for 3.15 too, i submitted it a while ago but accidentally to my fork
2021-10-11 16:53:58 <Hello71> ikke: what is the process for updating abuild on builders? in other words when can i reland !23988
2021-10-11 16:54:19 <ikke> Hello71: step 1: make an abuild release
2021-10-11 16:54:24 <ikke> step 2: bump abuild in aports
2021-10-11 16:54:39 <ikke> ncopa asked me to merge a few MRs and then make an rc release
2021-10-11 16:55:05 <ikke> Hello71: the builders will automatically use the latest build version
2021-10-11 16:55:19 <Hello71> s/build /abuild /?
2021-10-11 16:55:25 <ikke> yes
2021-10-11 17:00:37 <Hello71> i see, thanks
2021-10-11 18:55:36 <ikke> Hello71: I have tagged rc1
2021-10-11 18:56:38 <ikke> perl tests fail on rv64
2021-10-11 19:20:19 <Hello71> ok :)
2021-10-11 19:22:42 <ikke> lesigh
2021-10-11 19:27:31 <Hello71> link?
2021-10-11 19:27:48 <ikke> Hello71: it's on a container we are bootstrapping, no build log yet
2021-10-11 19:27:52 <Hello71> mm.
2021-10-11 19:28:13 <ikke> and the scrollback buffer was too small
2021-10-11 19:29:45 <ikke> How feasible would something like this be to handle just a single http request: printf "HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\ntest\r\n" | nc -l -p 8080
2021-10-11 19:33:47 <Hello71> it doesn't check the path or close the connection
2021-10-11 19:33:53 <skarnet> ikke: on the server side? a bit more complex, because you need to read the client request first
2021-10-11 19:34:24 <skarnet> also what Hello71 says, http is a bit too complex to be handled in oneliners :P
2021-10-11 19:34:38 <ikke> skarnet: usecase is to handle a single request in a test suite
2021-10-11 19:34:45 <Hello71> although i think most clients are probably lenient enough to accept it
2021-10-11 19:34:49 <skarnet> yeah but you still need to check the request
2021-10-11 19:34:52 <ikke> curl accepts it
2021-10-11 19:35:05 <skarnet> that's an artefact of kernel buffering
2021-10-11 19:35:05 <Hello71> i mean, if it works then it works
2021-10-11 19:35:21 <skarnet> if you try it on a Unix domain socket it might not work
2021-10-11 19:35:38 <Hello71> curl is probably more lenient than most clients when it comes to keepalive
2021-10-11 19:35:57 <ikke> I need a simple way to offer a file download over http
2021-10-11 19:36:01 <Hello71> actually in this case shouldn't curl hang? how does it know the file is done
2021-10-11 19:36:18 <ikke> Hello71: eof from nc closing the connection?
2021-10-11 19:36:25 <Hello71> busybox nc doesn't seem to
2021-10-11 19:36:43 <skarnet> just run bb httpd behind s6-tcpserver and be done with it :P
2021-10-11 19:37:02 <ikke> Hello71: I just tested it with bb nc
2021-10-11 19:37:03 <Hello71> ah, i think curl will shutdown its end once it's done sending the request
2021-10-11 19:37:12 <ikke> /usr/bin/nc symlink target is owned by busybox-1.34.1-r0
2021-10-11 19:37:57 <ikke> skarnet: we do not have bb httpd :)
2021-10-11 19:38:11 <Hello71> skarnet: you mean it will block?
2021-10-11 19:38:14 <Hello71> ikke: it's in -extras
2021-10-11 19:38:18 <ikke> ah, right
2021-10-11 19:38:55 <skarnet> Hello71: the client could block on write(), yes
2021-10-11 19:39:14 <Hello71> actually, no, it will be ok as long as you read from the output of nc?
2021-10-11 19:39:28 <skarnet> as long as you read *first*
2021-10-11 19:40:06 <Hello71> nc surely handles that, otherwise if you use it interactively it won't print any server banner
2021-10-11 19:40:42 <skarnet> whether the client or the server speaks first is part of the protocol
2021-10-11 19:40:55 <skarnet> if you don't follow the protocol, you expose yourself to things not working :P
2021-10-11 19:41:03 <Hello71> yes, i agree
2021-10-11 19:41:24 <ikke> right
2021-10-11 19:41:25 <Hello71> but i'm saying it won't break for the specific reason of unix socket blocking
2021-10-11 19:41:54 <skarnet> it was an example, idc about the exact specific reason, just saying there are cases where it won't work
2021-10-11 19:42:08 <skarnet> replace with two fifos if you want :P
2021-10-11 19:43:02 <ikke> fun, test suite failing in CI, while it works everywhere else
2021-10-11 19:43:30 <Hello71> ikke: is it the affinity nonsense again :p
2021-10-11 19:43:36 <Hello71> i think that's the pulseaudio issue
2021-10-11 19:43:53 <ikke> it's abuild
2021-10-11 19:44:54 <ikke> in the test suite, we expand PATH so that it can find the abuild executables. But in CI it fails with error 127
2021-10-11 20:09:54 <ikke> facepalm, It's doas that was missing, which abuild-keygen tries to invoke
2021-10-11 20:51:48 <ikke> scdoc to generate documentation, would that be makedepends_host or makedepends_build?
2021-10-11 20:59:35 <Hello71> build, it is a command
2021-10-11 21:00:06 <ikke> right, that's where I added it
2021-10-11 22:13:57 <liske> ikke: nc requires -q 0 to close on eof (but busybox doesn't support it)
2021-10-11 22:14:06 <ikke> ah ok
2021-10-11 22:16:55 <liske> "If seconds is negative, wait forever (default). Specifying a non-negative seconds implies -N." => -N is even shorter than -q 0
2021-10-11 22:17:52 <liske> I always wonder why bsd nc does not quit on eof
2021-10-11 22:59:28 <skarnet> because it does not transmit EOF correctly
2021-10-11 23:33:28 <dalias> ...
2021-10-11 23:33:53 <dalias> so infuriating how many network things fail to transmit eof right
2021-10-11 23:39:53 <skarnet> dalias: you're the one who says that shutdown(fd, 1) isn't a good solution because fd may be shared and all the connections will be closed :P I'm of the opinion that fd should not be shared and shutdown() should be performed.
2021-10-11 23:42:43 <dalias> well close would cause shutdown if its not shared
2021-10-11 23:42:54 <dalias> so theyre failing to even close
2021-10-11 23:43:26 <dalias> i was just informed schily passed away yesterday
2021-10-11 23:46:10 <valerius> :(
2021-10-11 23:49:24 <skarnet> dalias: there's one fd for writing and it's duped for reading, in the same process
2021-10-11 23:49:58 <skarnet> you have to do that for full-duplex
2021-10-12 07:10:57 <clandmeter> ikke: now that I think of it, didnt we want to wait for stable rv64 releases until we can run proper tests?
2021-10-12 07:12:54 <ikke> That sounds like a circular dependency 
2021-10-12 07:14:48 <clandmeter> not sure what you mean
2021-10-12 07:16:20 <ikke> You could argue that we need to run the test suite for a stable release 
2021-10-12 07:19:28 <clandmeter> i think we could add it to the agenda of the tsc today.
2021-10-12 10:29:48 <ikke> hmm, isl22 source seems to be awol
2021-10-12 10:30:31 <ikke> at least, a timeout when trying to fetch it
2021-10-12 10:43:35 <psykose> https://downloads.sourceforge.net/project/libisl/isl-${pkgver}.tar.xz this is the new place
2021-10-12 10:43:54 <ikke> psykose: ok, good to know
2021-10-12 10:44:44 <ikke> https://libisl.sourceforge.io/
2021-10-12 10:45:15 <psykose> ah, neat, looks like they moved it finally then
2021-10-12 10:45:19 <psykose> the old host was shut down
2021-10-12 10:48:05 <ikke> psykose: updated the packages
2021-10-12 10:48:45 <psykose> looks good
2021-10-12 10:48:45 <ikke> Only the source though, forgot the url
2021-10-12 10:49:03 <psykose> it might change again, who knows
2021-10-12 10:49:30 <ikke> We also keep a copy on our distfiles
2021-10-12 14:11:13 <mkaesberger> ncopa: chromium 94+ is a big mess and completely unusable. ALSA/sound works with 95 again, but all tabs crash regularly
2021-10-12 14:11:34 <mkaesberger> I managed to catch some backtraces for 95.0.4638.40: https://gist.github.com/mkaesberger/324e27d349f9f3214460283b75ab7383
2021-10-12 14:18:15 <ikke> ncopa is away 
2021-10-12 14:19:43 <Hello71> i think what we should do about chromium is merge llvm12 and then make chromium-clang-asan
2021-10-12 14:19:53 <Hello71> otherwise these crashes are basically impossible to diagnose remotely
2021-10-12 14:34:19 <mkaesberger> is there an estimate when llvm12 will be ready/merged? 
2021-10-12 14:40:12 <yyp> The MR seems to be in good shape, not sure what exact plans are
2021-10-12 14:42:38 <ikke> Misthios said there were a few issues left 
2021-10-12 14:42:50 <ikke> Not sure if they have been solved yet 
2021-10-12 16:00:10 <Misthios> Some are blocked by openssl, im gonna try to fix the rest rhis evening
2021-10-12 16:15:48 <andypost[m]> Misthios please check that link is not broken as for llvm11, it missing review  !23389
2021-10-12 16:27:17 <dalias> good coverage of what went down with the firefox shit:
2021-10-12 16:27:19 <dalias> https://www.quippd.com/writing/2021/10/10/firefox-suggest-an-anatomy.html
2021-10-12 16:29:11 <Misthios> andypost[m] will do
2021-10-12 17:14:10 <ikke> hmm, why is python3 a transitive dependency of aports-build
2021-10-12 17:14:34 <ikke> (build dependency)
2021-10-12 17:16:27 <ikke> probably due to git
2021-10-12 17:19:42 <dalias> ?
2021-10-12 17:20:14 <ikke> git pulls in python3-dev
2021-10-12 17:20:25 <dalias> is there a git dep on python? if so it's surely some fringe subcommand functionality that should be relegated to a separate package...
2021-10-12 17:20:36 <ikke> yes
2021-10-12 17:20:39 <ikke> I think p4
2021-10-12 17:20:57 <dalias> i recall there was perl like that at least at one point and i always just built with it disabled
2021-10-12 17:22:26 <ikke> git-perl is a subpackage that you do not need to install
2021-10-12 17:22:33 <ikke> but atm at least it's a build dependency
2021-10-12 17:22:42 <ikke> well, perl that is
2021-10-12 17:27:37 <mps> heh, nowadays people thinks that adding more features (and mostly useless) is improvement
2021-10-12 17:28:04 <psykose> back in my day nothing ever added any features
2021-10-12 17:57:23 <Misthios> andypost[m] 12 seems to have the symlink
2021-10-12 18:13:33 <clandmeter> ddevault: did you boot unmatched with efi?
2021-10-12 18:13:56 <ddevault> yes
2021-10-12 18:14:08 <ddevault> and I sent the aports patches necessary to get grub working
2021-10-12 18:15:51 <ikke> ok, so mosquitto -> (libwebsockets|cjson) -> cmake -> python3; 
2021-10-12 18:17:04 <clandmeter> ddevault: interesting
2021-10-12 18:17:16 <bl4ckb0ne> can I have a round of review for !24589 pls
2021-10-12 18:17:53 <ddevault> I also had to prepare a patched u-boot and opensbi
2021-10-12 18:18:02 <ddevault> minor edits
2021-10-12 18:19:20 <clandmeter> any difference between u-boot and efi boot?
2021-10-12 18:19:59 <ddevault> I don't understand your question
2021-10-12 18:20:45 <clandmeter> any limitations when booting via efi?
2021-10-12 18:20:53 <ddevault> it seems to work
2021-10-12 18:21:01 <ddevault> persistent efivars would require additional effort
2021-10-12 18:21:38 <ddevault> otherwise, it works well, I was able to boot up a mostly standard alpine installation iso, install to nvme, then boot from nvme, without any hacks
2021-10-12 18:21:55 <clandmeter> boot from nvme?
2021-10-12 18:21:57 <clandmeter> without sd?
2021-10-12 18:22:01 <ddevault> with sd
2021-10-12 18:22:09 <ddevault> the sd just has openspi and u-boot on it
2021-10-12 18:22:12 <ddevault> think of it like the firmware
2021-10-12 18:22:26 <ddevault> the next step would be to move that onto the onboard SPI flash, but I haven't looked into that yet
2021-10-12 18:22:59 <ddevault> do you have an unmatched board you're setting up?
2021-10-12 18:23:00 <clandmeter> ah right, you still need all those pieces 
2021-10-12 18:23:18 <clandmeter> yes i got it
2021-10-12 18:23:27 <clandmeter> running from sd atm
2021-10-12 18:23:51 <ddevault> if you write to ~alpine/devel and Cc me I can reply tomorrow with details of the boot process, my setup, and the bootstrapping steps
2021-10-12 18:26:46 <Misthios> mps would you mind if i upgraded zig as part of the llvm12 rebuilds? (Since it depends on it anyway)
2021-10-12 18:27:10 <mps> Misthios: don't do this
2021-10-12 18:27:16 <Misthios> Okidoki
2021-10-12 18:27:25 <mps> why make llvm MR more complicated
2021-10-12 18:27:55 <mps> if you want you can upgrade zig when llvm is merged
2021-10-12 18:29:07 <Misthios> Hmm, when rebuilding zig it complains about lld claiming llvm files that why it fails
2021-10-12 18:29:21 <Misthios> And only with zig 
2021-10-12 18:29:45 <Misthios> Ideas?
2021-10-12 18:30:45 <mps> till we/I see I don't have any idea why it fails
2021-10-12 18:30:57 <Misthios> Omw to tpaste
2021-10-12 18:31:08 <mps> no for me
2021-10-12 18:31:16 <Misthios> O
2021-10-12 18:31:18 <mps> but ofc, you can
2021-10-12 18:31:48 <mps> will look on it but doubt I will see anything useful
2021-10-12 18:31:55 <Misthios> Well most of the things that fail work fine locally (most of them are due to openssl conflics atm) and i fixed most of the others
2021-10-12 18:32:21 <mps> if it works, merge it
2021-10-12 18:32:39 <Misthios> Only real failures left are postgres on s390x (jit test), and apk-polkit-rs and zig
2021-10-12 18:33:15 <Misthios> That zig error is weird and should be looked at but i just dont know why
2021-10-12 18:34:12 <mps> I think postgresql don't need llvm12
2021-10-12 18:34:31 <mps> it could be built with older one
2021-10-12 18:34:47 <Misthios> Ah
2021-10-12 18:53:21 <Misthios> mps fixed that lld error
2021-10-12 19:01:03 <ikke> I'm trying to figure out how to disable git from building / installing the documentation, but I don't even see what triggers it (there is a install-doc target, but I don't see it being used as a dependency, nor it being called directly)
2021-10-12 19:03:00 <psykose> the manpages or the other docs
2021-10-12 19:04:20 <ikke> manpages, I try to be able to build git without asciidoc
2021-10-12 19:04:39 <dalias> ikke, heh, i thought that was a problem unique to gnu packages :-p
2021-10-12 19:05:03 <ikke> dalias: the confusing make rules?
2021-10-12 19:05:28 <ikke> interestingly, the man pages only get built during install phase
2021-10-12 19:07:30 <mps> Misthios: good news
2021-10-12 19:08:11 <psykose> i checked the gentoo ebuild for it and what they do for +doc and i can see i have manpages even with -doc, and xmlto/asciidoc are only needed for html/other docs apparently
2021-10-12 19:08:15 <psykose> though this looks like a mess
2021-10-12 19:09:23 <dalias> ikke, inability to disable doc (texinfo) build
2021-10-12 19:09:27 <ikke> aha
2021-10-12 19:09:46 <dalias> the idea that someone building your sw would want to build docs is so nonsensical to me
2021-10-12 19:09:55 <dalias> anyone who wants to read docs will do it in their browser
2021-10-12 19:10:11 <dalias> docs build is only meaningful to maintainers and folks forking it
2021-10-12 19:10:26 <psykose> not everyone has internet all the time, but it is quite niche
2021-10-12 19:12:32 <ikke> It's not that I want to disable it permanently, just during bootstrapping
2021-10-12 19:25:29 <dalias> psykose, yeah, even still it's not derived data in a sense i'd care to build
2021-10-12 19:25:54 <dalias> it's not arch dependent or OS dependent. it doesn't need to be built to my system, and i don't have to trust that it was built correctly to use it
2021-10-12 19:26:30 <dalias> unless i'm forking the program and want to document changes to my fork, there is no reason i'd do something other than just wget the official doc build to read offline
2021-10-12 19:27:02 <psykose> yes, but the docs are generated from the code, to wget them from somewhere you need them to be built at some point... so, they're part of the build system
2021-10-12 19:27:39 <psykose> i don't mean they should be default-on or hard to disable or something
2021-10-12 19:27:44 <dalias> oh lolz..
2021-10-12 19:27:51 <dalias> "docs generated from code" = not docs
2021-10-12 19:28:28 <psykose> there are like 50 ways to handwrite docs inside the code and then extract them from there, in wide use
2021-10-12 19:28:40 <psykose> like it or not but it's there
2021-10-12 19:28:49 <psykose> not autogenerated
2021-10-12 19:31:16 <dalias> i understand it's handwritten content from comments, but it's still not docs because it's not structured as such
2021-10-12 19:32:23 <dalias> it might in some sense be a reference document but it's not a usage document
2021-10-12 19:32:32 <ikke> I'm still puzzled how the install-* targets are triggered
2021-10-12 19:32:36 <dalias> :-p
2021-10-12 19:32:47 <dalias> ikke, doesn't make have ssome sort of trace?
2021-10-12 19:41:24 <ikke> ok, I'm stupid
2021-10-12 19:42:41 <ikke> I searched for doc in the APKBUILD, but there is install-man 😑
2021-10-12 19:51:08 <dalias> :)
2021-10-12 20:36:49 <ikke> pax-utils upstream is awol
2021-10-12 20:39:45 <ikke> here now: https://dev.gentoo.org/~sam/distfiles/
2021-10-12 20:41:31 <dalias> heh
2021-10-12 20:45:49 <liske> can someone consider looking at !26176? Please be aware that the package of the mr builds fine but due to issue lua-aports#1 CI fails 
2021-10-12 20:51:42 <ikke> liske: most focus is now on getting 3.15 out
2021-10-12 23:25:58 <sam_> ikke: not really awol
2021-10-12 23:26:03 <sam_> just slyfox@ retired
2021-10-12 23:26:08 <sam_> still available on gitweb and such
2021-10-12 23:26:20 <sam_> i'd like to get a more stable location though
2021-10-12 23:26:45 <sam_> oh nice to see isl moved
2021-10-13 01:46:08 <andypost[m]> something weird with x86 CI runner https://gitlab.alpinelinux.org/alpine/aports/-/jobs/511245#L52
2021-10-13 04:08:47 <smcavoy> andypost[m]: seeing that as well... and aarch64 builds do not seem to be getting scheduled
2021-10-13 04:13:54 <andypost[m]> aarch64 finishing run https://gitlab.alpinelinux.org/alpine/aports/-/jobs/511268
2021-10-13 04:15:43 <andypost[m]> pushed commit, maybe it will recalculate
2021-10-13 04:34:15 <smcavoy> I mr from just about an hour ago just started the aarch64: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26382 x86 is still not working
2021-10-13 04:36:30 <ikke> x86 failed
2021-10-13 04:39:02 <andypost[m]> yep, >>> ERROR: nodejs-current: Failed to create index
2021-10-13 04:39:48 <andypost[m]> btw both builder and CI
2021-10-13 04:40:06 <ikke> yup
2021-10-13 05:08:59 <ikke> the index should be fixed now
2021-10-13 05:17:37 <andypost[m]> thank you, looks 3.14 is not affected
2021-10-13 05:17:50 <ikke> no, this was just edge
2021-10-13 05:31:32 <Ariadne> welp
2021-10-13 05:31:49 <Ariadne> the new proposed openrc wipes your system solution is "use systemd-tmpfiles"
2021-10-13 05:32:02 <ikke> :D
2021-10-13 05:33:51 <Ariadne> i swear if i wind up having to fork openrc, i am going to have an advent calendar of CVEs
2021-10-13 05:34:12 <ikke> popcorn.gif
2021-10-13 05:41:51 <meph> whats the big holdup with s6 again?
2021-10-13 05:41:55 <Ariadne> i really do not want to do this, as it would justify "keeping" it in opposition to adopting s6
2021-10-13 05:42:03 <Ariadne> meph: s6-rc needs to be finished :)
2021-10-13 05:42:11 <meph> seems like creating service dirs wouldn't be that hard
2021-10-13 05:42:17 <meph> I think void just does that
2021-10-13 05:42:31 <Ariadne> alpine has a certain standard of user experience quality
2021-10-13 05:42:40 <Ariadne> openrc provides "good" UX, but is internally shit
2021-10-13 05:42:57 <Ariadne> s6-rc provides "this is a prototype" UX, but is internally good
2021-10-13 05:43:25 <ikke> see also https://skarnet.com/projects/service-manager.html
2021-10-13 05:43:55 <Ariadne> however, i do not see how we can depend on openrc upstream when gentoo can veto anything
2021-10-13 05:44:21 <Ariadne> alpine's attempts (amongst several developers) to work with openrc has largely been an effort in futility
2021-10-13 05:46:31 <meph> oh true
2021-10-13 05:47:14 <meph> i forgot that the order you start things in is important!!!
2021-10-13 05:47:20 <meph> i need to go to bed
2021-10-13 05:48:48 <Ariadne> yes, void solves that by scripting the process
2021-10-13 05:50:22 <Ariadne> basically, my issue here is that requiring tmpfiles.d as a solution effectively saddles Alpine with technical debt (as we're not going to import systemd for that, meaning we would have to write our own implementation), and that writing our own implementation means that we have to fight "fork control" efforts from systemd (there are no stable specifications for systemd functionality, so we will always be chasing it)
2021-10-13 05:51:34 <meph> how about a holdover where you just mount /tmp as a tmpfs early in one of the openrc init scripts
2021-10-13 05:52:41 <meph> bootmisc seems to already mess with /tmp
2021-10-13 05:59:20 <Ariadne> a fork, say LibreRC, would be spite-driven basically.  we're not the only distro treated as a second-class citizen.  there is a governance issue in OpenRC that direly needs resolution.
2021-10-13 06:01:02 <ikke> The question is if it's worth the effort if we basically already committed to switching away
2021-10-13 06:02:00 <Ariadne> well, we will need to provide compatibility for openrc services in an s6 world, at least for a while
2021-10-13 06:03:19 <Ariadne> it is likely that we will have more flexibility to achieve that in a fork, and there are other community users who would likely want to keep it going after we switch (like devuan)
2021-10-13 06:04:03 <Ariadne> maybe i should drop in on their weekly devuan community video chat and see what they think tomorrow
2021-10-13 06:06:25 <mps> if I'm not tired of repeating for about 3 years now, I would say 'switch to runit'
2021-10-13 06:08:59 <Ariadne> mps: alpine has a certain standard of user experience quality.  if you want to build an acceptable user experience on top of runit, then feel free to show us the code.
2021-10-13 06:10:21 <mps> :)
2021-10-13 06:12:37 <Ariadne> the key reason s6-rc is the viable replacement is because it is already being written, and skarnet has complete understanding of both the user-facing side and how the technical side should work
2021-10-13 06:14:38 <mps> I already told few months ago that I agree with switching to s6
2021-10-13 06:16:03 <mps> and there should 'go' our efforts (ofc, if someone have time to do this)
2021-10-13 06:17:46 <Ariadne> the blocker is that s6 is not ready for alpine
2021-10-13 06:18:05 <Ariadne> that's what the call for funding was about: getting s6 to a point where it is polished enough to replace OpenRC
2021-10-13 06:18:49 <Ariadne> i was hoping we could just bullshit our way through until s6 hits that level of readiness, and then dalias's box got rm -rf'd
2021-10-13 06:19:14 <Ariadne> and Gentoo has made it clear that despite whatever WilliamH has to say, OpenRC is actually a Gentoo project, yet again
2021-10-13 06:19:31 <Ariadne> so, now we need a solution *immediately*, because we can't just keep doing this again and again.
2021-10-13 06:19:55 <Ariadne> Gentoo must be divorced from Alpine's init system, and that must happen now.
2021-10-13 06:21:48 <mps> eh
2021-10-13 06:22:53 <mps> (don't want to go another philosophical thread)
2021-10-13 06:23:25 <Ariadne> well, like i said, it was fine enough, but Gentoo wants to keep this rm -rf for "performance" reasons, instead of preferring safety
2021-10-13 06:23:44 <mps> yes, this is bad, I agree
2021-10-13 06:23:46 <Ariadne> if Gentoo wants to rm -rf their users boxes, fine
2021-10-13 06:23:51 <Ariadne> but we don't want that
2021-10-13 06:25:09 <mps> iirc you have patch to fix this?
2021-10-13 06:29:19 <Ariadne> yes
2021-10-13 06:29:25 <skarnet> this is getting fucking ridiculous
2021-10-13 06:30:03 <skarnet> I'm in time off right now for health reasons but it really looks like people are making a mountain out of nothing
2021-10-13 06:30:09 <skarnet> the rm -rf thing is a script snippet
2021-10-13 06:30:25 <skarnet> why cannot it be patched in the apkbuild of openrc?
2021-10-13 06:30:42 <Ariadne> skarnet: we *can*, but it's not really *about that* at all
2021-10-13 06:30:56 <skarnet> then what is it about?
2021-10-13 06:31:03 <Ariadne> it's about the fact that governance issue outlined above
2021-10-13 06:31:20 <skarnet> the thing is, you need a temporary solution
2021-10-13 06:31:23 <Ariadne> s/fact that/
2021-10-13 06:31:25 <Ariadne> yes
2021-10-13 06:31:29 <skarnet> patching policy scripts is a temporary solution
2021-10-13 06:31:50 <Ariadne> it is a temporary solution, but there are other distributions being screwed by this governance issue
2021-10-13 06:31:53 <skarnet> given that openrc evolves with the speed of the average molasses after 3 days in a fridge
2021-10-13 06:32:02 <Ariadne> so i wonder if fixing the governance issue makes sense
2021-10-13 06:32:04 <skarnet> I think the temporary solution can hold out until s6-rc is ready
2021-10-13 06:32:27 <Ariadne> well, yes, but if we upgrade to openrc 0.45
2021-10-13 06:32:33 <Ariadne> then we will need systemd-tmpfiles
2021-10-13 06:32:39 <Ariadne> because that is how they plan to fix this
2021-10-13 06:32:52 <Ariadne> did you know systemd-tmpfiles supports regex?  that seems very safe
2021-10-13 06:33:06 <skarnet> > openrc
2021-10-13 06:33:17 <skarnet> > fix this by using a part of systemd
2021-10-13 06:33:27 <skarnet> yeah they're hopeless
2021-10-13 06:33:27 <mps> huh
2021-10-13 06:33:36 <skarnet> but still
2021-10-13 06:33:41 <skarnet> it's in Alpine power to patch it
2021-10-13 06:33:47 <skarnet> knowing that it is temporary
2021-10-13 06:33:57 <Ariadne> yes, but its in Alpine's power to also resolve the governance crisis
2021-10-13 06:34:09 <Ariadne> even in an s6 world, we will need to support some subset of OpenRC for legacy scripts
2021-10-13 06:34:16 <Ariadne> at least for a while
2021-10-13 06:35:31 <Ariadne> so, the question is, do we do that, or do we just patch and wait for the next decision point
2021-10-13 06:35:50 <Ariadne> we will eventually have to fork anyway, to do the compatibility glue
2021-10-13 06:36:13 <skarnet> compatibility glue?
2021-10-13 06:36:14 <Ariadne> just as fedora to this day still maintains a fork of their old init system to support systemd's compatibility glue
2021-10-13 06:36:57 <skarnet> you'll be able to run a whole openrc set of scripts as a s6-rc service
2021-10-13 06:37:18 <skarnet> so compatibility won't be an issue
2021-10-13 06:38:53 <Ariadne> yes, but to achieve that, openrc has to be somewhat lobomized
2021-10-13 06:39:02 <Ariadne> otherwise it will try to start openrc core servics up
2021-10-13 06:39:06 <Ariadne> services*
2021-10-13 06:39:13 <Ariadne> lobotomized*
2021-10-13 06:39:40 <skarnet> it's all policy scripts fortunately
2021-10-13 06:40:22 <skarnet> lobotomy is strip down the openrc runlevels to nothing
2021-10-13 06:40:27 <Ariadne> nope
2021-10-13 06:40:40 <Ariadne> /sbin/rc has some hardcoded stuff it runs before runlevels begin
2021-10-13 06:41:11 <Ariadne> so, some patching will be involved
2021-10-13 06:41:31 <skarnet> in the mechanism scripts/binaries? not everything is in /etc/init.d/stuff ?
2021-10-13 06:41:38 <Ariadne> correct
2021-10-13 06:41:52 <Ariadne> it also hardcodes calling certain /etc/init.d/foo start
2021-10-13 06:41:57 <Ariadne> in /sbin/rc
2021-10-13 06:42:02 <skarnet> yeah but that's not a problem
2021-10-13 06:42:08 <Ariadne> no, i don't know why they do that :)
2021-10-13 06:42:20 <Ariadne> i mean, none of this is a problem per se
2021-10-13 06:42:30 <Ariadne> the problem is the governance
2021-10-13 06:42:48 <skarnet> hardcoding stuff in /sbin/rc on the other hand is doubleslap-worthy
2021-10-13 06:43:03 <skarnet> never had to fiddle with that before which is why I didn't notice
2021-10-13 06:43:35 <Ariadne> so i think there are some value in organizing a fork
2021-10-13 06:43:52 <Ariadne> even if our trajectory is moving away from openrc as fast as possible
2021-10-13 06:44:27 <Ariadne> removing the hardcoded stuff in /sbin/rc without having to just patch it in alpine would be nice
2021-10-13 06:44:46 <Ariadne> there are likely other OpenRC distros which are tired of being second class citizens despite having more installs than Gentoo
2021-10-13 06:45:00 <Ariadne> Alpine is likely not the only distro in that boat
2021-10-13 06:45:04 <skarnet> true
2021-10-13 06:45:06 <Ariadne> TrueNAS i believe use OpenRC
2021-10-13 06:45:37 <skarnet> but then that should be a distro-independent (or at least cross-distro) initiative
2021-10-13 06:46:38 <Ariadne> yes, i am proposing organizing such a thing
2021-10-13 06:46:58 <Ariadne> because this can be Alpine's last "fuck you" on the way out the OpenRC door ;)
2021-10-13 06:47:29 <skarnet> well you know me
2021-10-13 06:48:06 <skarnet> I'm not interested in the politics aspect of it and to me the best fuck you is ignoring them and using something better
2021-10-13 06:48:32 <skarnet> I want to help with the technical aspect, don't much care about the rest
2021-10-13 06:49:27 <skarnet> but yeah, I now understand how terrible OpenRC has become and why the need to change/fork it is so pressing
2021-10-13 06:52:09 <Ariadne> skarnet: the other issue is that they don't care to support BusyBox anymore
2021-10-13 06:53:12 <skarnet> what are they going to do, use GNU options to cp ?
2021-10-13 06:53:18 <Ariadne> yes, actually.
2021-10-13 06:53:32 <skarnet> 
ACTION facepalms

2021-10-13 06:53:34 <Ariadne> we literally have patches which revert things like that :)
2021-10-13 06:54:46 <ericonr> 
ACTION goes look

2021-10-13 06:55:15 <ericonr> also the mips64 builder seems to be behind
2021-10-13 06:55:19 <ericonr> for edge
2021-10-13 06:57:16 <Ariadne> it got decommissioned
2021-10-13 06:57:31 <ericonr> ah that explains it
2021-10-13 06:58:03 <Ariadne> you can't buy new octeon mips64 processors anymore, and that was the only CPU we supported for the port
2021-10-13 06:59:20 <skarnet> tbh the lack of bb support doesn't bother me, it sounds like an Alpine specificity (I like it, but you can't enforce it on upstream)
2021-10-13 06:59:29 <skarnet> I wish they'd stick to posix tools though
2021-10-13 06:59:38 <skarnet> because a hard dependency on coreutils is ugh
2021-10-13 07:01:31 <mps> but with posix one doesn't have new and shiny features :) (I prefer posix ofc)
2021-10-13 07:02:52 <Ariadne> skarnet: well it is more like util-linux et al
2021-10-13 07:04:47 <skarnet> well tbh that's gonna be a problem for every package providing a complete policy set
2021-10-13 07:04:58 <skarnet> you need util-linux equivalents to boot a system
2021-10-13 07:05:29 <skarnet> choosing the dependency is on the policy script writer
2021-10-13 07:06:53 <Ariadne> no, what i mean is, some units were originally busybox compatible, but then a gentoo developer drove by and broke that compatibility simply because he couldn't be bothered to find out what the shortopt was
2021-10-13 07:07:27 <Ariadne> and again, this is a governance issue
2021-10-13 07:07:53 <skarnet> yeah I understand that, but in the absence of a spec for stuff like util-linux, I can't really blame people for a hard dep on util-linux
2021-10-13 07:08:08 <skarnet> it's different with GNU coreutils because posix has a spec
2021-10-13 07:08:10 <Ariadne> gentoo developers can change openrc at their whim, without any review
2021-10-13 07:08:24 <Ariadne> while if alpine or devuan want to change openrc, we have to send an MR
2021-10-13 07:08:43 <skarnet> I agree it's an issue for a multi-distro package
2021-10-13 07:08:44 <Ariadne> it's one world for gentoo, and another for everyone else
2021-10-13 07:08:51 <skarnet> absolutely agreed
2021-10-13 07:08:53 <skarnet> this is bad
2021-10-13 07:09:15 <Ariadne> and i think that alpine should, at least from our historical position of moral authority, set this right
2021-10-13 07:10:35 <Ariadne> even if openrc (or its fork) is deprecated in alpine ultimately
2021-10-13 07:10:46 <skarnet> historical position of moral authority? care to quote a precedent? :D
2021-10-13 07:11:00 <Ariadne> we have the weight and moral position to do it, and it would benefit all openrc users
2021-10-13 07:11:05 <Ariadne> skarnet: pkgconf i think is a good example
2021-10-13 07:11:39 <skarnet> pkgconf was a good change but I don't understand the moral implications?
2021-10-13 07:12:22 <skarnet> (I didn't follow closely what happened with pkgconf)
2021-10-13 07:12:26 <Ariadne> pkg-config was basically a GNOME-only club
2021-10-13 07:13:16 <skarnet> pkg-config users are gnomes, agreed
2021-10-13 07:14:06 <Ariadne> no, what i mean is, it was developed by GNOME people, and only did things GNOME people wanted changed
2021-10-13 07:14:21 <skarnet> yeah I got that :)
2021-10-13 07:15:37 <skarnet> but it only means that Alpine has (or more precisely in that case, you have) a history of providing less clubby replacements
2021-10-13 07:15:58 <Ariadne> i wrote pkgconf to solve a problem in Alpine, though
2021-10-13 07:16:21 <Ariadne> i *run* pkgconf as a distro-agnostic project, because it only makes sense
2021-10-13 07:16:33 <skarnet> yes
2021-10-13 07:17:03 <skarnet> so is that what you mean by moral authority? "I have proven I can provide a replacement that works better for all distros" ?
2021-10-13 07:17:20 <Ariadne> no, what i mean is that Alpine does not shy away from solving problems
2021-10-13 07:18:06 <skarnet> I agree with this sentiment, I can tell however that not everyone will see it under that light
2021-10-13 07:18:47 <skarnet> some will interpret it as "Alpine can't mind its business and has to come step on our flowerbeds"
2021-10-13 07:19:25 <skarnet> and invoking moral authority is likely to make them stiffen more than anything else
2021-10-13 07:19:31 <Ariadne> OpenRC *is* our business, as Alpine is the largest install base of OpenRC
2021-10-13 07:21:49 <Ariadne> and to some extent, there's already people who hate on alpine
2021-10-13 07:21:52 <Ariadne> *shrug*
2021-10-13 07:22:40 <PJ[m]> can confirm
2021-10-13 07:26:26 <Ariadne> this is also why, to some extent, i can sympathize personally with lennartp
2021-10-13 07:26:46 <Ariadne> even if i disagree with the technical design of systemd
2021-10-13 07:27:35 <skarnet> I'm sure that pointing out other distro's deficiencies and bulldozing through their governance issues has nothing to do with the fact that some people hate Alpine :D
2021-10-13 07:28:16 <skarnet> and I don't see the comparison with lennartp here
2021-10-13 07:28:27 <skarnet> what you do is for the good of the ecosystem as a whole
2021-10-13 07:28:48 <Ariadne> well, he sees himself as trying to do the same i assume
2021-10-13 07:28:51 <skarnet> what he does is for the supremacy of systemd regardless of the consequences
2021-10-13 07:29:55 <skarnet> I have little empathy for tyrants with great ideals
2021-10-13 07:31:20 <skarnet> (and you, Ariadne, are a bully, but not a tyrant XD)
2021-10-13 07:34:04 <Ariadne> i don't try to be a bully, even if i am sometimes blunt
2021-10-13 07:35:32 <skarnet> oh, you are, without trying :P
2021-10-13 07:35:52 <skarnet> I don't mind as long as the end result for the ecosystem is positive
2021-10-13 07:38:01 <Ariadne> to me a bully is somebody who punches down.  i try to, at least from how i see it, punch up.
2021-10-13 07:38:29 <skarnet> given your position, you're mostly punching sideways
2021-10-13 07:41:41 <Ariadne> sometimes, that too, is necessary
2021-10-13 07:42:07 <skarnet> qed :D
2021-10-13 08:06:05 <maribu> Ariadne: Any luck so far with resolving the dependency loop for vlan's in ifupdown-ng?
2021-10-13 08:06:19 <Ariadne> have not had time to dig into it
2021-10-13 10:53:49 <ikke> Ariadne: you added diffutils as checkdepends to m4 in dd4e68704e077c27cd2b20a7e15cdea61d8f8b97 to reconcile dependencies between adelie-base and alpine-base
2021-10-13 10:54:28 <ikke> That dependency causes a cyclic dependency atm (m4 -> diffutils -> coreutils -> bash -> bison -> flex -> m4)
2021-10-13 10:55:39 <ikke> Hmm
2021-10-13 10:55:41 <ikke> e873461813d56ceac8622701bf1a4f79bd1fa8f2 is more recent
2021-10-13 11:09:53 <ktprograms> Should there be post-install/post-uninstall scripts that echo installation instructions? (e.g. the capitaine-cursors package needs you to either use lxappearance or manually set the default cursor theme)
2021-10-13 11:10:36 <ktprograms> This could also be needed e.g. for qemu-vdagent if you're using openbox so the .desktop file isn't used and you have to add it to the openbox autostart.
2021-10-13 11:11:08 <mps> ktprograms: no, alpine doesn't like echo in pre/post install
2021-10-13 11:11:35 <mps> alpine is not ubuntu (yet)
2021-10-13 11:13:20 <ktprograms> mps: Then how/where should post-installation instructions that might only apply to some people be put?
2021-10-13 11:13:30 <Misthios> *prepares for 999 alpine spinoffs with their own spinoffs*
2021-10-13 11:14:00 <mps> readme.txt
2021-10-13 11:14:45 <ktprograms> mps: Where?
2021-10-13 11:15:10 <mps>  /usr/share/doc/pkgname/readme.txt
2021-10-13 11:15:40 <ktprograms> mps: So a post-install script that writes that there?
2021-10-13 11:15:49 <psykose> people usually know that you need to change the cursor theme via variable or whatever
2021-10-13 11:15:59 <psykose> i don't think anyone expects an installed cursor theme to be auto applied
2021-10-13 11:16:27 <ktprograms> I wasn't suggesting auto applying, just instructions on how to apply it
2021-10-13 11:16:30 <psykose> and every cursor theme usually works the same way, no? it's just some files in usr/share, and updated however is right for your DE setup
2021-10-13 11:16:33 <mps> ktprograms: you can add readme.txt in pkg and don't need post install to manipulate it
2021-10-13 11:16:54 <psykose> yes, but every cursor theme ever has the same instructions, it doesn't make sense to have it in every cursor package with the same thing
2021-10-13 11:17:04 <psykose> and then you would want to put instructions for every DE settings panel ever made
2021-10-13 11:17:04 <ktprograms> psykose: ok makes sense
2021-10-13 11:17:34 <psykose> for me for instance i set it in sway config and also XCURSOR_THEME, i'm sure everyone else has their own little way for their setup
2021-10-13 11:17:46 <psykose> or no, i think the former sets the latter anyway
2021-10-13 11:18:02 <psykose> yep
2021-10-13 11:29:30 <clandmeter> ktprograms: we do not have a proper interface for post-install/uninstall
2021-10-13 11:29:40 <clandmeter> for messages that is
2021-10-13 11:44:02 <clandmeter> for example, if you run from ram, every boot will display them.
2021-10-13 11:55:47 <donoban> clandmeter: maybe it could difference if it's running interactive or automically or just have a '--silent' option
2021-10-13 11:57:01 <clandmeter> you would still not see it on some screens as the message would be gone when there are a lot of packages to install/update
2021-10-13 11:58:01 <clandmeter> maybe fabled will add a feature in the new apk tools
2021-10-13 12:04:56 <donoban> ah it could be an scrollable message like 'less readme.txt' and the user needs to press some key for continue, useful also for security updates that require some aditional tasks, of course if the user wants a automated/non-interactive process this messages should be sent in some non interrupting way like mail 
2021-10-13 12:21:16 <mps> use ubuntu, and this is solved :D
2021-10-13 12:23:29 <donoban> don't you like to get extra information on install/upgrade process?It's not something critical yes but ....
2021-10-13 12:24:02 <mps> no, quiet install/upgrade is best
2021-10-13 12:25:09 <mps> only errors should be displayed
2021-10-13 12:25:14 <donoban> if there is nothing more that you should do/know yes, but sometimes there are exceptions, secfixes wich need configuration changes or something like that
2021-10-13 12:26:13 <mps> these are totally different mindsets, and we can't have both at same time
2021-10-13 12:27:36 <donoban> it's only errors or errors 
2021-10-13 12:27:40 <donoban> && warnings :D
2021-10-13 12:28:20 <mps> 'no news is good news'
2021-10-13 12:28:59 <donoban> yep I admit that this system could be abussed or spammed wich too much unneeded info
2021-10-13 12:29:32 <donoban> time for have lunch, see you :)
2021-10-13 12:30:11 <mps> yes, I would add in post install 'enjoy my new $pgname with a lot of shiny features' :D
2021-10-13 12:30:37 <mps> and in post upgrade, ofc
2021-10-13 12:30:51 <mps> $pkgname*
2021-10-13 12:49:42 <ktprograms> I think the spice-webdavd package should have avahi as a dependency instead of just avahi-glib since the OpenRC init script is in the avahi package.
2021-10-13 12:53:05 <ktprograms> (And the avahi-daemon is needed for webdav to work)
2021-10-13 12:54:15 <ktprograms> https://packages.ubuntu.com/focal/spice-webdavd see the dependency on avahi-daemon (Alpine doesn't have a separate avahi-daemon only package)
2021-10-13 14:54:30 <bl4ckb0ne> build-armhf and build-aarch64 seems stuck
2021-10-13 15:29:04 <nmeum> andypost[m]: regarding icu rebuild: I really don't think that we need to address all issues on the CI, we can also fix stuff when it fails on the builders. looks to me like almost all packages in main/ and community/ now pass build & test with the new icu-69.1, right?
2021-10-13 15:29:35 <mps> nmeum: +1
2021-10-13 15:30:18 <andypost[m]> nmeum: yes, exaclty
2021-10-13 15:30:34 <nmeum> we also need icu 69.1 badly to upgrade firefox which fixes quite a few CVEs with high impact
2021-10-13 15:30:50 <ikke> I'm currently bootstrapping the builders. Does the ICU upgrade affect anything in the early bootstrap / toolchain/
2021-10-13 15:31:14 <ikke> Reminds me, I should send an e-mail about the toolchain feature frreze
2021-10-13 15:31:16 <ikke> freeze*
2021-10-13 15:31:21 <nmeum> andypost[m]: so how do we move forward with this then?
2021-10-13 15:31:36 <nmeum> ikke: we really need icu 69.1 in 3.15
2021-10-13 15:31:43 <ikke> nmeum: yes, I understand
2021-10-13 15:31:59 <ikke> But it should be done sooner rather than later
2021-10-13 15:32:07 <nmeum> yes exactly
2021-10-13 15:32:10 <mps> if something depends on icu in base it shouldn't
2021-10-13 15:32:36 <nmeum> IMHO we can just bump icu today
2021-10-13 15:32:40 <nmeum> rebuild everything that depends on it
2021-10-13 15:32:48 <nmeum> and fix the remaining issues on the builders
2021-10-13 15:32:58 <andypost[m]> nmeum: I think it needs someone to pull a trigger and start merge it
2021-10-13 15:33:27 <mps> nmeum: I agree, and I proposed exatly this a week or more ago
2021-10-13 15:33:46 <andypost[m]> I bet only seamonkey will fail
2021-10-13 15:34:08 <mps> seamonkey should be removed from aports, imo
2021-10-13 15:34:35 <nmeum> andypost[m]: which script did you use to identify packages which need to be rebuild?
2021-10-13 15:34:44 <andypost[m]> also it needs to upgrade firefox&co after commit, iirc old version won't build with new icu
2021-10-13 15:34:53 <nmeum> that's fine we need to upgrade firefox anyhow
2021-10-13 15:35:14 <ikke> And what will llvm12 affect?
2021-10-13 15:35:42 <mps> I already tested build FF with icu upgraded on x86_64, aarch64 and armv7
2021-10-13 15:35:47 <Hello71> seamonkey was already removed
2021-10-13 15:36:02 <Hello71> i moved it to unmaintained because it was unmaintained
2021-10-13 15:36:04 <mps> Hello71: ah, good
2021-10-13 15:36:08 <nmeum> nice
2021-10-13 15:36:18 <andypost[m]> nmeum: I bet https://tpaste.us/dP88
2021-10-13 15:36:26 <Hello71> no security updates for months, not acceptable for browser
2021-10-13 15:36:37 <Hello71> in alpine i mean, upstream is ok afaict
2021-10-13 15:36:51 <mps> ikke: llvm12 is not important for 3.15 so much
2021-10-13 15:36:55 <ikke> Ok
2021-10-13 15:37:17 <Hello71> imo llvm12 will make our lives easier if it comes with working sanitizers
2021-10-13 15:37:33 <mps> 'we' can release 3.15  without llvm12 upgrade, it is not critical
2021-10-13 15:37:38 <nmeum> Hello71: we should also move chromium from community/ back to testing/ for the same reason I think
2021-10-13 15:37:51 <Hello71> i guess
2021-10-13 15:37:59 <mps> nmeum: agree again
2021-10-13 15:38:17 <nmeum> but first things first: how is "pulling the trigger" on the icu upgrade? :D
2021-10-13 15:38:23 <nmeum> s/how/who/
2021-10-13 15:38:50 <mps> andypost[m]: ?
2021-10-13 15:39:10 <andypost[m]> I could rebase main
2021-10-13 15:39:30 <mps> remove upgrade for pg and I will risk
2021-10-13 15:39:36 <ikke> main is the most important right now
2021-10-13 15:41:15 <nmeum> I think it is actually easier to have someone with push access to main/, community/ and testing/ apply the icu upgrade and bump packages which need rebuilds locally with a script, no?
2021-10-13 15:41:17 <andypost[m]> pushed rebase !14092 , I thing PG will pass fine as I did rebuild it few times on different arches
2021-10-13 15:41:21 <nmeum> instead of rebasing the PRs all the time
2021-10-13 15:45:28 <nmeum> andypost[m]: is !14092 still WIP or is it ready?
2021-10-13 15:47:10 <psykose> doesn't it break edge in the meantime if it gets merged but before community gets rebuilt against it
2021-10-13 15:47:19 <psykose> aside from that it should be fine if all the main rebuilds pass
2021-10-13 15:48:52 <andypost[m]> nmeum: ready for sure, removed draft
2021-10-13 15:49:24 <nmeum> psykose: yes, we need to rebuild community and testing too
2021-10-13 15:50:09 <mps> psykose: edge usually breaks in freeze time
2021-10-13 15:50:33 <psykose> of course :)
2021-10-13 15:50:56 <ikke> Would be nice if someone else can handle ICU, then I can handle bootstrapping the builders
2021-10-13 15:51:35 <nmeum> I am currently debugging a go issue on ppc64le, might be able to handle icu after
2021-10-13 15:51:36 <andypost[m]> I see PureTryOut updated community and testing !24903 !24901
2021-10-13 15:54:09 <ikke> hmm, why does aports-build indirectly require ruby..
2021-10-13 16:02:15 <psykose> doesn't seem to pull it in for me
2021-10-13 16:02:41 <ikke> Sorry, I mean as makedepend
2021-10-13 16:02:46 <ikke> builddep
2021-10-13 16:03:03 <ikke> ap recusrive-deps aports-build returns ruby
2021-10-13 16:03:50 <psykose> ah
2021-10-13 16:07:03 <psykose> mosquitto-dev > util-linux-dev > asciidoctor > ruby
2021-10-13 16:07:17 <ikke> psykose: ah, thank you
2021-10-13 16:57:02 <nmeum> ikke: just checking: you agree that we shoudl upgrade icu now, yes?
2021-10-13 16:57:34 <ikke> Yes
2021-10-13 16:58:12 <nmeum> ok, I will just push it then
2021-10-13 16:58:25 <ikke> 👍
2021-10-13 16:58:34 <nmeum> just regenerating rebuilds using: for pkg in $(ap revdep icu-dev); do apkgrel -a $pkg; done
2021-10-13 16:58:38 <nmeum> that should be sufficient, right?
2021-10-13 16:59:02 <ikke> yes, afaik that should be
2021-10-13 16:59:14 <nmeum> ok
2021-10-13 17:00:41 <ikke> opinion on !26399
2021-10-13 17:01:23 <nmeum> pushed the icu rebuild
2021-10-13 17:01:27 <nmeum> if you see something, say something
2021-10-13 17:02:59 <andypost[m]> thank you! 🤞
2021-10-13 17:04:03 <nmeum> thank your doing the hard work! (:
2021-10-13 17:04:06 <nmeum> s/your/you/
2021-10-13 17:04:09 <nmeum> *for
2021-10-13 17:04:19 <psykose> ikke: isn't install $install_man an error when $install_man is empty during bootstrap
2021-10-13 17:04:54 <PureTryOut> icu 69.1 😱 yes!
2021-10-13 17:04:55 <ikke> psykose: it was when I uses "$install_man", but it worked without quotes
2021-10-13 17:05:06 <andypost[m]> now only ffi left in my list!!!
2021-10-13 17:05:27 <PureTryOut> Hopefully we can get a Firefox upgrade in too now
2021-10-13 17:05:44 <nmeum> ikke: the problem with this is: the bootstrap stuff only gets tested when someone does a bootstrap, so we don't notice if it breaks during updates or general changes of an apkbuild
2021-10-13 17:05:52 <nmeum> PureTryOut: yes, I also want the new firefox
2021-10-13 17:05:55 <ikke> nmeum: yes, I'm aware
2021-10-13 17:06:19 <psykose> ikke: hm, okay, seems to exit 1 for me with any empty argument
2021-10-13 17:06:26 <psykose> is it not the busybox install that runs
2021-10-13 17:06:42 <nmeum> ikke: but that's why I would be reluctant to add stuff that only runs if $BOOTSTRAP is set
2021-10-13 17:06:59 <ikke> psykose: it's part of the make command
2021-10-13 17:07:04 <psykose> ah right
2021-10-13 17:07:17 <psykose> all good then, looks good
2021-10-13 17:08:40 <ikke> nmeum: We could schedule a monthly job that tries to bootstrap build-base + abuild + aports-build
2021-10-13 17:09:33 <nmeum> not sure if that would be worth it
2021-10-13 17:11:47 <ikke> setting up new builders does benefit from reducing the amount of packages being built
2021-10-13 17:12:07 <nmeum> yes, I agree
2021-10-13 17:12:31 <ikke> Currently 396 packages that need to be built
2021-10-13 17:12:54 <nmeum> I think the MR you linked is as good as it gets currently to reduce bootstrap dependencies
2021-10-13 17:13:20 <ikke> https://tpaste.us/41Lj
2021-10-13 17:13:41 <psykose> three-hundred ninety-six
2021-10-13 17:13:47 <nmeum> in an ideal word we would have some sort of per-package build mode I suppose? basically what gentoo does with ebuild feature flags, but we don't have that so I guess your MR is fine as is :)
2021-10-13 17:13:48 <ikke> perl cannot be removed, but python and ruby are not necessary
2021-10-13 17:13:50 <ikke> psykose: exactly
2021-10-13 17:14:10 <ikke> nmeum: And it follows a pattern that is already used (see util-linux)
2021-10-13 17:17:04 <Hello71> USE flags, FEATURES are different
2021-10-13 17:17:16 <Hello71> and gentoo got it from bsd ports
2021-10-13 17:18:08 <psykose> the way use flags are used doesn't seem to be very useful here, it would just be a single flag (bootstrap) and do the same as the if bootstrap checks already
2021-10-13 17:18:41 <ikke> Anothing thing that would need to be done before bootstrapping 3.15 is reverting everything to openssl1.1 again
2021-10-13 17:20:45 <nmeum> psykose: well technically you would probably have something like build git with python support (+python) and build git with tcl support (+tcl) and bootstrap would be "git -tcl -python" but as I said we don't have build modes anyhow
2021-10-13 17:22:13 <psykose> ah, yeah, but those wouldn't be useful to package separately... and they would only exist like that for the bootstrapping stage, so those flags would only be used for the equivalent of +- bootstrap
2021-10-13 17:22:40 <psykose> e.g. the only time -python git gets built is for bootstrap, so really it's just a +bootstrap per package
2021-10-13 17:23:10 <nmeum> probably yes
2021-10-13 17:24:18 <nmeum> I approved the MR
2021-10-13 17:31:33 <ikke> make[2]: *** [src/libical-glib/CMakeFiles/valafile.dir/build.make:74: src/libical-glib/libical-glib.vapi] Bus error
2021-10-13 17:33:03 <psykose> too many passengers on the bus
2021-10-13 17:43:28 <ikke> What was the plan in reverting openssl? Just make everything depend on openssl1.1-compat?
2021-10-13 17:44:10 <andypost[m]> iirc there was idea to rollback to 1.x as default
2021-10-13 17:44:25 <nmeum> I think Ariadne was working on that but not sure what the current status is
2021-10-13 17:45:20 <andypost[m]> I suppose the main blocker is https://bugs.openldap.org/show_bug.cgi?id=9436
2021-10-13 17:46:46 <ikke> mariadb, apk-tools
2021-10-13 17:46:54 <ikke> those are the main reasons to roll back
2021-10-13 17:48:10 <andypost[m]> anybody explored idea to create openssl3.0-deprecated package?
2021-10-13 17:48:30 <ikke> I would not call it deprecated
2021-10-13 17:48:45 <andypost[m]> obsolete works too)
2021-10-13 17:48:53 <ikke> Why not just openssl3.0?
2021-10-13 17:50:04 <andypost[m]> I mean there's deprecations in 3.0 additionally to 1.1
2021-10-13 17:50:58 <ikke> andypost[m]: Oh, I guess I'm misunderstanding you
2021-10-13 17:52:26 <andypost[m]> https://www.openssl.org/docs/man3.0/man7/migration_guide.html#Deprecation-of-Low-Level-Functions
2021-10-13 17:54:20 <andypost[m]> so openssl could be 3.0 but additional "-depreecated" will be provided for ones that still using it
2021-10-13 17:57:12 <ikke> andypost[m]: were / are you working on ffi?
2021-10-13 18:02:51 <Hello71> andypost[m]: what would the differences be exactly?
2021-10-13 18:06:36 <ikke> I guess allowing packages to use openssl3.0 while still relying on deprecated functionality?
2021-10-13 18:30:31 <ikke> hmm, llvm10 fails to build, possibly due to GO111MODULES
2021-10-13 18:30:56 <ikke> (rather, as test failure)
2021-10-13 18:54:58 <nmeum> mps: do you already have firefox-92.0.1 ready?
2021-10-13 18:56:03 <nmeum> I think the old firefox doesn't build with new icu so now would be an opportune time to upgrade it ;)
2021-10-13 18:57:42 <nmeum> firefox-esr also needs to be upgrade to 91.X
2021-10-13 18:59:35 <mps> nmeum: yes, but I testing build once again
2021-10-13 18:59:57 <mps> I hope it will finish in 20-30 minutes
2021-10-13 19:00:28 <nmeum> nice, thanks!
2021-10-13 19:01:04 <mps> oh no
2021-10-13 19:01:11 <mps> this time it failed
2021-10-13 19:01:24 <mps> something with python traceback
2021-10-13 19:01:50 <mps> and I don't know python, so this have to be done by someone else
2021-10-13 19:02:10 <mps> I could just post patch
2021-10-13 19:02:49 <mps> shit, it is no space on device actually
2021-10-13 19:02:57 <ikke> where?
2021-10-13 19:02:59 <mps> s/shit//
2021-10-13 19:03:17 <mps> ikke: x86_64 dev lxc
2021-10-13 19:03:34 <ikke> so nld5 I suppose
2021-10-13 19:04:25 <mps> I think so
2021-10-13 19:05:00 <ikke> 4G free, hmm
2021-10-13 19:05:23 <mps> FF needs a lot of space
2021-10-13 19:06:11 <mps> ok, I cleaned /var/cache
2021-10-13 19:06:26 <mps> now there is 7.7G free
2021-10-13 19:06:46 <ikke> I only see 4.6G free?
2021-10-13 19:06:54 <mps> lets try again
2021-10-13 19:07:42 <ikke> 22G
2021-10-13 19:07:48 <ikke> I deleted my distfiles as well
2021-10-13 19:08:56 <ikke> 28G now
2021-10-13 19:08:59 <psykose> 22 is fine if it's in memory builds
2021-10-13 19:09:02 <mps> so I'm not main abuser ;)
2021-10-13 19:09:32 <andypost[m]> ikke: Hello71: it's ready as ghc unblocked !24886
2021-10-13 19:10:24 <ikke> andypost[m]: ah, good, then I can stop
2021-10-13 19:12:19 <ikke> algitbot: so only main I see?
2021-10-13 19:12:24 <ikke> andypost[m]: *
2021-10-13 19:17:01 <andypost[m]> there's sub-MRs)
2021-10-13 19:17:04 <ikke> mps: 60G free now :D
2021-10-13 19:17:14 <ikke> andypost[m]: ok, good
2021-10-13 19:17:22 <nmeum> andypost[m]: how did you determine rebuilds for the libffi mr?
2021-10-13 19:17:54 <nmeum> you have to use `apk search -r so:libffi.so.7` if you use ap revdep you will not catch packages that have transitive dependencies on libffi
2021-10-13 19:18:00 <andypost[m]> 2 ways: script for bump and checksing via apk search -d
2021-10-13 19:18:10 <mps> ikke: I expect more when FF finish build
2021-10-13 19:18:57 <andypost[m]> nmeum: for ffi -r so: is enough, icu used to provide 4 .so to check
2021-10-13 19:19:20 <nmeum> yeah, for icu you have to do `apk search -r icu-libs`
2021-10-13 19:19:39 <ikke> apk info -r so:libffi.so.8 -> no output :(
2021-10-13 19:20:12 <nmeum> .so.7, .so.8 is the new soname
2021-10-13 19:20:28 <andypost[m]> https://tpaste.us/qPqz
2021-10-13 19:20:37 <ikke> oh yes, doesn't help that I already upgraded it in my container
2021-10-13 19:21:09 <andypost[m]> and "s/info/search" 
2021-10-13 19:22:29 <ikke> info -r is rdepends
2021-10-13 19:24:14 <ikke> So do we want to merge libffi now, or wait until icu is built / fixed
2021-10-13 19:24:48 <andypost[m]> ikke: info searching only in installed
2021-10-13 19:25:56 <ikke> Not with other options
2021-10-13 19:26:04 <ikke> apk info -R libffi works, even if it's not installed
2021-10-13 19:26:23 <andypost[m]> hm,... strange
2021-10-13 19:26:38 <andypost[m]> ok, let me check the state of ffi
2021-10-13 19:26:52 <andypost[m]> iirc ghc update could wait
2021-10-13 19:28:53 <andypost[m]> ffi MRs needs rebase/rebuid
2021-10-13 19:29:23 <ikke> do you think the rebuild is required, or could we just merge?
2021-10-13 19:29:42 <andypost[m]> there's merge conflicts with icu(
2021-10-13 19:30:06 <ikke> possibly version bumps against the same packages
2021-10-13 19:30:12 <andypost[m]> bumps the same aports
2021-10-13 19:30:14 <ikke> yeah
2021-10-13 19:30:26 <andypost[m]> asnd a lot
2021-10-13 19:30:40 <andypost[m]> better to to regenerate
2021-10-13 19:31:07 <ikke> Yeah, probably easier
2021-10-13 19:31:28 <andypost[m]> is there abump-ng?
2021-10-13 19:31:37 <ikke> not that I'm aware of
2021-10-13 19:31:43 <ikke> what would it add?
2021-10-13 19:39:47 <andypost[m]> search for bumps via "-dev" and "-libs"
2021-10-13 19:41:59 <nmeum> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10033
2021-10-13 19:42:16 <nmeum> I think we should just add that rebuild script I posted in this issue to abuild.git
2021-10-13 19:43:06 <nmeum> since it reads packages from stdin in works with both `apk search -r foo-libs` and `apk search -r so:libfoo.so.N`
2021-10-13 19:43:11 <nmeum> s/in/it/
2021-10-13 19:59:48 <Ariadne> 5:53 AM <ikke> Ariadne: you added diffutils as checkdepends to m4 in dd4e68704e077c27cd2b20a7e15cdea61d8f8b97 to reconcile dependencies between adelie-base and alpine-base
2021-10-13 19:59:55 <Ariadne> is that a problem?
2021-10-13 19:59:57 <ikke> Ariadne: no
2021-10-13 20:00:13 <ikke> Later diffutils checks were enabled
2021-10-13 20:01:14 <ikke> Ariadne: any idea when you can handle the openssl1.1 revert? nopca asked me to setup the builders, but that cannot happen before openssl is handled
2021-10-13 20:01:31 <Ariadne> going to work on it tonight
2021-10-13 20:01:38 <ikke> alright
2021-10-13 20:01:42 <Ariadne> finally starting to get over whatever this crud i had was
2021-10-13 20:02:20 <ikke> final question, do you have any objection against !26399?
2021-10-13 20:03:06 <ikke> that should remove python + ruby from the initial bootstrap process
2021-10-13 20:05:57 <andypost[m]> ikke: i did rebuild of 3 MRs for libffi, testing for community and testing makes no sense without main so CI canceled
2021-10-13 20:06:08 <ikke> Right 
2021-10-13 20:12:40 <ikke> ugh, apparently checkpath --directory does not like if the directory name ends with a / :/
2021-10-13 20:15:10 <ikke> Hmm, any clue what can cause 2 'sleep 60' processes to be spawned that are paused (need to send SIGCONT). I started to notice that on the builders lately
2021-10-13 20:17:04 <nmeum> well, they probably received a SIGSTOP at some point
2021-10-13 20:17:27 <ikke> nmeum: Yes, I did get that far :)
2021-10-13 20:17:30 <nmeum> maybe this is part of some software test suite?
2021-10-13 20:17:55 <ikke> Yes, that would be my guess as well
2021-10-13 20:30:23 <andypost[m]> ikke: ffi-main CI should finish in ~2hrs
2021-10-13 20:30:42 <ikke> Then I'll be 💤
2021-10-13 20:31:06 <andypost[m]> 110 commits behind it was green)
2021-10-13 20:31:27 <ikke> yeah, I don't think it'll be an issue
2021-10-13 20:31:37 <ikke> But I guess we better wait for the current builds to finish?
2021-10-13 20:31:43 <nmeum> maybe it makes sense to wait for icu rebuild anyhow?
2021-10-13 20:31:49 <ikke> exactly
2021-10-13 20:32:59 <Ariadne> ikke: its okay, future OpenRC versions will remove checkpath entirely, as systemd-tmpfiles does everything they need from checkpath :D
2021-10-13 20:33:29 <ikke> sigh
2021-10-13 20:34:38 <Ariadne> i now regret opening openrc bug #458
2021-10-13 20:34:55 <ikke> I guess that's the openrc issue #
2021-10-13 20:34:59 <Ariadne> yes
2021-10-13 20:36:35 <psykose> better to know than not know
2021-10-13 20:37:12 <psykose> should throw a patch that removes rm -rf at alpine openrc already
2021-10-13 20:37:32 <dalias> also btw..
2021-10-13 20:37:48 <dalias> having it governed by a file in /etc/ seems like a really bad idea
2021-10-13 20:38:00 <dalias> because if the default is to rm -rf and you need a config file to turn that off...
2021-10-13 20:38:07 <dalias> if somehow the config file got lost, it will fallback to rm -rf'ing
2021-10-13 20:38:21 <Ariadne> psykose: i already have a patch that does that.  it will be addressed in alpine openrc 0.44.7-r0
2021-10-13 20:38:26 <dalias> it should always fail-safe not fail-rm'ing
2021-10-13 20:38:29 <psykose> it should be the opposite if anything
2021-10-13 20:38:30 <psykose> yeah
2021-10-13 20:38:53 <Ariadne> yes, i tried to explain that, and even convinced WilliamH
2021-10-13 20:38:58 <Ariadne> and then gentoo showed up and vetoed it anyway
2021-10-13 20:39:06 <Ariadne> which is always what happens
2021-10-13 20:39:09 <dalias> ...
2021-10-13 20:39:30 <psykose> reading that thread was not very fun
2021-10-13 20:40:24 <psykose> it actually was so not fun, i ordered a new m.2 ssd to remove gentoo from my laptop, lol
2021-10-13 20:40:59 <dalias> :-p
2021-10-13 20:42:00 <psykose> spite is bad but also feels good, so maybe it's not so bad :p
2021-10-13 20:42:18 <Ariadne> when gentoo masked XMMS and told people to use audacious instead, i got stalked by this diaper-wearing furry who used to send me detailed e-mails and IRC messages about how he was going to brutally murder me
2021-10-13 20:42:36 <psykose> did you even have any say at all in their decision
2021-10-13 20:42:42 <psykose> that sounds like something gentoo did themselves
2021-10-13 20:42:43 <Ariadne> gentoo also switched to pkgconf before it was ready for primetime and slammed me with tons of bugs
2021-10-13 20:42:48 <Ariadne> yes, no say at all
2021-10-13 20:42:51 <psykose> classic
2021-10-13 20:43:15 <psykose> i do wonder why they did the pkgconf switch though
2021-10-13 20:43:26 <psykose> i wasn't around back then, was there some major pkg-config issues at the time
2021-10-13 20:43:39 <psykose> for people to want to jump /that/ badly
2021-10-13 20:43:39 <Ariadne> there were a few major reasons why pkgconf needed to be done
2021-10-13 20:43:43 <Ariadne> from distro perspective
2021-10-13 20:44:02 <Ariadne> 1. pkg-config sysroot support is totally unrealistic, you have to modify every .pc to make use of it
2021-10-13 20:44:42 <Ariadne> 2. pkg-config quit bundling a copy of glib, so suddenly you needed pkg-config to build pkg-config, as you needed pkg-config to build glib
2021-10-13 20:46:05 <psykose> that does not sound very fun
2021-10-13 20:46:40 <dalias> i still dont get why pkg-config couldn't be like a 50-line shell script :-p
2021-10-13 20:46:45 <Ariadne> 3. pkg-config does not actually perform dependency resolution, it just checks for problems after the fact, which means that there are a lot of edge cases that glitch it
2021-10-13 20:46:54 <dalias> grep the right CFLAGS and LDFLAGS and stuff out of the .pc file and echo them :)
2021-10-13 20:47:02 <Ariadne> dalias: the dependency resolution is why
2021-10-13 20:47:10 <dalias> for me not performing dependency resolution is a feature :)
2021-10-13 20:47:26 <Ariadne> dependency resolution is central to pkg-config
2021-10-13 20:47:41 <eris[m]> slackware user spotted in the wild??
2021-10-13 20:47:58 <dalias> my understanding of it (as used) is that it's jusst to print the right -l -L and -I options needed to compile & link against a library
2021-10-13 20:48:12 <dalias> i dont understand why it needs any dep resolution to do that
2021-10-13 20:48:46 <dalias> (also the -L and -I parts should be a nop because the library should already be in the path for your sysroot :)
2021-10-13 20:48:53 <Ariadne> because people supply `pkg-config gtk+-3.0 --cflags --libs`, and need the cflags for glib, atk, etc
2021-10-13 20:49:58 <Ariadne> ordering is also important, especially with stuff like `-Wl,--as-needed`
2021-10-13 20:51:01 <Ariadne> if `-lglib` comes before `-lgtk` then as-needed will skip over the glib dependency for gtk
2021-10-13 20:52:54 <Ariadne> i mean, let me put it this way
2021-10-13 20:53:02 <Ariadne> if i designed it, there wouldn't be dependency resolution
2021-10-13 20:53:13 <Ariadne> the goal of pkgconf was to make bootstrap.sh less painful
2021-10-13 20:54:33 <psykose> i dunno, being able to do -lgtk and not need to pass 20 -l's yourself is not the worst feature to want in something to make your life easier
2021-10-13 20:55:04 <Ariadne> its the cflags
2021-10-13 20:55:09 <Ariadne> moreso than the libs
2021-10-13 20:55:09 <psykose> or er, not -lgtk but pkgconf --libs --cflags gtk
2021-10-13 20:55:15 <psykose> yea
2021-10-13 21:07:50 <PJ[m]> can package be built/shipped with own version of dependency? e.g. Ruby
2021-10-13 21:08:19 <dalias> unless i misunderstand the question i think not
2021-10-13 21:09:10 <PJ[m]> I'm looking at Vagrant and they specifically don't want others to use system version of Ruby 🤔
2021-10-13 21:09:26 <PJ[m]> "Do NOT use the system Ruby - use a Ruby version manager like rvm or chruby"
2021-10-13 21:12:36 <PJ[m]> "Beware of system package managers! Some operating system distributions include a vagrant package in their upstream package repos. Please do not install Vagrant in this manner. Typically these packages are missing dependencies or include very outdated versions of Vagrant. If you install via your system's package manager, it is very likely that you will experience issues. Please use the official installers on the downloads page."
2021-10-13 21:14:13 <psykose> ignore all of this :)
2021-10-13 21:14:46 <psykose> their releases are also very infrequent
2021-10-13 21:14:59 <PJ[m]> cool
2021-10-13 21:15:00 <dalias> yeah, that's redflag behavior by an upstream
2021-10-13 21:15:28 <Saijin_Naib[m]> Ariadne: What the fuck with that creep, first of all, but why would they mask XMMS? As an aside, is that one of your projects?
2021-10-13 21:15:31 <dalias> "bypass your distro and download our binaries" is behavior indistinguishable from malware :)
2021-10-13 21:15:45 <Ariadne> Saijin_Naib[m]: audacious is, yes
2021-10-13 21:16:00 <psykose> they have a super large range for ruby
2021-10-13 21:16:03 <dalias> the distro exists because upstreams in general can't be trusted to act in their users' interests
2021-10-13 21:16:04 <psykose> 2.5-3.1
2021-10-13 21:16:14 <PJ[m]> yes, I've seen that, but wanted to be sure :)
2021-10-13 21:16:15 <Ariadne> Saijin_Naib[m]: as for why mask XMMS, XMMS was quite dead and GTK1 had CVEs, so they were trying to remove GTK1 entirely from Gentoo
2021-10-13 21:16:29 <dalias> this is the big difference between linux and something like windows :)
2021-10-13 21:16:52 <dalias> there's a party between you and the upstream software that has no commercial incentive to act against your interests
2021-10-13 21:17:24 <psykose> there's a fat requirement of like 15 gems, but aside from that this doesn't look very hard to package
2021-10-13 21:20:12 <PJ[m]> I'm also a SW dev so whenever there is a special case of installation, my ~~spider~~ sense is tingling as I would like to not have people install my stuff in a weird way :)
2021-10-13 21:20:30 <PJ[m]> thankfully all I do is compiled so don't have to care much
2021-10-13 21:21:49 <psykose> compiled packages can have just as many weird packaging upstream issues :p
2021-10-13 21:24:16 <psykose> PJ[m]: where did you see the recommendation to ignore package repos?
2021-10-13 21:24:43 <PJ[m]> 1: https://www.vagrantup.com/docs/installation/source
2021-10-13 21:24:46 <PJ[m]> 2: https://www.vagrantup.com/docs/installation
2021-10-13 21:25:11 <PJ[m]> > compiled packages can have just as many weird packaging upstream issues :p
2021-10-13 21:25:17 <psykose> i see
2021-10-13 21:25:20 <PJ[m]> sure do, but is less painful
2021-10-13 21:25:56 <PJ[m]> at least in Go/Rust ;)
2021-10-13 21:26:21 <psykose> i believe every distribution hates packaging everything to do with rust
2021-10-13 21:26:44 <Ariadne> yes
2021-10-13 21:27:05 <psykose> it gets bad enough just to write something in it sometimes, as much as i like the language itself
2021-10-13 21:27:24 <dalias> shouldn't rust (apps) be fairly easy once you have rust itself? no shared libs/dynamic deps
2021-10-13 21:27:50 <psykose> why wouldn't they have shared libs? plenty of things use e.g. openssl
2021-10-13 21:28:22 <psykose> i believe the convention is -sys crates link to a system .so for runtime or somesuch
2021-10-13 21:28:36 <psykose> could be wrong
2021-10-13 21:28:46 <PJ[m]> many will still depend on openssl because it's just good and battletested 
2021-10-13 21:28:55 <psykose> of course, i'm just giving an example
2021-10-13 21:29:02 <PJ[m]> while we patiently wait for rustls 
2021-10-13 21:29:34 <Ariadne> dalias: no shared libs/dynamic deps means if a CVE happens in a dep we have to patch every rust program that uses that dep
2021-10-13 21:29:37 <PJ[m]> some provide option to choose which dependencies route you want to go
2021-10-13 21:29:53 <psykose> yep
2021-10-13 21:30:32 <PJ[m]> you patch main only or community too?
2021-10-13 21:30:41 <psykose> both
2021-10-13 21:30:42 <Ariadne> rust is not in main
2021-10-13 21:30:45 <dalias> ariadne, that's something you automate once tho
2021-10-13 21:31:06 <PJ[m]> I know it's not in main, or at least not yet
2021-10-13 21:31:12 <Ariadne> dalias: sure, but my disk space
2021-10-13 21:31:24 <dalias> and it's not so much patching them individually as just patching the affected crate
2021-10-13 21:31:32 <dalias> and rebuilding affected packages
2021-10-13 21:32:00 <PJ[m]> this can be a pain though
2021-10-13 21:32:15 <psykose> given how often i've seen xyz got an so bump and 60 packages have to get rebuilt it seems like much of the same
2021-10-13 21:32:27 <psykose> i can only imagine the amount of builder time needed for this though, if half of everything used rust
2021-10-13 21:32:47 <PJ[m]> time for rust but with dynlibs ;)
2021-10-13 21:33:02 <psykose> i believe almost every issue with rust currently is just language immaturity
2021-10-13 21:33:08 <psykose> no magical feature is going to fix anything
2021-10-13 21:33:16 <psykose> they just need to stop developing the language itself for 2 years
2021-10-13 21:34:20 <PJ[m]> do you monitor anyhow for Rust CVEs?
2021-10-13 23:46:39 <Ariadne> yes
2021-10-13 23:46:50 <Ariadne> the security team monitors all of alpine for CVEs, including rust packages
2021-10-13 23:51:00 <PJ[m]> even the crate deps?
2021-10-14 00:30:28 <Ariadne> when possible, yes
2021-10-14 01:03:51 <ktprogra1s> Any idea why the aarch64 and mips64 version of capitaine-cursors hasn't updated? https://pkgs.alpinelinux.org/packages?name=capitaine%2Dcursors
2021-10-14 01:04:34 <ktprogra1s> BTW is the build pipeline for builds put onto the repo different than the aports CI test pipeline?
2021-10-14 01:19:26 <Ariadne> mips64 is dead
2021-10-14 01:35:42 <ktprogra1s> Ariadne: what about aarch64?
2021-10-14 01:41:38 <Ariadne> it hasn’t gotten to building it yet
2021-10-14 01:43:04 <ktprogra1s> Ariadne: ok. Just that I use arm64 myself.
2021-10-14 01:56:30 <andypost[m]> I think to disable libreoffice as it needs upgrade and not compatible with new icu
2021-10-14 02:04:13 <orbea> fedora sometimes has patches to fix stuff like that
2021-10-14 02:04:54 <orbea> the libreoffice git also might have patches that can be backported
2021-10-14 02:06:08 <dalias> uhg
2021-10-14 02:06:35 <dalias> can icu be made into a package named by the major version
2021-10-14 02:06:47 <dalias> so that new versions can be packaged without breaking the system?
2021-10-14 02:09:02 <orbea> i think libreoffice provides an internal icu if you want to go that route
2021-10-14 02:12:45 <dalias> sounds like a much better idea
2021-10-14 02:16:38 <andypost[m]> btw !11136 looks near ready
2021-10-14 02:20:59 <andypost[m]> the same issue with boost, any idea why it can't find boost from main? https://build.alpinelinux.org/buildlogs/build-edge-x86/community/calamares/calamares-3.2.39.3-r2.log
2021-10-14 02:21:19 <orbea> libreoffice has an internal boost too :P
2021-10-14 02:23:01 <dalias> :)
2021-10-14 02:24:03 <andypost[m]> this way when bumping dependencies it will need to bump makedepeds - it sounds good idea
2021-10-14 02:27:37 <sam_> andypost[m]: so the libffi thing was ok in the end? :)
2021-10-14 02:28:11 <sam_> [08:08:24]  <Ariadne> while if alpine or devuan want to change openrc, we have to send an MR
2021-10-14 02:28:18 <sam_> to be fair, I did try broker this commit access thing a while ago and nothing happened with it
2021-10-14 02:28:22 <sam_> I still think william would be up for it
2021-10-14 02:28:31 <Ariadne> i think it’s too late
2021-10-14 02:29:06 <dalias> ?
2021-10-14 02:29:32 <Ariadne> thankfully more reasonable people have convinced me that forking openrc is a waste of time and brings no tangible benefit to alpine (in that it does not solve our problems per se)
2021-10-14 02:30:27 <Ariadne> fundamentally we exist in a world where gentoo can veto anything it wants in openrc.  resolution of that governance issue will not be resolved simply by adding committers from outside gentoo.  gentoo itself must be divorced from it’s special relationship with openrc.
2021-10-14 02:31:06 <Ariadne> but again it doesn’t matter, as we will be switching to s6-rc in a couple of release cycles most likely.
2021-10-14 02:31:11 <dalias> :)
2021-10-14 02:32:00 <Ariadne> at which point openrc will be given a significant lobotomization in alpine so that it can exist as a compatibility layer for legacy init scripts that haven’t been ported to s6-rc units yet
2021-10-14 02:33:20 <Ariadne> the problem fundamentally is that william is not allowed to tell gentoo no
2021-10-14 02:33:24 <Ariadne> it’s not even his project
2021-10-14 02:33:28 <Ariadne> it’s gentoo’s project
2021-10-14 02:33:53 <Ariadne> and when mgorny gets his way and gentoo migrates to systemd, they will dispose of openrc and it will be dead
2021-10-14 02:33:59 <Ariadne> that’s the reality
2021-10-14 02:34:18 <sam_> but it's.. not?
2021-10-14 02:34:46 <sam_> why not just focus on something concrete? you want william to make a decision, so talk to him about it?
2021-10-14 02:35:10 <sam_> you don't need to invoke this idea of it being a "gentoo project" because it isn't, and if mgorny is really some overlord and everyone in gentoo hates openrc anyway, what would it being a "gentoo project" mean?
2021-10-14 02:36:32 <sam_> i really don't think the sun shines out of openrc's arse at all
2021-10-14 02:36:47 <sam_> ii'm just saying that i don't think there's this hostility to alpine suggestions or collaboration or you guys maintaining it with william or whatever
2021-10-14 02:37:14 <sam_> vapier commenting on bugs being glib isn't super helpful but it's not a veto from "gentoo" either
2021-10-14 02:37:49 <Ariadne> nah man it’s always been this way
2021-10-14 02:38:01 <sam_> i do think things have been stagnant but not for _that_ reason
2021-10-14 02:38:15 <Ariadne> almost everyone on alpine core has at some point tried to make a deal to maintain openrc in a sane way
2021-10-14 02:38:20 <Ariadne> i think we stop now
2021-10-14 02:38:25 <Ariadne> better to focus on future
2021-10-14 02:38:31 <sam_> fair enough
2021-10-14 02:38:57 <dalias> i dont think you need to "make a deal to maintain it"
2021-10-14 02:39:09 <Ariadne> you are right, we don’t
2021-10-14 02:39:21 <Ariadne> we can just maintain openrc 0.44.x ourselves
2021-10-14 02:39:50 <dalias> but william seems reasonable and doesn't need to have gentoo bs projected onto him
2021-10-14 02:39:54 <Ariadne> William wanted a different outcome.  and then vapier came in and shit all over it
2021-10-14 02:40:03 <sam_> that doesn't mean vapier is in charge though
2021-10-14 02:40:08 <sam_> people bikeshed on bugs
2021-10-14 02:40:12 <dalias> and i dont think you need to maintain it yourself aside from carrying some trivial patches
2021-10-14 02:40:18 <Ariadne> funny, he seems to talk like he is and William hasn’t rebuffed him
2021-10-14 02:40:21 <sam_> i promise, william may have his flaws (and i'd say so to him), but he is no dictator 
2021-10-14 02:40:30 <sam_> and he's upset about this situation
2021-10-14 02:40:57 <Ariadne> yes he is upset because he wanted Alpine to collaborate instead of maintaining a huge patchset
2021-10-14 02:41:02 <dalias> that doesn't even bind you to a particular version
2021-10-14 02:41:14 <dalias> why would you need a "huge patchset" ?
2021-10-14 02:41:35 <Ariadne> because we literally fix tons of bad upstream behavior
2021-10-14 02:41:39 <dalias> unless you're trying to further develop openrc (which i'm pretty sure you're not) the patchset should be just fixing any critical problems hit
2021-10-14 02:41:39 <Ariadne> some of it got up streamed
2021-10-14 02:41:47 <Ariadne> yes
2021-10-14 02:41:52 <Ariadne> that is what i am telling you
2021-10-14 02:42:08 <Ariadne> alpine user reports bug, we fix bug, patchset grows
2021-10-14 02:42:22 <Ariadne> every few years there is some attempt to reconcile the patchset
2021-10-14 02:42:27 <Ariadne> and then things are ok
2021-10-14 02:42:39 <Ariadne> and then Gentoo developers start walking around like they own the place
2021-10-14 02:42:46 <Ariadne> and we go back to doing what works
2021-10-14 02:46:35 <Ariadne> dalias: what i’m trying to do is address the fact that openrc has release critical bugs, it is clear that trying to do so in concert with upstream, even when upstream wants to work with us, is not possible, when gentoo developers can veto anything they wish.
2021-10-14 02:46:57 <Ariadne> if addressing release critical bugs means we have to maintain a patchset, fine.  we do so already.
2021-10-14 02:47:09 <Ariadne> but i’m not going to waste my time on another bikeshed
2021-10-14 02:47:37 <sam_> someone dissenting on a bug is not a veto
2021-10-14 02:47:50 <psykose> currently i can see the issue has william suggesting a patch
2021-10-14 02:47:53 <orbea> have you actually tried to discuss why the dissent is wrong?
2021-10-14 02:47:55 <Ariadne> it is when their dissent contains no valid technical argument
2021-10-14 02:48:05 <orbea> then say that?
2021-10-14 02:48:13 <Ariadne> i believe i did
2021-10-14 02:48:14 <sam_> then ignore it? speak to william that you think it's nebulous? ask if you can move forward now?
2021-10-14 02:48:16 <orbea> and ping someone else to look at it if it gets ignored
2021-10-14 02:48:18 <psykose> unless there is some out of band thing, perhaps it can get merged, i don't think just vapier saying no would stop it
2021-10-14 02:48:23 <sam_> exactly
2021-10-14 02:48:30 <sam_> vapier is loud and always has been, everywhere in foss
2021-10-14 02:48:42 <sam_> him commenting on a bug doesn't mean much
2021-10-14 02:48:54 <Ariadne> good for him, kick him out of the project if you don’t want the consequences of his actions
2021-10-14 02:48:54 <sam_> usually his perspective is worth understanding although I don't always end up agreeing
2021-10-14 02:49:06 <sam_> he's not allowed to comment on a bug?
2021-10-14 02:49:32 <Ariadne> he is allowed to do whatever he wants but he throws his weight around.
2021-10-14 02:49:39 <psykose> if you go and agree with william right now, the patch is probably going to get merged in the next few days
2021-10-14 02:49:50 <Ariadne> the patch
2021-10-14 02:49:52 <Ariadne> does not
2021-10-14 02:49:54 <Ariadne> fix the bug
2021-10-14 02:50:03 <sam_> then speak to william about what's wrong?
2021-10-14 02:50:07 <Ariadne> vapier bikeshed a patch that did fix the bug
2021-10-14 02:50:08 <sam_> because he doesn't understand it right now
2021-10-14 02:50:17 <Ariadne> into one which does not
2021-10-14 02:50:18 <Ariadne> nope
2021-10-14 02:50:24 <Ariadne> i’m not wasting anymore time on this
2021-10-14 02:51:41 <dalias> i dont even know what would "fix the bug" but i do not want any automated "rm -rf" or "find -delete" or whatever executing on my boxen by default at boot time
2021-10-14 02:51:51 <dalias> it's unnecessary and ridiculously risky
2021-10-14 02:53:40 <Ariadne> yes, and that's what i asked for to begin with: flipping the default
2021-10-14 02:53:52 <Ariadne> so, we will fix it in alpine.
2021-10-14 02:55:17 <Ariadne> every second of my time wasted on this is time i could be spending resolving other RC bugs and getting us to freeze
2021-10-14 02:55:31 <Ariadne> as far as i am concerned, vapier is maliciously DoSing my time, and i'm not having any more of it
2021-10-14 02:55:59 <Ariadne> if gentoo dislikes how outside projects see his behaviour, maybe they should tell him to stop derailing work with bikesheds.
2021-10-14 02:56:34 <orbea> sam_: fwiw the code this is about is indeed questionable, changing the default wouldn't be a bad idea
2021-10-14 02:58:41 <andypost[m]> what about that move !26410
2021-10-14 02:59:19 <Ariadne> i think it should go into main
2021-10-14 02:59:38 <Ariadne> from security team POV, i only want to support either 1.76 or 1.77 in the next release
2021-10-14 03:01:06 <andypost[m]> so it makes sense to update 140 aports atm?
2021-10-14 03:01:37 <andypost[m]> Ariadne: I can't get how to fix calamares build except pointing exact version of boost
2021-10-14 03:02:31 <Ariadne> i think i would like to wait until openssl 1.1 downgrade is done
2021-10-14 03:04:24 <andypost[m]> but calamares blocks further build
2021-10-14 03:04:57 <Ariadne> then fix calamares
2021-10-14 03:05:36 <Ariadne> does boost 1.76 not have boost-python3?
2021-10-14 03:08:58 <Ariadne> dalias: alpine's patchset to openrc already addresses critical bugs
2021-10-14 03:09:20 <Ariadne> for example, if you do not use gentoo's baselayout, openrc does not even work ^_^
2021-10-14 03:12:13 <dalias> :-p
2021-10-14 03:18:49 <Ariadne> 
ACTION debates warning on wipe_tmp=yes

2021-10-14 03:19:32 <Ariadne> something like
2021-10-14 03:20:08 <Ariadne> wipe_tmp is explicitly set in /etc/conf.d/bootmisc; Alpine does not recommend the use of this setting, due to reported data loss incidents relating to it.  See alpine/aports#13070 for more details.
2021-10-14 03:20:58 <dalias> :)
2021-10-14 03:43:53 <ktprograms> If I'm modifiying the config-virt in aports how should make olddefconfig be run? (To update the configs since I'm also updating to 5.10.73)
2021-10-14 04:54:14 <smcavoy> ktprograms: it seems to run `listnewconfig oldconfig` at the end of prepare https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-lts/APKBUILD#L106 
2021-10-14 04:56:29 <smcavoy> I think that will accept defaults if shell is not interactive and sit at a prompt if the shell is interactive 
2021-10-14 05:32:35 <ktprograms> smcavoy: That's good, but what I mean is in the (for example) config-virt.aarch64, in the comments at the top it says 5.10.68 configuration even though the latest in the repos it 5.10.72. I guess running it through make menuconfig would work but how do you do that for each architecture?
2021-10-14 06:09:26 <nmeum> looks like the builders made some good progress on the icu rebuild, thanks andypost[m] (:
2021-10-14 06:10:11 <andypost[m]> nmeum: only libreoffice been disable but the rest looks went fine
2021-10-14 06:10:35 <nmeum> great!
2021-10-14 06:11:10 <nmeum> firefox-esr also passed on the CI, so I will push that now
2021-10-14 06:27:13 <smcavoy> ktprograms: pretty sure that the comment is just that, it has no bearing on building the kernel. when you run oldconfig or menuconfig (and save) it should update the .config within src/{kver} but that is delete after the kernel is done building and abuld cleans up. you *could* generate the config you want and copy it into the config-virt.{arch} file but that might not look good as a diff to aports, 
2021-10-14 06:27:19 <smcavoy> I think it best to edit the config and simply add module lines as needed.
2021-10-14 06:30:32 <ktprograms> smcavoy: Thatt's what I'm currently doing.
2021-10-14 06:32:08 <ktprograms> But it looks like when ncopa updates the kernel config the versions in the config-* files change. So therefore menuconfig makes changes based on ncopa's machine (such as CC_VERSION_TEXT)?
2021-10-14 06:44:17 <smcavoy> ktprograms: that might be auto updated at compile time
2021-10-14 06:51:00 <mps> smcavoy: ncopa have script for this things
2021-10-14 06:51:23 <mps> and I have them somewhere but forgot where
2021-10-14 08:50:46 <Ariadne> if there is really need to move to 5.10.73 i can do it
2021-10-14 08:50:50 <Ariadne> i have the scripts
2021-10-14 08:53:27 <ktprograms> Ariadne: I don't think there's any need to update, but would you be ok with sharing the scripts (I'm wondering how it works)?
2021-10-14 08:53:37 <Ariadne> my scripts are garbage :)
2021-10-14 08:55:16 <ktprograms> If you don't mind sharing them I'm wondering how the config can be updated but still build on the CI builders
2021-10-14 08:57:01 <MY-R> 
ACTION love garbage scripts - are more readable :D

2021-10-14 09:02:39 <mps> 'putting' kernels on CI is actually useless, kernel always passes
2021-10-14 09:04:00 <mps> and these versions and tools versions changes in .config is not important, kernel builds even if they not changed
2021-10-14 09:06:02 <ktprograms> mps: makes sense
2021-10-14 09:06:42 <mps> and (as I wrote above) i have this script but don't use it because sometimes it can make some mess which is unnoticable
2021-10-14 09:07:37 <ktprograms> Ok so if I have changes to the kernel config I should just submit them regardless of the version number in the config?
2021-10-14 09:08:14 <mps> Sasha Levin (stable kernel maintainer) looks for making kernel maintainers life easier, i.e. rolling stable kernel release
2021-10-14 09:08:51 <mps> https://lwn.net/Articles/871989/
2021-10-14 09:09:40 <mps> person asks and left ;)
2021-10-14 09:10:31 <mps> could be network on (hmm, her/his) side
2021-10-14 09:11:10 <ktprograms> mps: Needed to disconnect from ethernet and switch to wifi
2021-10-14 09:11:27 <mps> ok, happens also to me
2021-10-14 09:12:04 <ktprograms> In case you're wondering I saw your message on the irclog
2021-10-14 09:12:28 <mps> ktprograms: if you need changes or features in kernel it is better to open issue/wishlist first and discuss this with maintainer
2021-10-14 09:13:06 <mps> ncopa (nor I) are easy to accepting changes in kernels
2021-10-14 09:13:17 <mps> are not*
2021-10-14 09:14:13 <Ariadne> to clarify, the requested changes are likely to be implemented, but opening an MR does not help anyone
2021-10-14 09:15:47 <mps> Ariadne: right. I mean we accept changes but when explained why is needed
2021-10-14 09:15:58 <mps> not blindly
2021-10-14 09:16:55 <mps> I have changes for armv7 virt for more than 3-5 months but didn't opened MR nor posted MR
2021-10-14 09:17:49 <mps> and changes are critical for armv7 virt to work with more than 1G RAM, but ..... :)
2021-10-14 09:17:58 <mps> no one ask for this
2021-10-14 09:19:10 <mps> when we are talking about kernels, I'm contemplating of making arm kernels specific for particular SoCs
2021-10-14 09:19:56 <mps> for example, linux-rockchip, linux-sunxi, .... linux-M1
2021-10-14 09:20:59 <mps> but this will need more hands, or I have to become Shiva
2021-10-14 09:22:19 <mps> actually, I made linux-elm and linux-gru already in testing, and have locally linux-n900 and linux-sunxi (beside linux-rc)
2021-10-14 09:22:57 <mps> maybe we could get help from pmOS devs on this
2021-10-14 09:39:22 <ktprograms> mps: It's enabling CONFIG_INPUT_UINPUT so spice-vdagent works
2021-10-14 09:43:43 <mps> ktprograms: you know that you can install non virt version of kernel in VM
2021-10-14 09:56:25 <ktprograms> It doesn't really matter for me since I compile my own kernel but people would expect a virt kernel to support spice-vdagent (which is used for e.g. clipboard sharing). Also for some reason the standard kernel doesn't boot in Virtualization.framework which uses almost entirely virtio devices.
2021-10-14 09:59:49 <mps> ktprograms: then 'normal' kernel should be fixed
2021-10-14 10:12:44 <ktprograms> mps: What's the virt kernel for then?
2021-10-14 10:44:34 <clandmeter> anyone used setup-alpine/setup-disk on edge recently?
2021-10-14 10:44:56 <ikke> Last before the 3.14 release
2021-10-14 10:48:23 <ikke> PureTryOut: any reason kactivities depends directly on boost1.76-dev?
2021-10-14 10:49:05 <PureTryOut> Because it couldn't pull in boost-dev for some reason
2021-10-14 10:49:22 <ikke> hmm, ok
2021-10-14 10:49:31 <PureTryOut> I think it was in the testing repository and kactivities in community or something?
2021-10-14 10:49:43 <PureTryOut> It doesn't in particularly need 1.76 though
2021-10-14 10:49:53 <ikke> boost1.76 in main also has boost-dev as metapackage
2021-10-14 10:50:09 <PureTryOut> Yet abuild still wouldn't pull it in 🤷
2021-10-14 10:50:43 <PureTryOut> Right now it does however 🤔 How strange
2021-10-14 10:51:16 <clandmeter> looks like setup-disk does not populate root except for /etc
2021-10-14 10:52:12 <PureTryOut> ikke: changed it for boost-dev
2021-10-14 10:52:36 <ikke> PureTryOut: 👍
2021-10-14 10:53:17 <ikke> So regarding !26410, I expect that we could just merge that, and start rebuilding the rest against boost1.76?
2021-10-14 10:53:20 <ikke> 1.77*
2021-10-14 10:53:40 <ikke> Because both are available, packages built against 1.76 should still work, right?
2021-10-14 10:55:21 <PureTryOut> Idk how much the API changed, but it should probably work yes
2021-10-14 10:55:30 <PureTryOut> is boost in general going to be moved away from main then?
2021-10-14 10:56:08 <ikke> PureTryOut: no
2021-10-14 10:56:16 <ikke> boost1.76 is in main now
2021-10-14 10:56:20 <ikke> boost1.77 in testing
2021-10-14 10:56:35 <ikke> The idea is to move everything to boost1.77
2021-10-14 10:57:03 <PureTryOut> And then move boost1.77 to main?
2021-10-14 10:57:17 <ikke> that's what that MR does
2021-10-14 10:57:31 <PureTryOut> No it moves it to community
2021-10-14 10:57:37 <PureTryOut> At least, according to the title algitbot posted
2021-10-14 10:58:19 <ikke> Right
2021-10-14 10:58:25 <ikke> Then it needs to be moved to main
2021-10-14 10:58:53 <PureTryOut> Yes I'd think so, that's why I asked 😉
2021-10-14 10:59:29 <ikke> I was working on moving it to main, and saw this MR, so I kinda assumed it would move it to main
2021-10-14 11:01:52 <ikke> andypost[m]: Do you think !24886 can be merged now?
2021-10-14 11:02:41 <andypost[m]> ikke: yes, and I bet community and testing too
2021-10-14 11:03:30 <ikke> merged the first one
2021-10-14 11:14:02 <PureTryOut> Some great big upgrades are coming through 😄
2021-10-14 11:15:50 <andypost[m]> I think we should get in !26072 before boost moved to main
2021-10-14 11:20:54 <mps> ktprograms: virt flavor is to be small (and fast) on VMs, not for desktops in VMs
2021-10-14 11:21:18 <mps> i.e. for servers in VMs, iirc
2021-10-14 11:21:33 <ikke> Yes 
2021-10-14 11:22:03 <ikke> andypost[m]: what about the comment from Leo 
2021-10-14 11:24:13 <ktprograms> mps: I see. So I should try to figure out why the normal kernel doesn't boot on virtualization.framework?
2021-10-14 11:25:55 <andypost[m]> ikke: I think both needs provider priority at least at rebuild time, cmmented
2021-10-14 11:27:33 <ikke> But they do not provide the same package at the moment 
2021-10-14 11:28:06 <ikke> except boost-dev, which is versioned
2021-10-14 11:31:26 <ikke> If both would have provides="boost", then the priority would be needed 
2021-10-14 11:42:56 <yyp> Is there much involved in moving package from testing to community? I maintain two packages for a few months now and think they are ready to leave testing
2021-10-14 11:43:21 <ikke> No, just a merge request doing so 
2021-10-14 11:43:54 <yyp> Great, will do :)
2021-10-14 12:05:01 <PureTryOut> mps: you just merged testing/crust for the PinePhone. Why do you need that?
2021-10-14 12:05:28 <PureTryOut> (also you made MartijnBraam the maintainer for that, probably good to notify him about that)
2021-10-14 12:05:52 <PureTryOut> Oh and the options variable contains a postmarketOS specific one
2021-10-14 12:06:05 <PureTryOut> Seems it's just a straight copy from the package in postmarketOS?
2021-10-14 12:06:47 <PureTryOut> Oh derp never mind, I should stop looking at the postmarketOS package lol
2021-10-14 12:06:54 <PureTryOut> Still, why do you need it in Alpine?
2021-10-14 12:08:51 <mps> PureTryOut: no, looks like I'm maintainer
2021-10-14 12:09:09 <PureTryOut> (yeah I know, I was looking at the postmarketOS package, hence my "never mind")
2021-10-14 12:09:20 <mps> and I made it with newapkbuild, didn't copied anything
2021-10-14 12:09:34 <PureTryOut> (yeah I know, again, I was looking at the wrong package)
2021-10-14 12:09:40 <mps> ok, np
2021-10-14 12:09:48 <PureTryOut> Still I wonder why you need it in Alpine
2021-10-14 12:10:09 <mps> 'we' need it for a64 sunxi boards to use AR100 CPU
2021-10-14 12:10:28 <PureTryOut> But right now it just builds for the PinePhone?
2021-10-14 12:11:24 <mps> yes, this is initial commit, later will add more boards and move to community, as smcavoy proposed also
2021-10-14 12:11:50 <mps> we commented this in MR
2021-10-14 12:12:06 <PureTryOut> I did see a comment to add boards but it was not acted upon
2021-10-14 12:12:16 <PureTryOut> So I thought you just needed the PinePhone
2021-10-14 12:12:42 <mps> yes, for now this is enough to test on my teres notebook
2021-10-14 12:13:37 <PureTryOut> Huh ok, interesting
2021-10-14 12:14:03 <PureTryOut> Maybe eventually it can be moved to main rather that community? It's better to have stuff required for devices to boot in main imo
2021-10-14 12:30:25 <mps> yes, but we will have to move other needed tools to main also
2021-10-14 12:32:08 <martijnbraam> don't you need it in main anyway since it's a build dep for uboot?
2021-10-14 12:33:37 <mps> martijnbraam: yes ofc. but we need to persuade maintainers of these tools for this
2021-10-14 12:35:27 <mps> anyway, whoever wants to use crust on his/her local machine to build u-boot can do this now manually on alpine
2021-10-14 12:48:25 <andypost[m]> ikke: plasma building fails because ffi community and testing not committed
2021-10-14 12:48:53 <ikke> Ok, feel free to do those 
2021-10-14 12:49:01 <ikke> I don't vee time sum
2021-10-14 12:49:06 <ikke> Atm*
2021-10-14 13:54:41 <clandmeter> mps: linux-edge riscvy64 does not have iptables?
2021-10-14 13:55:39 <mps> really?
2021-10-14 13:55:59 <clandmeter> or is it buildin?
2021-10-14 13:56:05 <mps> does it have nftables
2021-10-14 13:58:11 <clandmeter> this config is not based on other cofnigs?
2021-10-14 13:58:36 <mps> no, it is made from defconfig for riscv
2021-10-14 13:59:12 <clandmeter> heh
2021-10-14 13:59:23 <clandmeter> it looks like its kind of limited 
2021-10-14 13:59:44 <mps> when I started it I wanted small as possible to build it in reasonable time in lxc
2021-10-14 14:01:28 <mps> say your wishes, and it will be done later at evening (I have to go to one gala lunch in short time)
2021-10-14 14:30:09 <nmeum> clandmeter: i honestly thing it would be worth it to modulize our kernel configuration files a bit, keeping everything in sync manually is cubersome and error-prone
2021-10-14 14:30:13 <nmeum> s/thing/think
2021-10-14 14:30:47 <nmeum> #12933
2021-10-14 14:43:22 <clandmeter> mps: please add iptables support, else I cant use lxc 
2021-10-14 14:45:10 <clandmeter> nmeum: i did something kind of similar for rpi
2021-10-14 14:45:49 <clandmeter> where you take defconfig and have a list of items you want to add.
2021-10-14 14:46:19 <nmeum> yeah, that's basically what debian does too
2021-10-14 14:46:33 <clandmeter> fabled also had some ideas about it
2021-10-14 14:47:09 <nmeum> maybe something that could also be discussed with TSC, idk
2021-10-14 14:47:21 <nmeum> but would be nice to have imho
2021-10-14 14:47:43 <clandmeter> maybe nice to discus when we have enough time :)
2021-10-14 14:48:16 <clandmeter> i think we should first add some ideas to this ticket
2021-10-14 14:49:13 <nmeum> yup, feel free to add comments
2021-10-14 14:54:23 <clandmeter> done
2021-10-14 15:06:19 <mps> please keep such discussion open and not hidden behind some committees
2021-10-14 15:06:46 <mps> *as everything should be open*
2021-10-14 15:07:03 <clandmeter> mps: its all open
2021-10-14 15:07:21 <clandmeter> you can see all actitivy in the tracker
2021-10-14 15:07:33 <mps> meh
2021-10-14 15:08:03 <mps> open means everyone can discuss
2021-10-14 15:08:46 <clandmeter> yes, and that is possible
2021-10-14 15:09:02 <clandmeter> but somebody will have to make a decision 
2021-10-14 15:09:13 <ikke> And fyi, it's not the goal of the TSC to take every decision
2021-10-14 15:09:54 <mps> hehe, like with 'quiet' kernel cli fiasco
2021-10-14 15:10:15 <clandmeter> kunkku write an document about what the TSC is about
2021-10-14 15:11:38 <clandmeter> this is also why i say that this kernel config thing is probably not a good thing for the tsc to discus 
2021-10-14 15:11:43 <mps> I had a hope when I joined that we could make decisions by some kind of consesus and common sense (looks like I was wrong)
2021-10-14 15:12:37 <clandmeter> tsc should look at deeper or wider technical changes that can affect the system in a whole.
2021-10-14 15:12:53 <mps>  /o\
2021-10-14 15:13:15 <clandmeter> for the rest we leave it up to the regular teams like developement team
2021-10-14 15:13:32 <mps> but I agree with nmeum proposal about kernel config
2021-10-14 15:14:55 <clandmeter> and i agree with your feeling, we should not discuss these things in some meeting. we need the communities input on it. 
2021-10-14 15:15:57 <mps> that is why I like you :)
2021-10-14 15:16:58 <clandmeter> i love you too
2021-10-14 15:17:35 <clandmeter> and please use that ticket to put your ideas, else we would mis your input on this topic.
2021-10-14 15:19:01 <mps> ok, will do if I found any
2021-10-14 15:24:55 <mps> heh, openbsd released with riscv and apple M1 initial supports https://www.openbsd.org/70.html
2021-10-14 15:30:15 <psykose> feels like everyone is getting risc-v support all at once
2021-10-14 15:30:58 <nmeum> well, with the hifive unmatched hardware capable of booting conventional operating systems is somewhat widely available now
2021-10-14 15:32:08 <psykose> yep
2021-10-14 17:31:15 <ikke> should packages depend directly on boost1.xx-*?
2021-10-14 17:31:32 <ikke> Cloudi fails becuase it depends on boost-system/thread
2021-10-14 17:54:53 <ikke> How to solve this conflict? https://tpaste.us/BgLR 
2021-10-14 17:55:13 <ikke> need to build ghc against libffi3.3-compat-dev, but ghc conflicts with it
2021-10-14 17:55:19 <ikke> and ghc needs ghc to build
2021-10-14 18:15:04 <Hello71> 386af84e101e82ea54e6a3e2874ef279234e720a, 4feaea39adc2ee2eb2be672ce032edcb50548dd9 possibly related
2021-10-14 18:27:23 <ikke> heh, trying `apk add -t libffi-dev`
2021-10-14 18:34:53 <Hello71> i think that could work if you rebuild ghc again afterwards
2021-10-14 19:12:38 <ikke> >>> ghc*: Tracing dependencies...                              
2021-10-14 19:12:40 <ikke> >>> ERROR: ghc*: libHSCabal-3.0.1.0-ghc8.8.4.so: path not found
2021-10-14 19:13:32 <ikke> but apparently it's still continuing
2021-10-14 19:30:06 <xkrz> I wanted to thanks for the flatpak upgrade 1.10.5, no more syscalls errors anymore
2021-10-14 20:48:14 <ikke> mps: can you take a look at perl-glib-object-introspection? It has test failures atm
2021-10-14 20:55:46 <mps> ikke: I was on 'big' dinner and drink some quantity of wine, not sure I can do much now, but I will glance over it
2021-10-14 20:56:47 <ikke> thx
2021-10-14 20:57:08 <mps> oh '-Wformat'
2021-10-14 20:57:34 <clandmeter> there is nothing a bottle of wine cant fix.
2021-10-14 20:58:31 <mps> all these errors are in one file gperl-i11n-marshal-interface.c
2021-10-14 20:59:46 <mps> and it is related to '%d' format, could be fixed probably by changing format specifiers
2021-10-14 21:18:39 <mps> Armenian cognac is best drink in the world, confirmed again today
2021-10-14 21:19:59 <mps> I understand why it is only drink contrabanded to space station :)
2021-10-14 21:27:38 <andypost[m]> )))
2021-10-15 03:38:20 <smcavoy> does anyone know if there is a  chance kernel modules can be added to linux-rpi before 3.15 is release? !25760
2021-10-15 03:39:44 <Hello71> normally with any changes to linux-rpi config there is a question, why does this justify differing from upstream linux-rpi
2021-10-15 03:42:02 <smcavoy> I think the mr answers that but certainly if there are questions I might have answers :)
2021-10-15 03:45:30 <Hello71> well why is lxd not needed on raspbian
2021-10-15 03:49:39 <smcavoy> looks like linux-rpi is tracking kernel.org + alpine patches, not raspbian 
2021-10-15 03:51:53 <smcavoy> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-rpi/APKBUILD#L20
2021-10-15 03:55:41 <Hello71> the "rpi-patches" part is important
2021-10-15 03:56:11 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-rpi/APKBUILD#L220
2021-10-15 03:56:31 <Hello71> dunno why it was done this way instead of just downloading linux-rpi
2021-10-15 04:02:52 <smcavoy> that is quite a bit... 
2021-10-15 04:06:09 <smcavoy> the proposed changed are additional modules to allow lxd vms on the rpi. As to why the modules are not enabled upstream *I am guessing* the vast majority of users do not use lxd and if they do, use lxc containers not VMs. Other VM platforms do not require the option..
2021-10-15 05:40:23 <ktprograms> Hi, can someone please take a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29
2021-10-15 05:41:06 <PJ[m]> why it should be prepended?
2021-10-15 05:50:42 <ktprograms> PJ[m]: For exammple if you run lbu include from your home directory, the path in lbu.list will be relative to your home directory. (For example if in /home/kt you lbu include a_directory , in lbu.list it will just be +a_directory. It should be +/home/kt/a_directory which my MR does)
2021-10-15 05:51:36 <PJ[m]> it was my assumption from alpine wiki that it supports only absolute paths
2021-10-15 05:52:06 <PJ[m]> which brings another question, what will happen after MR if I `lbu include` an absolute path
2021-10-15 05:53:19 <psykose> probably becomes wrong
2021-10-15 05:53:41 <PJ[m]> just looked at the MR, perhaps lbu should handle both cases or it should be clearly noted in help section it supports only absolute/relative paths
2021-10-15 05:57:12 <ktprograms> I guess checking if it starts with a '/' should work?
2021-10-15 06:06:40 <pj> most likely, try it :)
2021-10-15 06:15:04 <ktprograms> I'll try later. I'm a bit busy now.
2021-10-15 08:25:02 <PureTryOut> Clang inside abuild ignores my JOBS setting 👿
2021-10-15 08:44:40 <ktprograms> Why does lbu purposely remove the leading '/' in the path?
2021-10-15 09:28:06 <ktprograms> PJ[m]: My MR should be good now. Also should the package version be increased?
2021-10-15 09:28:43 <mps> hmm, 'apk upgrade -s' doesn't show icu-libs
2021-10-15 09:28:45 <psykose> if it's not it doesn't get an update for install, so yes
2021-10-15 09:28:49 <mps> on edge
2021-10-15 09:29:11 <pj> seems ok
2021-10-15 09:29:23 <pj> version will be probably bumped by ncopa
2021-10-15 09:30:13 <ktprograms> When doing package development/testing, can you tell apk to force reinstall even if the version didn't change?
2021-10-15 09:31:49 <pj> you can bump pkgrel version
2021-10-15 09:32:00 <pj> for a local fix
2021-10-15 09:32:20 <pj> or apk del/apk add
2021-10-15 09:32:28 <mps> ktprograms: apk fix -r pkgname
2021-10-15 09:32:57 <mps> -r --reinstall
2021-10-15 09:33:50 <clandmeter> i think apk fix pkgname is enough?
2021-10-15 09:34:17 <ktprograms> mps: clandmeter: apk fix works! thanks
2021-10-15 09:34:44 <mps> ok, apk upgrade -s now works
2021-10-15 09:36:10 <ktprograms> But it looks like apk fix can't downgrade packages (such as changing from the custom repo to latest-stable/main which has a lower pkgver/pkgrel)
2021-10-15 09:37:54 <mps> ktprograms: apk add --allow /path/to/pkgfilename
2021-10-15 09:42:38 <ktprograms> mps: I can't find a --allow flag in the apk man pages?
2021-10-15 09:47:57 <psykose> -a
2021-10-15 09:48:22 <psykose> or maybe he means --allow-untrusted
2021-10-15 09:48:34 <psykose> you can partially type it if there's no conflicts
2021-10-15 09:48:40 <psykose> honestly not the greatest 'feature'
2021-10-15 09:53:22 <ktprograms> mps: If you mean --allow-untrusted, I already have my signing key in /etc/apk/keys. It's just that I can't downgrade back to stable main
2021-10-15 09:54:39 <psykose> apk upgrade -Ua should work
2021-10-15 09:54:55 <ktprograms> psykose: Can you please take a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29 ? I've fixed the problem with absolute/relative paths
2021-10-15 09:55:42 <ktprograms> psykose: Ah so the flag is --available
2021-10-15 10:09:19 <mps> ktprograms: --allow is short variant of --allow-untrusted
2021-10-15 10:35:51 <ktprograms> I just realised I should have added my Contributor Comment to community/capitaine-cursors when I fixed the build. Should I make a new MR for that?
2021-10-15 10:37:36 <mps> question is, why add contributor
2021-10-15 10:38:01 <mps> contributor should be removed from all APKBUILDs
2021-10-15 10:38:42 <mps> maybe something for TSC, but I know result :D
2021-10-15 11:06:47 <Misthios> looks al long contributor lists in some apkbuilds
2021-10-15 11:07:21 <Misthios> Cogitri !25551 should be done for (hopefully) a final review
2021-10-15 11:28:13 <clandmeter> mps: your idea is not that crazy
2021-10-15 11:28:21 <clandmeter> it has been discussed before
2021-10-15 11:28:37 <clandmeter> also to make maintainer a real variable instead of a comment
2021-10-15 11:31:56 <mps> yes, I remember this discussion and wanted to raise it again
2021-10-15 11:32:29 <mps> not 'raise' but decide when we 'force' this
2021-10-15 11:39:56 <mps> what is ethernet device/driver on riscv64 unmatched
2021-10-15 11:41:11 <pj> if someone needs contributors, can't they just look at commits?
2021-10-15 11:41:34 <mps> pj: right
2021-10-15 11:42:11 <mps> and can see there what actually is contribution
2021-10-15 11:43:52 <psykose> it uses cadence macb
2021-10-15 11:43:59 <psykose> i cannot find anything on wtf it actually is
2021-10-15 11:44:22 <psykose> the hw reference manual is the only one missing on their site
2021-10-15 11:44:39 <psykose> but it is some cadence nic pretty sure
2021-10-15 11:45:58 <psykose> https://u-boot.readthedocs.io/en/latest/board/sifive/unmatched.html this is as much info as i found
2021-10-15 11:47:11 <mps> psykose: ah yes, I remember, nmeum told me earlier
2021-10-15 11:47:27 <mps> thanks
2021-10-15 11:48:31 <nmeum> yeah, it's macb
2021-10-15 11:49:28 <mps> I'm testing kernel for it with more modules and options enabled (mostly network part) right now
2021-10-15 11:49:50 <mps> if anything is needed please tell
2021-10-15 11:49:58 <mps> anything else
2021-10-15 12:02:16 <pj> well, mps: contributor comment would be useful if it was used by some external system, like maintainer is used on pkgs.alpinelinux.org but I'm not aware of its usage anywhere
2021-10-15 12:02:39 <pj> since to get all contributors, it would be required to get full git index
2021-10-15 12:04:14 <mps> pj: contributor field is useless
2021-10-15 12:06:41 <pj> I have no opinion on that :P just saying what someone could have tried using it for
2021-10-15 12:08:03 <mps> this is discussed some time ago and overall conclusion it is useless and can be even misleading, and should be removed
2021-10-15 12:21:18 <clandmeter> ddevault: did you make any progress on putting uboot on SPI?
2021-10-15 12:21:42 <ddevault> no, I have not been actively working on it
2021-10-15 12:22:02 <clandmeter> right, saw your blog just now.
2021-10-15 12:22:18 <ddevault> ah, gotcha
2021-10-15 12:22:37 <ddevault> timeframe on me working on that is probably within 3 months
2021-10-15 12:22:46 <clandmeter> :)
2021-10-15 12:25:00 <clandmeter> me and nmeum were running into issues booting with u-boot
2021-10-15 12:25:33 <ddevault> I have some u-boot patches
2021-10-15 12:25:38 <nmeum> I think it's a ramdisk specific issue
2021-10-15 12:25:41 <nmeum> I also have a patch for it
2021-10-15 12:25:41 <ddevault> https://git.sr.ht/~sircmpwn/u-boot
2021-10-15 12:25:41 <clandmeter> nmeum has a patch which he want upstream to take a look at, but seems its hard to reach them.
2021-10-15 12:26:00 <Cogitri[m]> Misthios: There are still some unresolved threads in that MR
2021-10-15 12:26:29 <ddevault> I also have https://git.sr.ht/~sircmpwn/opensbi
2021-10-15 12:29:34 <nmeum> but you didn't have any issues with u-boot hanging during ramdisk loading?
2021-10-15 12:29:45 <nmeum> https://tpaste.us/KMKB for example
2021-10-15 12:29:49 <nmeum> > Loading Ramdisk to ffa4b000, end fffff5c5 ...
2021-10-15 12:29:51 <nmeum> hangs after that
2021-10-15 12:30:10 <Misthios> Cogitri i still didnt figure ff out toh
2021-10-15 12:30:22 <nmeum> the address range seems very wonky to me
2021-10-15 12:30:33 <Misthios> rest should be fine now, just 2 failures left due to openssl but 1 of them builds fine locally
2021-10-15 12:32:55 <clandmeter> ddevault: if you have a reboot fix, please share :) very annoying to move to the attic all the time.
2021-10-15 12:33:31 <ddevault> hm
2021-10-15 12:33:34 <ddevault> I think there's a linux patch
2021-10-15 12:33:38 <ddevault> don't recall if I've tested it successfully
2021-10-15 12:33:58 <ddevault> lemme boot up my box and take a look at my linux tree
2021-10-15 12:34:06 <clandmeter> nmeum: ill add the release script modifications later.
2021-10-15 12:34:34 <nmeum> ddevault: why would it be a linux issue?
2021-10-15 12:35:04 <nmeum> I believe this to be an issue with the ramdisk address range calculation code in u-boot
2021-10-15 12:35:04 <ddevault> beats me
2021-10-15 12:35:13 <ddevault> wut
2021-10-15 12:35:16 <nmeum> because if you set initrd_high manually to a more sensible value you don't ran into it
2021-10-15 12:35:20 <ddevault> I'm talking to clandmeter
2021-10-15 12:35:22 <ddevault> about the reboot issue
2021-10-15 12:35:23 <nmeum> aaaaa
2021-10-15 12:35:24 <nmeum> haha
2021-10-15 12:36:32 <ddevault> clandmeter: sorry, I can't find the patch
2021-10-15 12:36:46 <ddevault> I was last experimenting with some upstream kernel builds
2021-10-15 12:37:03 <ddevault> iirc it was kind of a shitty patch anyway
2021-10-15 12:41:07 <ddevault> is anyone making an effort to upstream our firefox patches?
2021-10-15 12:47:52 <nmeum> I don't think so, no
2021-10-15 16:02:59 <andypost[m]> why edge builders (except rv64) can't find boost?
2021-10-15 16:03:14 <ikke> boost1.76 does not provide boost
2021-10-15 16:03:18 <ikke> and boost1.77 is in testing
2021-10-15 16:03:41 <andypost[m]> ah, it's not moved yet
2021-10-15 16:03:44 <ikke> I'm (slowly) working on rebuilding everything against boost1.77
2021-10-15 16:04:01 <ikke> andypost[m]: that's why provider_priority is not required (yet)
2021-10-15 16:04:25 <ikke> andypost[m]: I'm building on your MR
2021-10-15 16:04:50 <alpineLuser> hi - can anyone help me with gcc + kernel builds?  alpine's bundled gcc doesn't seem to have plugin support, is there a package I'm unaware of or do I have to rebuild gcc and make my own packages?
2021-10-15 16:04:53 <andypost[m]> got it, then not clear how to resolve builders
2021-10-15 16:05:33 <ikke> andypost[m]: depend on boost1.76
2021-10-15 16:05:35 <ikke> not boost
2021-10-15 16:06:02 <andypost[m]> ikke: maybe it will be easy just point exact version of boost in makedepends? otoh it makes bumps harder
2021-10-15 16:06:19 <ikke> andypost[m]: in many cases, it already is happening
2021-10-15 16:06:36 <ikke> and there are no boost-<component> packages either
2021-10-15 16:06:47 <ikke> so packages need to depend explicitly on boost1.76-system for example
2021-10-15 16:06:54 <andypost[m]> at least it makes transition more predictable
2021-10-15 16:07:33 <ikke> yes
2021-10-15 16:07:51 <ikke> And I found at least on package which does not build against boost1.77 (in testing)
2021-10-15 16:08:04 <ikke> and which was not trivially patcheble
2021-10-15 16:08:11 <andypost[m]> so 1.76 could went to testing)
2021-10-15 16:08:51 <ikke> yes, that was my idea
2021-10-15 16:08:56 <ikke> if there are no others
2021-10-15 16:08:58 <ikke> I did fix a few
2021-10-15 16:30:12 <ikke> Ariadne: just for my info / planning, what's the status of the openssl revert?
2021-10-15 16:35:05 <dalias> sad about revert :(
2021-10-15 16:36:03 <ikke> yes
2021-10-15 17:49:14 <ikke> hmm, source-highlight fails on CI https://gitlab.alpinelinux.org/alpine/aports/-/jobs/513229/artifacts/raw/logs/build-source-highlight.log?inline=false
2021-10-15 17:49:44 <ikke> test failures I guess
2021-10-15 18:24:49 <ikke> >>> ceph-dbg*: Package size: 5.9 GB 
2021-10-15 18:24:51 <ikke> oof
2021-10-15 18:24:56 <ikke> 6GB of symbols
2021-10-15 20:17:15 <Hello71> that's good in a way, it used to crash the whole build instead
2021-10-15 20:20:05 <ikke> You mean your abuild fix worked? :)
2021-10-15 20:27:20 <ikke> Hmm, inkscap builds just with a single job :/
2021-10-15 20:27:23 <ikke> it's taking forever
2021-10-15 20:28:31 <jvoisin> inkscape is __heavy__ af.
2021-10-15 20:38:22 <ikke> euh, seems like it's building again in package()
2021-10-15 20:40:24 <ikke> Hmm, >>> inkscape-view*: Tracing dependencies...
2021-10-15 20:40:26 <ikke> >>> ERROR: inkscape-view*: libinkscape_base.so: path not found
2021-10-15 20:40:50 <ikke> This started to happening
2021-10-15 20:41:01 <ikke> The package builds fine, but these errors are shown
2021-10-15 20:52:41 <ikke> `undefined reference to `backtrace_symbols'`
2021-10-15 20:53:08 <dalias> *sigh* crash dumpers
2021-10-16 02:48:49 <Ariadne> ikke: main doing in about an hour
2021-10-16 02:51:35 <ktprograms> I know there's been some discussion about openssl conflicts, but is there any solution? Here's the error I'm getting https://gist.github.com/ktprograms/4be9d41a0709308c520fecc8a29a5e2f
2021-10-16 02:59:15 <ktprograms> Nevermind I fixed it by remove qt5-qtbase-dev from makedepends
2021-10-16 03:00:20 <ktprograms> Is there anyfor abuild to not purge packages at the end of a failed build?
2021-10-16 03:36:28 <Saijin_Naib[m]> ktprograms i believe you can set that rule in the /etc/abuild.conf
2021-10-16 04:42:04 <ktprograms> How do I write the APKBUILD such that installing the $pkgname-dev package installs $pkgname ?
2021-10-16 04:43:43 <ktprograms> Saijin_Naib[m]: Ah, it's removing deps from ERROR_CLEANUP
2021-10-16 04:44:57 <Saijin_Naib[m]> ktprograms: I think APKBuild takes care of that automatically
2021-10-16 04:45:08 <Saijin_Naib[m]> I didn't do anything special for my first package with -dev and it depends properly
2021-10-16 04:45:18 <Saijin_Naib[m]> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/libopenraw
2021-10-16 04:45:28 <Saijin_Naib[m]> https://git.alpinelinux.org/aports/tree/testing/libopenraw/APKBUILD
2021-10-16 04:45:38 <Saijin_Naib[m]> Or maybe the subpackages is what handles that
2021-10-16 05:28:04 <maxice8> ktprograms: $pkgname-dev will automatically depend on whatever package provides the libraries it holds the sonames for, so if $pkgname-dev has libfoo.so it will depend on the package that has libfoo.so.X.Y.Z, most cases that is $pkgname but can also be $pkgname-libs or lib$pkgname
2021-10-16 05:57:55 <ktprograms> maxice8: I see. thanks
2021-10-16 05:59:08 <Ariadne> so, my plan of attack is to change all openssl-dev dependencies to openssl1.1-compat-dev
2021-10-16 05:59:15 <Ariadne> then rename main/openssl to main/openssl3
2021-10-16 05:59:34 <Ariadne> and have main/openssl1.1-compat-dev provide openssl-dev
2021-10-16 06:28:23 <ikke> Ariadne: do you have any idea why libffi-dev and libffi3.3-compat-dev conflict with eachtother? See for example https://gitlab.alpinelinux.org/alpine/aports/-/issues/13086#note_185691
2021-10-16 06:28:54 <Ariadne> both provide pc:libffi
2021-10-16 06:28:58 <Ariadne> you can only have one or the other
2021-10-16 06:30:58 <ikke> Right, and both would also have libffi.so
2021-10-16 06:31:22 <Ariadne> the user in question was likely trying to use the old libffi
2021-10-16 06:31:34 <Ariadne> i think `--enable-portable-binary` is needed to fix libffi 3.4
2021-10-16 06:31:39 <ikke> I had the same issue with ghc
2021-10-16 06:31:58 <ikke> ghc depends (not makedepends) on libffi-dev
2021-10-16 06:32:30 <Ariadne> why is there libffi3.3 compat anyway
2021-10-16 06:32:34 <Ariadne> is it because of the trampoline?
2021-10-16 06:32:37 <Ariadne> we can just disable it
2021-10-16 06:32:51 <ikke> I've added it just to be able to build ghc again for the time being
2021-10-16 06:32:56 <Ariadne> oh
2021-10-16 06:33:04 <ikke> it had a lot of test failures against ffi3.4
2021-10-16 06:34:28 <Ariadne> yes, likely due to the new trampoline
2021-10-16 06:35:13 <ikke> ok
2021-10-16 06:38:56 <Ariadne> i would suggest disabling it and trying tests again :)
2021-10-16 06:39:16 <ikke> ok, will look at it
2021-10-16 06:42:29 <ikke> How would I disable it? Can't find references to a knob
2021-10-16 06:43:27 <ikke> https://gitlab.haskell.org/ghc/ghc/-/issues/20051
2021-10-16 06:44:05 <ikke> --disable-exec-static-tramp
2021-10-16 06:46:08 <ikke> It mentions it wasn't backported
2021-10-16 06:47:37 <ikke> Trying what ncopa suggested and remove --with-system-ffi
2021-10-16 07:18:52 <sam_> that flag is for libffi
2021-10-16 07:21:59 <ikke> Yes
2021-10-16 07:23:45 <ikke> THe idea is to use the bundled libffi version instead of the system libffi
2021-10-16 07:25:23 <Ariadne> well the libffi needs to be fixed anyway
2021-10-16 07:26:45 <ikke> is this a libffi issue?
2021-10-16 07:30:28 <ikke> So I don't think anything is pending anymore regarding bootstrapping the builders, right?
2021-10-16 07:31:50 <Ariadne> no :)
2021-10-16 07:32:22 <ikke> I think now that main is built against boost1.77, we could move boost1.76 to community
2021-10-16 07:34:17 <ikke> Errors like these started to crop up: ">> ERROR: ghc*: libHSCabal-3.0.1.0-ghc8.8.4.so: path not found"
2021-10-16 07:34:25 <ikke> I suppose related to the latest abuild version
2021-10-16 07:37:45 <Ariadne> seems reasonable
2021-10-16 09:05:16 <nmeum> Ariadne: would you be ok with adding some way to silence the wipe_tmp bootmisc warning (e.g. `wipe_tmp_i_really_know_what_i_am_doing = "YES"`)? or maybe just move the warning to a comment in /etc/conf.d/bootmisc?
2021-10-16 09:07:04 <nmeum> given the lack of an alternative I would personally prefer to continue using wipe_tmp for /var/tmp without having everyone who observes the boot process bothering me about that warning
2021-10-16 09:17:46 <ktprograms> PJ[m]: psykose: I think https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29 should be ready to review. Should the VERSION be increased?
2021-10-16 09:55:49 <andypost[m]> What is valid way to fight with missing libintl_gettext for !26111 - removal of -lang looks weird
2021-10-16 10:01:19 <nmeum> andypost[m]: have you tried linking against libintl with -lintl?
2021-10-16 10:01:56 <andypost[m]> no, checking
2021-10-16 10:02:34 <andypost[m]> nmeum: ah, it was default via gettext-dev
2021-10-16 10:02:47 <andypost[m]> and it's what exactly failing
2021-10-16 13:20:39 <puzzled-user> Hi. Does anyone else experienced rare unexpected shutdowns with 3.13 (linux-lts 5.10.xx) lately ?
2021-10-16 13:21:45 <nmeum> I am not aware of anyone who has complained about that so far, no
2021-10-16 13:23:42 <puzzled-user> nmeum - thank you. happens on 6 different server running kvm/quemu vms recently - hardware is totally different - 2 variants - bios/i9-9900t; bios/i9-10900t different mobo; coreboot/i7-10500t
2021-10-16 13:24:08 <puzzled-user> started happening approximately 2-3 months ago; happens once every 10 days or so
2021-10-16 13:24:11 <ikke> Hmm, haven't noticed it on our infra either
2021-10-16 13:26:02 <nmeum> feel free to open an issue in the bug tracker with more information though if you suspect this to be an alpine problem
2021-10-16 13:26:03 <puzzled-user> thank ikke. we are puzzled. no events in var/log/messages - just sudden shutdown and only messages from openrc boot after someone presses the power button to start the server again
2021-10-16 13:43:52 <ikke> https://build.alpinelinux.org/ ;-)
2021-10-16 13:46:47 <Hello71> smells like flaky power supply
2021-10-16 14:05:59 <andypost[m]> nmeum: I find !21318 ready, please check my changes
2021-10-16 14:12:18 <nmeum> andypost[m]: I think jakub is maintainer, maybe ping him to merge?
2021-10-16 14:17:05 <ikke> anoying. aports-build requires git pull to not fail (ie, also pull something) before it tries to build something
2021-10-16 14:17:25 <ikke> Normally that should not be an issue, but when you just cloned aports, it does nothing
2021-10-16 14:49:33 <abk> Some hardware will shutdown unexpectedly if the power supply results slightly not enough for sustaining the operation. This happens especially if the machines are connected to an UPS or something akin, because then some UPS drain ver-very slowly without raising an alarm, and at some point they very briefly interrupt the supply, thereupon the shutdown.
2021-10-16 15:14:31 <andypost[m]> nmeum: I mean that I reverted your changes because of rpath
2021-10-16 17:50:42 <ikke> Ariadne: hmm, vlan cannot be built because ifupdown-ng conflicts with it
2021-10-16 18:03:50 <ikke> all 3.15 builders are churning now
2021-10-16 18:36:47 <Nulo> Hey, I'm packaging Telegram Desktop v3.1.9. It depends on jemalloc which has long been unmantained. Will it be mantained again?
2021-10-16 18:37:33 <ikke> Nulo: https://pkgs.alpinelinux.org/package/edge/community/x86_64/telegram-desktop
2021-10-16 18:37:50 <Nulo> ikke, Yes, that version is 2.7.5
2021-10-16 18:38:15 <Nulo> From May 9
2021-10-16 18:38:38 <ikke> Nulo: So you're trying to upgrade it?
2021-10-16 18:38:44 <Nulo> ikke, indeed
2021-10-16 18:38:49 <ikke> ok
2021-10-16 18:39:10 <ikke> So, for a package to be maintained, it needs a maintainer
2021-10-16 18:39:18 <Nulo> Figured that much
2021-10-16 18:39:49 <Nulo> I was just wondering why such a package wouldn't be maintained. Many packages need workarounds because of the lack of jemalloc
2021-10-16 18:40:26 <ikke> 21836d30f5db21f9f3bb4fe3d70ddd4802ed9541
2021-10-16 18:40:30 <mps> jemalloc is not needed with musl malloc-ng
2021-10-16 18:41:55 <mps> especially not with software like clients to some servers
2021-10-16 18:42:23 <Nulo> https://github.com/telegramdesktop/tdesktop/commit/d42fb6d1b94be9c6184ea1cdff98f13549dee22b
2021-10-16 18:43:00 <Nulo> So patch jemalloc out?
2021-10-16 18:43:32 <mps> if it is possible, will be very good idea
2021-10-16 18:44:07 <Nulo> FreeBSD gets special treatment and uses malloc-ng
2021-10-16 18:44:39 <mps> yes, that is good
2021-10-16 18:45:13 <mps> on alpine jemalloc is unsupported for few years now
2021-10-16 18:47:04 <mps> Nulo: prepare merge request (patch) for upgrade without jemalloc and I will try to help
2021-10-16 18:47:13 <ikke> So they took a draft version of mallocng from musl used it as a separate project?
2021-10-16 18:47:16 <ikke> https://github.com/desktop-app/mallocng
2021-10-16 18:47:21 <Nulo> mps, tysm
2021-10-16 18:47:27 <mps> ifc, it the help would be needed :)
2021-10-16 18:48:03 <mps> ikke: yes, till they switch to musl ;)
2021-10-16 18:51:21 <dalias> <mps> jemalloc is not needed with musl malloc-ng
2021-10-16 18:51:22 <dalias> ???
2021-10-16 18:51:30 <dalias> they solve completely different problems
2021-10-16 18:52:00 <dalias> but anyway an app that "depends on" jemalloc, doesn't
2021-10-16 18:52:13 <dalias> it's just trying to do stupid performance hacks at the expense of gigantic memory usage and safety
2021-10-16 18:52:36 <Nulo> Telegram developers aren't the most competent
2021-10-16 18:52:44 <dalias> indeed
2021-10-16 18:53:09 <dalias> did you read about the diffie hellman backdoor in older versions of telegram?
2021-10-16 18:53:15 <Nulo> This applies to the Android apps' developers too, etc
2021-10-16 18:53:57 <dalias> the server provided an "additional secret" to xor into the output of the diffie hellman exchange "in case the endpoints had insufficient entropy"
2021-10-16 18:54:11 <ikke> oh lol
2021-10-16 18:54:13 <Nulo> dalias, I believe I did. But it doesn't matter anyway; all chats (except Secret Chats which only work in Android, iOS and the proprietary macOS apps, and in general they are unusable) are uploaded to their servers
2021-10-16 18:54:36 <dalias> ikke, :)
2021-10-16 18:54:46 <Nulo> https://buttondown.email/cryptography-dispatches/archive/cryptography-dispatches-the-most-backdoor-looking/
2021-10-16 18:55:27 <dalias> yes that's in reference to it
2021-10-16 18:56:20 <dalias> yeah my point was just the utter incompetence and/or malice of telegram developers
2021-10-16 18:56:26 <dalias> (more likely malice imo)
2021-10-16 18:56:34 <mps> dalias: yes, I know difference (not deeply) but I think jemalloc is not good idea to use for such software as telegram client
2021-10-16 18:56:50 <Nulo> Also: the new version depends on rnnoise which isn't packaged yet. I've packaged it, but should I send it in the same patch or a separate one?
2021-10-16 18:56:54 <dalias> mps, yes it's especially a bad idea for something like a messaging client (high attack surface)
2021-10-16 18:57:06 <Nulo> dalias, knowing them it's more likely incompetence. I wish I was kidding
2021-10-16 18:57:12 <dalias> :)
2021-10-16 18:57:27 <Nulo> Telegram is kind of a cult around that russian dude who made a Facebook clone and got rich off of it
2021-10-16 18:58:06 <dalias> yeah i know. the core following/pushing of it is a cult and they have broad reach in a bunch of russia/russian-politics-adjacent countries
2021-10-16 18:58:40 <mps> telegram is good idea, but implementation ... I'm not sure
2021-10-16 18:59:49 <dalias> i'm not even sure what part of the idea is good :-p
2021-10-16 18:59:52 <mps> yet another silo chat/messaging system
2021-10-16 19:00:10 <mps> dalias: end to end encryption
2021-10-16 19:00:32 <dalias> well that's not even a big part of the idea. e2e is only usable in some contexts in it, and historically it *wasn't* e2e
2021-10-16 19:00:47 <dalias> (because of the above DH issue that inherently MITMs it)
2021-10-16 19:00:56 <mps> :)
2021-10-16 19:01:00 <mps> yes
2021-10-16 19:01:20 <Nulo> To be clear: it's not a DH issue. The only e2e things in Telegram are it's calls and Secret Chats which no one uses
2021-10-16 19:01:35 <mps> but with it we have TLA agencies to spy us
2021-10-16 19:01:57 <mps> more TLA*
2021-10-16 19:02:06 <dalias> the only 'idea' of telegram was confusion/muddying the waters about what "e2ee" and "encrypted chat" mean
2021-10-16 19:02:21 <dalias> so that nobody understands it or what security properties to expect
2021-10-16 19:03:02 <Nulo> dalias, massive channels and chats is a really cool property of Telegram which other apps don't really have (WhatsApp/Signal/Messenger/...)
2021-10-16 19:03:14 <mps> yes, I just looked at first announce and it sounded better than in that time other 'big' messengers
2021-10-16 19:03:48 <dalias> massive channels is really not a cool property
2021-10-16 19:03:50 <mps> later reading about it from time to time I concluded it is not well implemented
2021-10-16 19:04:09 <dalias> it's what facilitates massive spread of propaganda
2021-10-16 19:04:44 <mps> but anything is better than whatsup
2021-10-16 19:04:56 <ikke> 
ACTION eats a carrot

2021-10-16 19:04:59 <dalias> whatsapp is so uhg
2021-10-16 19:05:26 <dalias> privacy-oriented marketing while the app harvests all the private info it possibly can from your device
2021-10-16 19:05:45 <dalias> it's not usable without giving it contacts permission (harvest whole social graph)
2021-10-16 19:05:56 <Nulo> <Nulo> Also: the new version depends on rnnoise which isn't packaged yet. I've packaged it, but should I send it in the same patch or a separate one?
2021-10-16 19:06:07 <ikke> same
2021-10-16 19:06:10 <Nulo> I also need to upgrade tg_owt which AFAIK is only used by telegram-desktop
2021-10-16 19:06:11 <dalias> and to view any images you receive you have to give it full "sd card" access
2021-10-16 19:06:30 <mps> Nulo: try first in testing to see will it build
2021-10-16 19:06:44 <dalias> i would assume it at least harvests all EXIF
2021-10-16 19:06:58 <dalias> to bypass lack of location permission
2021-10-16 19:07:02 <Nulo> dalias, that also applies to most messengers because of Android problems. Android 11 introduces more granular permissions that allow only giving permission to a specific paart
2021-10-16 19:08:09 <dalias> nulo, no other messagers seem to have that problem
2021-10-16 19:08:31 <dalias> and it's not even a fundamental limitation in whatsapp's data model
2021-10-16 19:08:41 <Nulo> Telegram and Signal do AFAIK 
2021-10-16 19:08:58 <dalias> if you pair the web client with your phone, then it can access the images just fine with no sdcard perms in the app
2021-10-16 19:11:50 <dalias> so they're intentionally breaking ability to just view the images directly in the app
2021-10-16 19:11:52 <Nulo> BTW you can just use Shelter for giving those permissions in a sandboxed environment
2021-10-16 19:11:59 <dalias> shelter?
2021-10-16 19:12:15 <dalias> ahh
2021-10-16 19:31:01 <Nulo> Is there a way to avoid apk from installing and removing dependencies every time?
2021-10-16 19:31:11 <dalias> ?
2021-10-16 19:31:11 <ikke> no
2021-10-16 19:31:23 <ikke> other than explicitly adding dependencies 
2021-10-16 19:35:04 <ikke> Nulo: context: https://ariadne.space/2021/04/25/why-apk-tools-is-different-than-other-package-managers/
2021-10-16 19:37:47 <Ariadne> telegram chats are a mess
2021-10-16 19:38:17 <Ariadne> there’s a huge amount of criminal activity going on using telegram
2021-10-16 19:38:38 <Ariadne> tons of chats relating to credit card fraud etc
2021-10-16 19:39:01 <dalias> :-p
2021-10-16 19:40:22 <Nulo> ikke, love that but no clue how that changes anything :P
2021-10-16 19:40:54 <Nulo> I would like to be able to just "apk add apkbuild-deps:apkbuild" or something like that to avoid adding and removing every single time 
2021-10-16 19:41:13 <Nulo> To reduce the time taken in "edit APKBUILD and build" cycle
2021-10-16 19:44:46 <ikke> oh, you want to prevent abuild from removing dependencies
2021-10-16 19:45:02 <ikke> That's a different matter
2021-10-16 19:45:03 <Nulo> I guess
2021-10-16 19:45:13 <ikke> You can edit /etc/abuild.conf
2021-10-16 19:45:27 <ikke> there is a CLEANUP variable
2021-10-16 19:47:35 <mps> credit cards are fraud by itself :)
2021-10-16 19:56:39 <solkozor> yes, life is a mess, there is a huge amount of criminal acitivty around
2021-10-16 20:04:18 <Nulo> It seems tg_owt (a telegram-desktop dependency) depends on usrsctp, but the repo includes changes that seem to be from a fork
2021-10-16 20:04:41 <Nulo> A Google/ChromiumOS fork to be specific
2021-10-16 20:07:17 <Nulo> Should I let tg_owt use it's own usrsctp version?
2021-10-16 20:08:33 <mps> I would ask current maintainer
2021-10-16 20:09:25 <mps> nice, crystal also failed with openssl3
2021-10-16 20:09:50 <ikke> mps: everything should build now against openssl1.1-compat
2021-10-16 20:11:09 <Nulo> Newbyte, Should I let tg_owt use it's own usrsctp version?
2021-10-16 20:11:16 <mps> yes, I know. or to wait while Ariadne change it back to openssl
2021-10-16 20:11:38 <ikke> The next step is only renaming packages
2021-10-16 20:11:58 <mps> I mean this
2021-10-16 20:14:52 <mps> need to build crystal static and not sure will it be ok with openssl1.1-compat-dev
2021-10-16 20:17:37 <mps> oh, I will have to destroy my development lxcs for this
2021-10-16 20:17:49 <mps> will consider tomorrow what to do
2021-10-17 00:38:43 <ktprogra1s> Is LXC or chroot better for packaging?
2021-10-17 01:39:11 <smcavoy> a `abuild rootbld` will not use any system packages so any deps that are already installed will not be used but you could have much the same on an lxc container or vm
2021-10-17 01:45:11 <nasuna>  I'm building input-wacom from source on alpine, and ./configure gives me a error saying it finds no module building environment. Its looking for header files in '/usr/src/linux-$(uname -r)/' when Alpine linux header files are in /usr/include/linux/'. Should I edit the configure script directly to point at '/usr/include/linux/', or is there a better way of doing this?
2021-10-17 01:45:14 <nasuna> the aports wacom module request thread has a comment recommend building module from source but no mention of changes to ./configure, so I wonder i might screwed up even something before ./configure. 
2021-10-17 01:45:29 <ktprogra1s> smcavoy: Thanks, I'll try that
2021-10-17 01:46:30 <Hello71> what is "input-wacom"
2021-10-17 01:46:56 <PJ[m]> I assume xf86-input-wacom ?
2021-10-17 01:47:14 <Hello71> oh yeah, CONFIG_HID_WACOM still isn't set
2021-10-17 01:48:04 <nasuna> yeah, im trying to build the module so i can use my tablet on an alpine system
2021-10-17 01:49:00 <Hello71> huh, input-wacom is available out of tree
2021-10-17 01:50:01 <Hello71> for building out-of-tree modules, you need to install linux-lts-dev, not linux-headers
2021-10-17 01:50:09 <nasuna> oh!
2021-10-17 01:50:15 <Hello71> confusingly they are both called "kernel headers"
2021-10-17 01:50:16 <nasuna> ok
2021-10-17 01:50:31 <Hello71> and have similar files
2021-10-17 02:00:29 <nasuna> Hello71 thank you! It fix the problem
2021-10-17 03:28:53 <xkrz> there is a bug in pipewire 0.3.29-r2 (main repo) that prevents from saving recording device settings, this is annoying because I have to set up everything manually each time I start recording with some software
2021-10-17 03:29:17 <xkrz> been testing with newer versions and it's been fixed
2021-10-17 03:30:06 <xkrz> no idea if it has been fixed specifically in 0.3.30, will check that out soon
2021-10-17 03:39:09 <Saijin_Naib[m]> So how does that manifest? You set your levels, etc and it just gets ignored each session?
2021-10-17 03:41:15 <xkrz> I set up all the recording devices (choose Desktop Audio from... X, etc), then close all the recording programs. When I launch the programs again I see all settings at default
2021-10-17 03:51:55 <ktprogra1s> What is the standard on where the -doc package should put non-manpage files?
2021-10-17 06:20:59 <bratkartoffel> can someone please merge !26354? i'd really like to see java 17 in 3.15
2021-10-17 08:39:43 <ikke> #13092
2021-10-17 08:44:26 <ikke> wow, aarch64 already finished main
2021-10-17 08:45:11 <ikke> not sure if that's correct
2021-10-17 09:08:22 <PureTryOut> do the builders not build things in order? I see packages failing on deps being not available but they just haven't been built yet
2021-10-17 09:08:45 <ikke> PureTryOut: in generally they do, but lua-aports only looks at top-level dependencies
2021-10-17 09:08:52 <ikke> dependencies of subpackages are not taken into account
2021-10-17 09:09:04 <PureTryOut> Hmm ok
2021-10-17 09:09:11 <PureTryOut> Strange 😛
2021-10-17 09:09:24 <ikke> It just sources the APKBUILD
2021-10-17 09:09:43 <ikke> so you can only see what is defined on the top level
2021-10-17 09:10:06 <ikke> (source APKBUILD && echo $depends $makedepends $checkedepends)
2021-10-17 09:10:16 <ikke> (roughly)
2021-10-17 09:12:33 <ikke> I'm working (once in a while) on a static parser for APKBUILD which should also be able to 'evaluate' variables in functions
2021-10-17 09:13:16 <nmeum> do we want to move chromium back to testing for 3.15 or no? I have the feeling that we are not really able to provide 6 months of support for chromium
2021-10-17 09:15:31 <Newbyte> Nulo: not sure if you'll see this, but what for?
2021-10-17 09:17:59 <PureTryOut> I'd love a proper APKBUILD parser that can be used from Python too. For a personal tool of mine but also for pmbootstrap from pmOS
2021-10-17 09:19:38 <ikke> hmm, interesting
2021-10-17 09:19:44 <ikke> apparently you can create python modules with go
2021-10-17 09:19:56 <ikke> https://stackoverflow.com/questions/12443203/writing-a-python-extension-in-go-golang
2021-10-17 09:20:37 <ikke> I use https://pkg.go.dev/mvdan.cc/sh to parse shell scripts
2021-10-17 09:21:43 <PureTryOut> Right now in pmbootstrap we do some parsing our own but it's hard and would be nice to source out to some proper library
2021-10-17 09:22:39 <ikke> https://github.com/go-python/gopy
2021-10-17 09:29:07 <PureTryOut> got a link to your work in progress static parser?
2021-10-17 09:30:20 <ikke> This is more for linting, but the principle is the same: https://gitlab.alpinelinux.org/kdaudt/atools-go
2021-10-17 09:31:14 <PureTryOut> Well for linting you still need to parse it, so having that part be usable by external things would be nice
2021-10-17 09:31:46 <ktprogra1s> If a package has a subpackage, should that subpackage have it's own -doc package?
2021-10-17 09:32:56 <ktprogra1s> Also, sorry for asking every day, but is there anything I can do to get https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29 looked at/merged?
2021-10-17 09:33:20 <ikke> ktprogra1s: generally ncopa takes care of that, who is currently away
2021-10-17 09:34:22 <ikke> One tip I can give: make clear in the commit message why this is needed. What problem are you trying to fix and why do you think this is the correct solution
2021-10-17 09:36:00 <ktprogra1s> ikke: I see. And thanks for the tip!
2021-10-17 09:40:50 <ikke> hmm, samba needs pyldb ~2.3, but we now have pyldb 2.4
2021-10-17 09:44:02 <ikke> There is a new samba version available
2021-10-17 09:44:53 <ikke> PureTryOut: It's not there yet, but my goal is to add it here as generic available libraries for go: https://gitlab.alpinelinux.org/alpine/go
2021-10-17 10:00:07 <PureTryOut> That be great!
2021-10-17 10:01:02 <PureTryOut> cc ollieparanoid , would that be useful to us? ^ (read our conversation). A static APKBUILD parser written in Go with Python bindings? It could potentionally replace our own parser in pmbootstrap
2021-10-17 10:03:19 <ktprogra1s> If a package has a subpackage, should that subpackage have it's own -doc package?
2021-10-17 10:08:08 <ikke> ktprogra1s: opinions are divided on that, and depends a bit on the situation
2021-10-17 10:12:12 <ktprogra1s> Basically SWI-Prolog works with XPCE (from the same source tar ball), but there are quite a lot of docs in the xpce folder. So would it be ok to have a swi-prolog-xpce and swi-prolog-xpce-doc ?
2021-10-17 10:20:48 <ollieparanoid> PureTryOut: after several people stepped up and fixed the python based APKBUILD parser we have in pmbootstrap, it's working pretty well. I didn't have an issue with it in a year or so. Therefore I'd rather keep using that than introducing a dependency to pmbootstrap. right now it's "git clone" and you are ready to go on any linux distro - that's quite useful.
2021-10-17 10:55:38 <Newbyte> Does anyone here use rootless X.Org on Alpine?
2021-10-17 11:02:43 <PureTryOut> ollieparanoid: ah yeah makes sense I suppose. I personally do not care about such deps but I can see the appeal. Other question then, any chance the APKBUILD parser can be exported as API for other Python packages? 😉
2021-10-17 11:03:53 <mps> Newbyte: I did some time, but after someone added helper I stopped because usually lazy to rebuild 
2021-10-17 11:04:34 <ollieparanoid> it could be done, if somebody wants to put in the effort to do it, sure. but currently that's not supported. with that being said, we use various pmbootstrap internal functions in e.g. pmaports ci scripts by just importing the files from pmbootstrap. (though that can break, as it did lately, then we have to fix it up)
2021-10-17 11:04:46 <mps> when I fork alpine I will do this again
2021-10-17 11:04:48 <Newbyte> I wonder if rootless X.Org is broken right now. It seems like gdm tries to use it, but it fails
2021-10-17 11:04:57 <Newbyte> fork Alpine? 🤔
2021-10-17 11:05:17 <mps> yes, make it again small and simple
2021-10-17 11:05:50 <Newbyte> and, if I disable rootless X.Org, it "works" (other issues are present, but at least it shows the error screen)
2021-10-17 11:06:27 <mps> it uses now /usr/libexec/Xorg.wrap
2021-10-17 11:07:00 <mps> and it is suid
2021-10-17 11:07:05 <Misthios> mps i wonder what that would be like if i made it simple agaun
2021-10-17 11:07:08 <Misthios> What would u drop
2021-10-17 11:07:41 <Newbyte> mps: yeah, but from what I understand it can drop root privileges? 
2021-10-17 11:08:17 <mps> it is intended for X to not have suid bit set
2021-10-17 11:09:01 <mps> and I don't use these 'new and shiny DMs' so I don't does it really work
2021-10-17 11:09:38 <mps> for some simple DMs X works fine without suid bit and without wrapper
2021-10-17 11:09:58 <Newbyte> Yeah, I wouldn't expect anything else from you. What I'm asking is if rootless X.Org works for anyone on Alpine at the moment.
2021-10-17 11:10:16 <Newbyte> I'm not very good with X.Org 
2021-10-17 11:10:26 <mps> I'm sure it could work
2021-10-17 11:11:01 <mps> not sure with current status. if I invoke it from console as non root it works
2021-10-17 11:12:36 <mps> you can try /usr/libexec/Xorg
2021-10-17 11:13:24 <Newbyte> mps: try adding `needs_root_rights=no` to `/etc/X11/Xwrapper.config`. For me, this causes it to fail to start with `startx`.
2021-10-17 11:13:30 <mps> Misthios: mostly removing useless dependencies and about half of pkgs
2021-10-17 11:13:40 <Newbyte> and, if you invoke X.Org as non-root, are you sure it's not running as root?
2021-10-17 11:14:15 <Newbyte> you can verify with `$ ps -o user $(pgrep Xorg)`
2021-10-17 11:14:25 <mps> Newbyte: not sure right now, but I'm sure it worked before wrapper is added
2021-10-17 11:15:16 <Newbyte> to me it seems like rootless X.Org is completely broken and I'd like to disable support for it until someone feels like fixing it, but I'm not sure how to verify this hypothesis 
2021-10-17 11:16:19 <mps> Newbyte: ah, right I see
2021-10-17 11:16:38 <mps> very nice that this wrapper solved nothing
2021-10-17 11:16:52 <Newbyte> it's possible that some new X.Org version caused regressions 
2021-10-17 11:17:05 <mps> I doubt
2021-10-17 11:17:30 <Newbyte> I wouldn't mind removing the wrapper 
2021-10-17 11:17:32 <mps> I'm sure I used it rootless more than a year
2021-10-17 11:17:53 <Newbyte> but I'm not the maintainer of xorg-server or the author of that wrapper 
2021-10-17 11:20:28 <mps> hmm, maybe will take maintainership of xorg-server and make it more 'clean' again. though of that but waiting new major release which should be in a month or two
2021-10-17 11:28:33 <donoban> ey Newbyte , nice to see you got some progress
2021-10-17 11:29:01 <Newbyte> donoban: I still have no idea why we're getting the "Oh no!" screen in gdm
2021-10-17 11:29:20 <Newbyte> gdm doesn't find the session bus, but it should be started by gdm itself according to one GNOME maintainer 
2021-10-17 11:29:24 <donoban> uhM, after getting properly permissions for tty?
2021-10-17 11:29:36 <Newbyte> yeah, after doing that I get the "oh no!"
2021-10-17 11:29:42 <donoban> oh :\
2021-10-17 11:30:15 <donoban> did you run it with debugging enabled? nothing useful there?
2021-10-17 11:30:26 <Newbyte> how about we make a GNOME on Alpine group to discuss this? I imagine most people here aren't super interested in GNOME, and stuff will get lost in the stream of other messages
2021-10-17 11:30:47 <Newbyte> and yes, but I've not looked into it that much. I was thinking of digging deeper into it today
2021-10-17 11:30:51 <donoban> uhM, maybe an gitlab issue?
2021-10-17 11:31:23 <Newbyte> that is also an option 
2021-10-17 11:46:53 <fabled> the new libreoffice crashes for me with "Fatal exception: Signal 11"
2021-10-17 11:51:48 <donoban> fabled: just opening it?
2021-10-17 11:52:09 <fabled> yeah. it seems there's some rebuild related unexpected package conflicts
2021-10-17 11:52:13 <fabled> investigating it
2021-10-17 11:53:10 <donoban> I tested a little, opened libreoffice, then writter, write something.. no crashes
2021-10-17 11:53:49 <fabled> so seems i had conflicting libreoffice subpackages, some from 6.x some 7.x. ugprade did not work as expected due to icu-libs conflicts
2021-10-17 11:55:49 <fabled> ok, upgrade --prune helped a bit
2021-10-17 11:56:07 <mps> fabled: works here
2021-10-17 11:56:15 <fabled> yeah, works now too
2021-10-17 11:56:25 <mps> good
2021-10-17 12:14:51 <ikke> mv: cannot stat '/home/build/aports/main/samba/pkg/samba/usr/lib/samba/libcmdline-credentials-samba4.so': No such file or directory
2021-10-17 12:14:59 <ikke> Is that lib important?
2021-10-17 12:15:13 <ikke> same with libpopt-samba3-cmdline-samba4.s
2021-10-17 13:47:30 <maxice8> postgresql-bdr-extension is failing to fetch archive
2021-10-17 13:47:43 <ikke> yeah
2021-10-17 13:48:58 <ikke> oof
2021-10-17 13:49:05 <ikke> https://wiki.postgresql.org/wiki/BDR_User_Guide links to a page that seems to be domain parked
2021-10-17 13:49:30 <ikke> Not domain parked
2021-10-17 13:49:38 <ikke> Leads to a whoops page
2021-10-17 13:50:26 <ikke> Can someone take a look at !26498? Upgrading samba to 4.15, but some things have changed
2021-10-17 14:18:18 <ikke> Hmm, somehow bluez-plugins suddenly contains libbluetooth.so*, which makes it conflict with bluez-libs
2021-10-17 14:18:27 <ikke> But this didn't happen before on edge
2021-10-17 14:18:35 <ikke> But I can now reproduce it
2021-10-17 14:19:03 <ikke> Simple solution is to just remove those files, but wonder what changed
2021-10-17 14:46:27 <ikke> oh fun, libical is a python segfault
2021-10-17 14:48:47 <ikke> py3-gobject
2021-10-17 14:55:19 <staceee> Hello there, I'd like to ping someone about a MR I got : https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25253#note_185071
2021-10-17 14:55:57 <staceee> It's about adding a global bashrc that will load profile.d scripts and allow things like autocompletion on non login bash sessions
2021-10-17 14:56:43 <staceee> could be nice if some of you guys could check this O:)
2021-10-17 14:57:02 <PJ[m]> you have lint job failed on it 
2021-10-17 14:57:29 <ikke> Those are not caused by the changes
2021-10-17 14:57:39 <staceee> mhh ya. Thats not about something I changed with this patch :S
2021-10-17 14:58:10 <ikke> oh, line 38 is
2021-10-17 14:58:39 <PJ[m]> I can see that CFLAGS were added in that MR
2021-10-17 14:58:57 <PJ[m]> SP:[AL36]:./APKBUILD:38:CFLAGS should not be overwritten, add $CFLAGS to it
2021-10-17 14:59:09 <ikke> export CFLAGS="$CFLAGS .."
2021-10-17 14:59:31 <staceee> I see
2021-10-17 15:10:09 <ikke> PureTryOut: is there a reason for arm-trusted-firmware to be in main?
2021-10-17 15:40:29 <mps> ikke: yes, it is needed for u-boot
2021-10-17 15:41:19 <ikke> ok, because it now depends on gcc-arm-none-eabi, which is only in community
2021-10-17 15:41:37 <mps> oh, how
2021-10-17 15:42:25 <ikke> 8f743ff4232caa58b2c678b83943034bcc71e05e
2021-10-17 15:42:36 <mps> I see
2021-10-17 15:42:48 <mps> that should be removed
2021-10-17 15:42:48 <ikke> Not sure how this could have been built before
2021-10-17 15:42:57 <ikke> mps: are you able to look at it?
2021-10-17 15:43:05 <mps> yes
2021-10-17 15:43:08 <ikke> thansk
2021-10-17 15:43:53 <mps> options are move some other pkgs to main (have to ask maribu) or remove this deps
2021-10-17 15:44:33 <mps> I think for now is to remove gcc-arm-none-eabi. PureTryOut ?
2021-10-17 15:44:55 <mps> how this 'slipped' in
2021-10-17 15:47:08 <mps> I see how
2021-10-17 15:47:21 <mps> :)
2021-10-17 15:47:57 <mps> ikke: if we wont to unblock builder we have to revert 8f743ff4232caa58b2c678b83943034bcc71e05e
2021-10-17 15:48:54 <ikke> so downgrade back to 2.3?
2021-10-17 15:49:27 <mps> and talk later with maribu to move some package to main, which is already discussed about 5 or more months ago, and didn't moved
2021-10-17 15:49:37 <ikke> Yeah, it's kinda controversial
2021-10-17 15:50:19 <mps> I would ask PureTryOut to revert for now
2021-10-17 15:50:45 <mps> and ask maxice8 to be more careful next time ;)
2021-10-17 15:51:40 <mps> and ask ikke to set gitlab so that at least 3 developers must review MR before merge :D
2021-10-17 15:55:36 <PureTryOut> what? last time I checked it did not depend on gcc-arm-non-eabi
2021-10-17 15:56:34 <mps> I'll try to build it now without gcc-arm-non-eabi
2021-10-17 15:56:50 <PureTryOut> oh seems the package changed since last time I checked
2021-10-17 15:57:12 <PureTryOut> great that something was added to it without notifying me, even though I'm the maintainer of that thing
2021-10-17 15:57:13 <PureTryOut> just revert 8f743ff4232caa58b2c678b83943034bcc71e05e
2021-10-17 15:58:15 <mps> yes it builds without gcc-arm-non-eabi
2021-10-17 15:58:40 <ikke> !22504
2021-10-17 15:58:54 <ikke> PureTryOut: you even gave a LGTM :P
2021-10-17 15:59:45 <ikke> > 
2021-10-17 15:59:47 <ikke> LGTM but rk3399 needs more work before it can be enabled. If you remove it from this MR for now then I'll merge it.
2021-10-17 16:00:41 <mps> I removed it
2021-10-17 16:00:53 <PureTryOut> Oh lol, woops
2021-10-17 16:01:02 <PureTryOut> I did not realize gcc-arm-none-eabi was a problem then
2021-10-17 16:01:34 <andypost[m]> so only libical left to main to pass)
2021-10-17 16:02:23 <ikke> and py3-dbus for armhf
2021-10-17 16:04:50 <pj> hey PureTryOut, I saw your issues on GitHub (that helped me), have you managed to build dotnet using source-build?
2021-10-17 16:05:33 <PureTryOut> In the end no, and I lost interest 😅
2021-10-17 16:05:42 <maribu> Regarding moving gcc arm-none-eabi to main: Usually clang can be used instead, especially if it doesn't depend on some C lib like newlib or picolibc. Since clang is already in main, this might be less controversial
2021-10-17 16:05:48 <pj> I understand why :D
2021-10-17 16:09:54 <maribu> It is a pity that neither picolibc nor newlib can be build with clang. picolibc can indeed be build for one flavor of arm, but not as multilib covering all the flavours newlib-arm-none-eabi or picolibc-arm-none-eabi provides. If clang could be used, this could break the dependency loop between GCC and newlib (and get rid of the -stage1 packages).
2021-10-17 16:09:59 <ikke> Ariadne: Do you think we should build libffi without trampoline?
2021-10-17 16:10:42 <ikke> there's my answer :)
2021-10-17 18:42:36 <pj> what is the status for openssl3? is openssl1.1 going to coexist with ossl3 on edge for now?
2021-10-17 19:12:29 <ikke> openssl1.1 will be the default openssl provider
2021-10-17 19:38:45 <ikke> PureTryOut: We have a cyclic dependency pipewire <-> sdl2
2021-10-17 19:41:55 <psykose> i don't think pipewire itself needs sdl2
2021-10-17 19:43:20 <psykose> according to the gentoo ebuild, the sdl2 dep is for a developer binary and not for end usage, and so they pass -Dsdl2=disabled
2021-10-17 19:43:43 <psykose> i don't think anyone cares about using that out of a pw package
2021-10-17 19:46:31 <psykose> and is apparently only needed for some sdl examples paired with installed tests, separate from the test suite
2021-10-17 19:48:05 <ikke> Any reference for that where I can link to?
2021-10-17 19:49:24 <psykose> https://gitlab.freedesktop.org/search?search=sdl2&group_id=10138&project_id=4753&scope=&search_code=true&snippets=false&repository_ref=master&nav_source=navbar
2021-10-17 19:49:33 <psykose> all the sdl2 using is in example code
2021-10-17 19:49:56 <ikke> Yes, noticed that as well
2021-10-17 19:50:48 <ikke> !abuild-apk add -X https://dl-cdn.alpinelinux.org/alpine/edge/community rust-bootstrap cargo-bootstrap
2021-10-17 19:51:05 <ikke> !26506
2021-10-17 19:52:01 <psykose> looks good
2021-10-18 00:18:13 <ktprograms> What's the difference between apk and abuild-apk? Is it just that abuild-apk doasn
2021-10-18 00:18:24 <ktprograms> * doesn't need sudo?
2021-10-18 01:46:43 <Ariadne> yes
2021-10-18 02:06:07 <ktprograms> ok thanks
2021-10-18 03:57:57 <craftyguy> hmm I get a 500 error in gitlab when trying to make a new merge request. anyone else experience that too?
2021-10-18 04:00:32 <maxice8> just tried and worked here
2021-10-18 04:03:09 <pj> if your fork master branch is too old, it will do that
2021-10-18 04:06:14 <craftyguy> ah yeah, that was it. I usually ignore that branch, so it was *quite* outdated
2021-10-18 06:38:09 <ikke> morning
2021-10-18 06:39:10 <mps> good morning (ikke goede morgen)
2021-10-18 06:40:17 <ikke> Добро јутро
2021-10-18 06:41:32 <mps> :)
2021-10-18 06:42:06 <Misthios> Oh no dutch, good morning
2021-10-18 06:44:40 <mps> Misthios: you are also Dutch?
2021-10-18 06:44:45 <Misthios> ye
2021-10-18 06:45:13 <mps> I see, (too much Dutchmen on this channel ;) )
2021-10-18 06:45:20 <Misthios> never enough
2021-10-18 06:45:27 <mps> agree
2021-10-18 06:46:43 <mps> I have nice friends in NL
2021-10-18 06:47:16 <mps> hmm, nice or fine or good, not sure for proper term
2021-10-18 06:57:43 <bratkartoffel> ikke: i've split !26354 into multiple commits, can you please merge this?
2021-10-18 06:58:30 <bratkartoffel> but maybe it should be delayed over night, the builds will block the builders for some time
2021-10-18 06:58:31 <ncopa> good morning
2021-10-18 07:00:07 <bratkartoffel> good morning Natanael
2021-10-18 07:02:15 <liske> good morning
2021-10-18 07:02:57 <ktprograms> ncopa: Hi! I was told you handle MRs for alpine-conf, so could you please take a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29? It allows you to call lbu include from any directory with relative paths.
2021-10-18 07:07:22 <liske> keepalived is cannot be installed on edge: keepalived-common depends on keepalived and keepalived-snmp but both being mutually exclusive
2021-10-18 07:08:42 <liske> in APKBUILD depends is set to empty for the -common subpackages, so it is tracedeps pulling them in?
2021-10-18 07:09:16 <liske> could that be avoided without using option !tracedeps?
2021-10-18 07:12:44 <ikke> They don't seem to contain any libraries?
2021-10-18 07:13:07 <ikke> They only both  contain /usr/sbin/keepalived
2021-10-18 07:15:51 <ncopa> why do we have a separate keepalived-snmp package?
2021-10-18 07:17:09 <ncopa> 53539e117ead530fd909bff21b1d985335a3ac4e
2021-10-18 07:18:04 <ncopa> ok. snmp-libs are 2.5M
2021-10-18 07:23:26 <ncopa> problem with keepalived-common is that $ ls -la pkg/keepalived-common/usr/bin/genhash 
2021-10-18 07:23:26 <ncopa> lrwxrwxrwx    1 ncopa    ncopa           18 Sep 20 10:01 pkg/keepalived-common/usr/bin/genhash -> ../sbin/keepalived
2021-10-18 07:23:31 <ncopa> its a symlink
2021-10-18 07:28:29 <mps> hmm, !26522 fails on CIs but passes fine in lxcs
2021-10-18 07:28:53 <mps> are CIs in 'sane' state
2021-10-18 08:01:39 <liske> ncopa: would moving the genhash symlink to keepalived+keepalived-snmp solve it?
2021-10-18 08:35:30 <ikke> liske: I expect it to
2021-10-18 08:40:18 <ktprograms> Why is db-dev deprecated?
2021-10-18 08:45:42 <ncopa> berkley db moved to a problematic license in version 6 so we cannot upgrade from db 5 to 6
2021-10-18 08:46:05 <ncopa> solution is to avoid use db-dev
2021-10-18 08:46:36 <ktprograms> ncopa: Ok thanks
2021-10-18 08:49:28 <ikke> rust and go should be bootstrapped on most arches now
2021-10-18 08:49:32 <fiesh> compilation of 32 bit binaries is broken under alpine: docker run -it -it alpine:3.14.2 sh -c "sed -i -e s/https/http/ /etc/apk/repositories && apk add g++ && echo -e '#include<chrono>\nstatic_assert(sizeof(std::size_t) == sizeof(size_t));' > /tmp/t.cpp && g++ -c -m32 /tmp/t.cpp" fails, meaning std::size_t and size_t differ
2021-10-18 08:49:39 <fiesh> any hints on where I should open a ticket?
2021-10-18 08:49:55 <fiesh> (might be a musl issue, not sure -- but either way I suppose a ticket in alpine makes sense since it's a bug there as well)
2021-10-18 09:03:42 <ncopa> fiesh: its a musl issue, it does not support multiarch (64 bit and 32 bit build on same machine)
2021-10-18 09:04:28 <fiesh> ncopa: oh it's a known shortcoming?
2021-10-18 09:04:38 <ncopa> if you need to build for 32 bit on a 64 bit machine you will have to do proper cross-compile
2021-10-18 09:04:39 <ncopa> yes
2021-10-18 09:05:03 <fiesh> ah, thanks!
2021-10-18 09:05:08 <ncopa> or you can use a 32 bit environment (eg use a 32bit docker image)
2021-10-18 09:05:38 <fiesh> (I wish it had an `#if .... #error musl doesn't support multiarch dude #endif` somewhere instead of making std::size_t differ from size_t ;-))
2021-10-18 09:06:08 <fiesh> ncopa: ok perfect, thanks, thought this was a bug (well kinda is, but a known one I guess)
2021-10-18 09:06:37 <ncopa> i stil find this a bit surprising though
2021-10-18 09:06:39 <mps> I don't think it is bug
2021-10-18 09:06:52 <ncopa> what size is std::size_t?
2021-10-18 09:07:07 <ncopa> oh... right, i am confused
2021-10-18 09:07:14 <ncopa> i was thinking time_t which is something else
2021-10-18 09:07:58 <fiesh> ncopa: sizeof (uintmax_t) == sizeof (unsigned long long)
2021-10-18 09:08:16 <fiesh> mps: I think if the build environment violates the C++ standard, it's a bug
2021-10-18 09:08:41 <mps> well
2021-10-18 09:09:19 <ncopa> https://www.openwall.com/lists/musl/2014/08/21/3
2021-10-18 09:09:41 <ncopa> the problem is the -m32
2021-10-18 09:10:13 <ncopa> we should probably install the 32bit headers in a different location and point gcc to this location when -m32 is used
2021-10-18 09:10:55 <fiesh> ncopa: I think alpine should do this if it makes sense, not me by hand ;-)
2021-10-18 09:15:00 <Ariadne> huh?
2021-10-18 09:15:24 <Ariadne> musl isn’t really related to multiarch
2021-10-18 09:15:55 <Ariadne> distros enable multiarch through adjusting how the tooling works
2021-10-18 09:16:54 <Ariadne> -m32 is different
2021-10-18 09:17:42 <fiesh> ncopa: oh sorry, "we", not "you", misread
2021-10-18 09:24:31 <ncopa> i think i meant multilib
2021-10-18 09:24:34 <ncopa> or what it is called
2021-10-18 09:25:35 <Ariadne> i prefer "awful hack" to describe -m32 :D
2021-10-18 09:29:58 <mps> how to install checkdepends pkgs with abuild
2021-10-18 09:36:01 <Ariadne> `abuild dep` should do it?
2021-10-18 09:36:43 <mps> it doesn't, I thought it will
2021-10-18 09:36:53 <mps> abuild deps
2021-10-18 09:37:40 <mps> ok, 'by hand' works always :)
2021-10-18 09:45:21 <Ariadne> ???????????
2021-10-18 09:45:30 <Ariadne> why is there circular dependency between polkit and elogind
2021-10-18 09:47:21 <Ariadne>     community/elogind: enable polkit support again
2021-10-18 09:47:21 <Ariadne>     
2021-10-18 09:47:21 <Ariadne>     Without polkit, the Phosh UI is broken on postmarketOS
2021-10-18 09:47:33 <Ariadne> with polkit, we cannot build the distro
2021-10-18 09:48:19 <Ariadne> DylanVanAssche: another solution needs to be found to solve this problem
2021-10-18 09:49:12 <ikke> fd0e522762796a182e2d1c1f6e5cf6ebf2b2a74f
2021-10-18 09:49:20 <ikke> #13095
2021-10-18 09:51:34 <Ariadne> well, that explains that
2021-10-18 09:51:40 <DylanVanAssche> Ariadne: I haven't touched polkit and elogind at all since a while. It was largely refactored to fix a bunch of issues as ikke posted it here.
2021-10-18 09:58:48 <Ariadne> sdl2 cannot depend on pipewire at all
2021-10-18 09:58:55 <Ariadne> because we still have circular dep
2021-10-18 09:59:11 <Ariadne> ffmpeg -> sdl2 -> pipewire -> ffmpeg
2021-10-18 10:04:10 <PureTryOut> huh, why does ffmpeg depend on sdl2?
2021-10-18 10:10:38 <Ariadne> ffplay
2021-10-18 10:12:50 <ikke> circular dependencies are fun™
2021-10-18 10:19:39 <ikke> ncopa: did you previously only enable -s -k for buildrepo when main was finished building?
2021-10-18 10:23:14 <ncopa> i dont remember. i think i started with -s -k and then when realizing it took too long time to fix one by one i removed it
2021-10-18 10:24:20 <ikke> I noticed that it quite soon finished main (with failed packages) and continued with community
2021-10-18 10:24:25 <ikke> which makes sense with -s
2021-10-18 10:28:05 <PureTryOut> Ariadne: do we need ffplay? It seems to mostly be a testbed for ffmpeg apis?
2021-10-18 10:28:31 <Ariadne> ffplay is commonly used in scripts
2021-10-18 10:28:41 <Ariadne> i mean
2021-10-18 10:28:44 <Ariadne> i don't personally care
2021-10-18 10:28:51 <PureTryOut> oh ok nvm then
2021-10-18 10:28:51 <Ariadne> do what you want, just don't create circular deps
2021-10-18 10:29:14 <PureTryOut> (I didn't create this one but sure, if I notice it I try to get rid of them)
2021-10-18 10:50:04 <psykose> ffmpeg should be disabled for pipewire
2021-10-18 10:50:09 <ikke> ncopa: !26525
2021-10-18 10:53:26 <psykose> PureTryOut: you can just add -Dffmpeg=disabled for pipewire, the ffmpeg integration is just a spa plugin that nobody uses and hasn't been touched in over a year
2021-10-18 10:53:37 <psykose> the default is also disabled for it in upstream for that reason
2021-10-18 10:54:33 <PureTryOut> oh good, awesome
2021-10-18 10:58:24 <psykose> vulkan should also be removed from the configure for a similar reason; really there's no need to differ from the meson_options for things explicitly disabled
2021-10-18 10:58:51 <Misthios> Cogitri[m] !25551 one more review plz
2021-10-18 11:20:24 <clandmeter> ikke: what about rv64 build key?
2021-10-18 11:21:44 <ikke> clandmeter: i thought we didn't want to do 3.15 for rv64?
2021-10-18 11:21:52 <clandmeter> nope
2021-10-18 11:21:59 <clandmeter> thats not what i mean
2021-10-18 11:22:02 <ikke> So I did not bother to generate a new key there
2021-10-18 11:22:19 <clandmeter> does this update also affect edge?
2021-10-18 11:22:23 <ikke> no
2021-10-18 11:22:28 <clandmeter> why not?
2021-10-18 11:22:43 <ikke> For edge, we use different keys, and we can only start to use them later
2021-10-18 11:22:54 <ikke> or
2021-10-18 11:23:55 <clandmeter> well for instnace, one we do make an stable release for rv64 i bet we will forget updating the key right?
2021-10-18 11:28:27 <ncopa> good job with the TSC meeting!
2021-10-18 11:28:35 <ncopa> the minutes is easy to read
2021-10-18 11:28:45 <ncopa> and seems like the decisions was good
2021-10-18 11:29:51 <clandmeter> ncopa: one items that is not added is we want to skip rv64 stable release due to missing hardware and check().
2021-10-18 11:30:08 <ncopa> ok
2021-10-18 11:31:10 <clandmeter> ncopa: one other thing that i wonder, why bootstrap stable builder from previous stable instead of edge?
2021-10-18 11:32:09 <ncopa> because previous stable is considered stable, but i guess it does not matter that much
2021-10-18 11:32:31 <ncopa> what would be the benefit of bootstrapping from edge?
2021-10-18 11:33:10 <clandmeter> for one, what if prev stable does not exist
2021-10-18 11:33:22 <ncopa> then we use edge i guess?
2021-10-18 11:33:33 <clandmeter> that was not my question :)
2021-10-18 11:33:44 <clandmeter> is there a specific reason to use stable instead of edge?
2021-10-18 11:34:09 <ikke> Like the script mentions, we probably want to be able to create a builder from scratch instead of copying it
2021-10-18 11:34:10 <clandmeter> edge is more close to new release compared to prev stable
2021-10-18 11:34:38 <ikke> we copy a stable builder, but then upgrade it to edge :)
2021-10-18 11:34:47 <clandmeter> i know what we do
2021-10-18 11:34:47 <ncopa> i dont think it matters much
2021-10-18 11:34:57 <clandmeter> we still boostrap from something
2021-10-18 11:35:01 <ncopa> we rebuild world anyway
2021-10-18 11:35:31 <clandmeter> so the packages would be build for similar env
2021-10-18 11:35:42 <clandmeter> from*
2021-10-18 11:35:50 <ncopa> copying previous stable is convenient because it is set up similar and less config chagnes is needed compared to if we used edge
2021-10-18 11:36:35 <ncopa> for example we store distfiles in different location
2021-10-18 11:37:15 <ikke> would ansible be usable to automate this?
2021-10-18 11:37:29 <ncopa> possibly
2021-10-18 11:37:52 <clandmeter> do we want to use something like that just to boostrap?
2021-10-18 11:38:28 <ikke> seems like ansible is made for those kinds of jobs
2021-10-18 11:39:12 <clandmeter> you will need to put the build keys inside ansible or related
2021-10-18 11:39:35 <ikke> vault, if we trust that
2021-10-18 11:39:41 <clandmeter> think it adds a lot of magic to do something simple
2021-10-18 11:40:01 <clandmeter> you would want to automate it completely?
2021-10-18 11:40:22 <ikke> as much as possible
2021-10-18 11:42:02 <clandmeter> its possible, but it needs stuff like vault and knowledge where you want to boostrap it.
2021-10-18 11:42:35 <clandmeter> and you need python on each builder host
2021-10-18 11:47:42 <ikke> Is that a big issue?
2021-10-18 11:55:19 <clandmeter> ive seen bigger issues
2021-10-18 13:38:21 <ncopa> im gonna merge llvm12 now
2021-10-18 13:38:34 <ncopa> i have built it in my dev env and it builds on x86_64 at least
2021-10-18 13:39:55 <ikke> alright :)
2021-10-18 13:40:28 <ikke> I'm also still working on boost. I've moved 1.77 to main, so it should be the default
2021-10-18 13:40:43 <ikke> but still working on rebuilding / switching community
2021-10-18 13:45:26 <ncopa> oh, cool! then we have most of the things we wanted for 3.15 release
2021-10-18 13:46:09 <ikke> ghc is still an issue
2021-10-18 13:46:16 <ikke> It's still built to ffi3.3 atm
2021-10-18 13:46:31 <ikke> It should work now with ffi3.4 now that the trampoline has been disabled
2021-10-18 13:46:36 <ikke> Just locally had one test failure
2021-10-18 13:46:54 <mps> I created crystal 1.2.0 upgrade MR already and waiting for llvm12 to finish to test zig 0.8.1
2021-10-18 13:48:18 <mps> only don't understand why ncurses fails on CI while works fine in lxc
2021-10-18 13:49:11 <mps> ncurses upstream author announced 6.3 major release in near future
2021-10-18 13:50:00 <mps> hope this will be resolved before 3.15 release
2021-10-18 13:50:37 <mps> it's a pity we cannot have riscv64 released
2021-10-18 13:51:15 <ikke> It's a pitty rv64 does not have proper server grade hw yet
2021-10-18 13:58:05 <ncopa> does current ghc build at all?
2021-10-18 13:58:37 <ncopa> i think we should try use the bundled libffi for ghc instead of system libffi, but I was not able to do so last week
2021-10-18 14:08:46 <ikke> I tried that
2021-10-18 14:09:02 <ikke> but it appeared it still linked against the system libffi
2021-10-18 14:09:26 <ikke> ghc + libffi3.3 does build
2021-10-18 14:10:44 <ikke> (I had to mask libffi-dev to make it build)
2021-10-18 14:11:23 <ikke> The goal is to switch it off libffi3.3-compat to libffi, but it had one test failure
2021-10-18 14:11:39 <ncopa> with libffi 3.4?
2021-10-18 14:11:45 <ikke> yes
2021-10-18 14:11:54 <ncopa> would be nice to update it as well
2021-10-18 14:12:35 <ikke> andypost[m] / J0WI were working on that, but that resulted in even more test failures in CI
2021-10-18 14:12:56 <ikke> !20134
2021-10-18 17:50:01 <nmeum> hm
2021-10-18 17:50:06 <nmeum> that llvm12 upgrade doesn't seem very polished
2021-10-18 17:50:18 <ikke> what's up?
2021-10-18 17:51:54 <nmeum> I have some issues with linking zig against the new llvm12
2021-10-18 17:52:00 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25551#note_186235
2021-10-18 17:52:06 <nmeum> jakub also seems to be running into some issues
2021-10-18 18:23:22 <Hello71> yes, it needed much more review before merging
2021-10-18 18:31:40 <nmeum> nod
2021-10-18 18:31:57 <nmeum> I believe jakub is working on a cleanup so I will just wait for now but this needs to be fixed
2021-10-18 18:32:36 <Ariadne> :D
2021-10-18 18:55:19 <ncopa> oh sorry
2021-10-18 18:59:27 <andypost[m]> ncopa: consider to backport to 3.14 !!25610
2021-10-18 19:01:14 <ikke> andypost[m]: I suppose there is patch available for that CVE?
2021-10-18 19:02:47 <ikke> there is no*
2021-10-18 19:02:47 <andypost[m]> or patch release, thank you will check
2021-10-18 19:03:19 <ikke> 4.15 has quite some changes
2021-10-18 19:03:26 <ikke> like you noticed, remove binaries / libraries
2021-10-18 19:04:45 <mps>  https://www.samba.org/samba/history/samba-4.14.8.html
2021-10-18 19:05:31 <mps> does it fixes this CVE?
2021-10-18 19:05:54 <ikke> It's not mentioned
2021-10-18 19:06:02 <nmeum> ncopa: happens (:
2021-10-18 19:08:20 <mps> it mentions this ' BUG 14854: samldb_krbtgtnumber_available() looks for incorrect string.' could it be this CVE
2021-10-18 19:08:49 <ikke> A null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ 
2021-10-18 19:08:58 <ikke> https://security.alpinelinux.org/vuln/CVE-2021-3671
2021-10-18 19:09:57 <mps> looks like it is invalid https://www.suse.com/security/cve/CVE-2021-3671.html
2021-10-18 19:10:51 <mps> details https://bugzilla.suse.com/show_bug.cgi?id=1191622
2021-10-18 19:12:22 <ikke> So depends on whether we use a bundled version of kerberos or system version
2021-10-18 19:12:34 <ikke> "this bug refers to Heimdal Kerberos source tree bundled with samba sources, but we build samba against system's MIT Kerberos."
2021-10-18 19:13:25 <mps> 'we' use bundled heimdal
2021-10-18 19:13:34 <ikke> ok, so then I guess we are affected
2021-10-18 19:13:47 <mps> yes
2021-10-18 19:15:17 <mps> samba changelog have this 'BUG 14817: An unuthenticated user can crash the AD DC KDC by omitting theserver name in a TGS-REQ.
2021-10-18 19:15:29 <mps> and more times mentioned
2021-10-18 19:15:54 <mps> so looks like 4.14.8 fixes this
2021-10-18 19:16:03 <ikke> yes, seems so
2021-10-18 19:16:43 <ikke> nvd does not have any information on this yet
2021-10-18 19:17:43 <ncopa> we should update samba-4.14.x
2021-10-18 19:17:49 <ncopa> not jump to samba 4.15
2021-10-18 19:17:58 <ncopa> not in a stable branch
2021-10-18 19:18:12 <ikke> Yea
2021-10-18 19:18:27 <Hello71> i think we already agreed on that, question is whether there is a fix in 4.14 and which version we should pick
2021-10-18 19:18:54 <mps> https://altlinux.pkgs.org/sisyphus/classic-aarch64/samba-4.14.8-alt1.aarch64.rpm.html
2021-10-18 19:19:05 <mps> there is mentioned above CVE
2021-10-18 19:19:57 <mps> Fix an unuthenticated user can crash the AD DC KDC by omitting the server name in a TGS-REQ (Fixes: CVE-2021-3671).
2021-10-18 19:20:34 <ikke> So seems like 4.14.8 fixes it
2021-10-18 19:21:27 <mps> seems so
2021-10-18 19:36:18 <ncopa> Misthios: I was apparently too quick on merging your MR. It did build everything in my local build env and I had tried it a couple of times and really wanted llvm12 in before 3.15. I'm very grateful for the work you put in there
2021-10-18 19:36:45 <ncopa> I simply didn't understand it needed closer look
2021-10-18 19:42:05 <Misthios> No problem although i will make sure to not make a mess next time
2021-10-19 01:44:12 <anjan> hi, can someone please review my MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24275
2021-10-19 07:06:14 <ncopa> good morning
2021-10-19 07:06:45 <mps> good morning
2021-10-19 07:15:12 <Misthios> good morning
2021-10-19 07:21:45 <ncopa> i worked on ghc 9.0.1 last night and I got it to build and pass all tests except 1. https://gitlab.haskell.org/ghc/ghc/-/issues/20523#note_385158
2021-10-19 07:35:15 <ikke> ncopa: right, that was the test that failed for me too
2021-10-19 07:52:33 <ncopa> it passes if gdb is uninstalled
2021-10-19 07:52:47 <ncopa> but now it fails on cpio segfaulting
2021-10-19 08:02:49 <Ariadne> which cpio?
2021-10-19 08:06:36 <ncopa> gnu cpio
2021-10-19 08:06:48 <ncopa> Hello71: did you follow up on the cpio thingy?
2021-10-19 08:07:23 <ncopa> Ariadne: i think the cve fix is incomplete and need one or two more commits backported
2021-10-19 08:07:52 <Ariadne> CVE fix for gnu cpio?
2021-10-19 08:25:27 <Ariadne> how can we resolve this circular dep with elogind/polkit
2021-10-19 08:25:33 <Ariadne> has anyone looked at it yet
2021-10-19 08:31:38 <Ariadne> ncopa: why is cpio used?  is it used by ghc or is it used by the APKBUILD?  why not use pax?
2021-10-19 08:32:25 <Ariadne>         echo "$pfiles" | cpio -pamVd "$subpkgdir"
2021-10-19 08:33:12 <Ariadne> this can be done with pax
2021-10-19 08:33:39 <Ariadne> or tar, even
2021-10-19 08:34:40 <Ariadne> or find
2021-10-19 08:36:24 <Ariadne> ncopa: fyi, `jmpq` vs `jmp` is semantically equivalent in that instruction
2021-10-19 08:40:14 <Ariadne> i think it is just busted test :)
2021-10-19 08:40:23 <Ariadne> but tell me more about this GNU cpio
2021-10-19 08:40:30 <Ariadne> is the thing i pasted what is crashing?
2021-10-19 08:43:21 <ktprograms> Can I specify optional dependencies in APKBUILD?
2021-10-19 08:44:58 <Ariadne> no
2021-10-19 08:47:21 <ktprograms> I'm packaging screenkey, and libappindicator, slop and ttf-font-awesome are all optional accordint to the project's documentation and the Arch package: https://archlinux.org/packages/community/any/screenkey/
2021-10-19 08:47:34 <ktprograms> So should they be in depends or not?
2021-10-19 08:48:17 <mps> no
2021-10-19 08:49:04 <mps> alpine prefer minimum deps, only what is essential for pkg
2021-10-19 08:50:26 <ktprograms> mps: So how should I indicate optional deps?
2021-10-19 08:50:39 <mps> you can't
2021-10-19 08:50:40 <Ariadne> those aren't runtime-optional
2021-10-19 08:50:51 <Ariadne> they are optional in that you may build with them
2021-10-19 08:50:53 <Ariadne> or not
2021-10-19 08:50:59 <Ariadne> so, either build with them, or not
2021-10-19 08:51:51 <mps> alpine is not debian/ubuntu (still)
2021-10-19 08:52:19 <ktprograms> So I guess don't build with them? Also should there be a dependency on whichever package provides libX11.so.6 (screenkey needs it)
2021-10-19 08:52:55 <mps> ktprograms: abuild automatically scans for build deps and add them
2021-10-19 08:53:18 <Ariadne> i mean
2021-10-19 08:53:18 <ktprograms> Ok thanks
2021-10-19 08:53:20 <Ariadne> build with them
2021-10-19 08:53:23 <Ariadne> if you want to
2021-10-19 08:53:31 <Ariadne> like if there is some compelling reason to build with them
2021-10-19 08:53:33 <Ariadne> then do so
2021-10-19 08:53:39 <Ariadne> if there is not, then don't
2021-10-19 08:53:47 <Ariadne> that's kinda the decisions you have to make as a maintainer
2021-10-19 08:53:55 <mps> so, if you have libx11-dev in makedepends abuild will add them
2021-10-19 09:02:41 <ncopa> ghc aport should probably not use cpio in the first place, but cpio should also be fixed
2021-10-19 09:03:27 <ncopa> seems like Hello71 did follow up in dfc99097d6372098d36f33a1c80961d3639293f2
2021-10-19 09:04:05 <ncopa> but cpio still segfaults
2021-10-19 09:04:40 <ikke> I thought there was an MR adding the other commits, but cannot find it anymore
2021-10-19 09:05:10 <ikke> oh, that was merged
2021-10-19 09:05:16 <ikke> !26330
2021-10-19 09:05:38 <ikke> But that was not enough?
2021-10-19 09:05:40 <ncopa> cpio still segfaults
2021-10-19 09:07:20 <Ariadne> i mean, you can try without the CVE fix to rule it out.
2021-10-19 09:17:24 <ncopa> let me see if i can create a testcase
2021-10-19 09:20:35 <ikke> ncopa: simpler than reproducing what the APKBUILD does?
2021-10-19 09:22:02 <ncopa> im mean, make a testcase based on what the APKBUILD does, but without needing to build the entire ghc
2021-10-19 09:22:34 <ncopa> we didnt have a testcase, so we assumed the subsequent commits in cpio would fix it, but we never verified that they actually did
2021-10-19 09:23:05 <ikke> I could reproduce it outside of the APKBUILD
2021-10-19 09:23:13 <ncopa> oh cool
2021-10-19 09:23:25 <ncopa> could you please add the reproducer to the check() function of cpio?
2021-10-19 09:23:41 <ikke> Hmm, wait. It did rely on ghc being built
2021-10-19 09:26:37 <ncopa> im just verifying that i didnt had a locally built cpio -r3
2021-10-19 09:26:52 <ncopa> without the additional patches
2021-10-19 09:27:33 <ncopa> yeah... thats what happened. i did have a locally built cpio with -dbg but without the additional patches
2021-10-19 09:27:44 <ncopa> ghc 9 built here now
2021-10-19 09:27:49 <ncopa> with llvm11
2021-10-19 09:28:05 <ikke> cpio -pamVd $PWD/../ghc-dev <files.txt 
2021-10-19 09:29:06 <ncopa> cpio was fixed. i just didnt had the update
2021-10-19 09:29:19 <ikke> ok, good
2021-10-19 09:39:02 <ncopa> argh...
2021-10-19 09:39:07 <ncopa> this haskell is killing me
2021-10-19 09:39:14 <ncopa> cabal does not build ofc
2021-10-19 09:39:18 <ncopa> and its outdated
2021-10-19 09:39:40 <ncopa> and the update is doind something completely different that it previously did
2021-10-19 09:39:48 <ncopa> currently it is ./bootstrap.sh
2021-10-19 09:40:25 <ncopa> newer way to build it apperas to be something like: runhaskell Setup configure -O --prefix=/usr --enable-executable-dynamic --disable-library-vanilla \
2021-10-19 09:40:25 <ncopa>   runhaskell Setup build $MAKEFLAGS
2021-10-19 09:40:25 <ncopa>     --docdir="/usr/share/doc/${pkgname}"
2021-10-19 09:40:42 <ncopa> which ofcourse is not mentioned in any readme or whatever
2021-10-19 09:41:36 <ncopa> that is at least what arch linux does https://github.com/archlinux/svntogit-community/blob/packages/cabal-install/trunk/PKGBUILD#L32
2021-10-19 09:58:38 <ncopa> haskell is a nightmare
2021-10-19 09:59:21 <ncopa> the cabal package should probably been named cabal-install, which is the upstream name and what other distros calls it (arch, fedora)
2021-10-19 09:59:56 <ncopa> in cabal-install-3.2.0.0 (which we currently use) there was a bootstrap.sh script, which would fetch and install the needed deps
2021-10-19 10:00:17 <ncopa> there are 17 deps
2021-10-19 10:00:42 <ncopa> with cabal-install 3.4.0.0, there are no longer any boostrap.sh script
2021-10-19 10:01:29 <ncopa> so we need to add 17 packages, and later make sure that the version of those are within the cabal's contraints
2021-10-19 10:02:29 <ncopa> i dunno, but what do you think about kicking out ghc and haskell?
2021-10-19 10:02:43 <ncopa> we need a haskell team to manage this, and we dont have that
2021-10-19 10:09:38 <ktprograms> Any idea why every test is taking 100 or more seconds? https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/515681
2021-10-19 10:12:28 <ncopa> because the tests are slow?
2021-10-19 10:12:49 <ncopa> i think the only package we actually need that uses haskell is shellcheck
2021-10-19 10:17:18 <ktprograms> ncopa: On all other architectures the total time of all tests is ~15s
2021-10-19 10:18:06 <Misthios> ktprograms if it times out u can just raise the job time lmiit
2021-10-19 10:18:34 <eris[m]> pandoc?
2021-10-19 10:21:20 <ncopa> ktprograms: maybe the code or test is inefficient for that arch? maybe the server is busy or are having some sort of issue?
2021-10-19 10:21:39 <ncopa> pandoc also uses ghc. can we kick out pandoc as well?
2021-10-19 10:23:26 <ikke> fyi, our CI is using shellcheck atm
2021-10-19 10:27:56 <ncopa> yeah...
2021-10-19 10:28:07 <ncopa> so we probably cannot kick it out, even if we want
2021-10-19 10:33:30 <ikke> ktprograms: wondering why as well, noticed that in general armhf CI is pretty slow
2021-10-19 10:35:54 <ktprograms> ikke: Hmm interesting. I'm re-running the job to confirm it's not a one-off slowness, but if it does take too long, how can I increase the timeout?
2021-10-19 10:36:17 <ikke> in the settings of your aports fork
2021-10-19 10:39:35 <ktprograms> It seems that generating the tex documentation is what is taking up most of the time. Probably will have to increase the timeout
2021-10-19 10:50:06 <mps> could someone with CI access look why !26522 fails on CIs, it works fine in lxcs
2021-10-19 10:50:44 <mps> do CIs need some uprades maybe?
2021-10-19 10:50:59 <Misthios> did u try rereunning it?
2021-10-19 10:51:02 <ikke> The images are rebuilt each weekend
2021-10-19 10:51:12 <Misthios> my mr had some random failures as well that werent there anymore with a rerun
2021-10-19 10:51:15 <mps> hmm, strange
2021-10-19 10:51:50 <ikke> mps: fyi, you should be able to run this in docker locally
2021-10-19 10:51:53 <mps> I would post report upstream but don't know what to say
2021-10-19 10:52:06 <mps> ah, CIs are dockers
2021-10-19 10:52:25 <ikke> alpinelinux/alpine-gitlab-ci
2021-10-19 10:53:38 <ikke> I can reproduce it
2021-10-19 10:57:01 <ikke> PKG_CONFIG_LIBDIR seems to be empty
2021-10-19 10:58:30 <mps> hmm
2021-10-19 10:59:25 <mps> pkgconf add in makedeps?
2021-10-19 10:59:32 <ikke> /usr/lib/pkgconfig
2021-10-19 10:59:35 <ikke> does not exist
2021-10-19 10:59:47 <mps> aha, thanks
2021-10-19 10:59:48 <ikke> you have --with-pkg-config-libdir=/usr/lib/pkgconfig
2021-10-19 11:00:27 <mps> thanks again ikke 
2021-10-19 11:32:31 <ktprograms> ikke: In the end the armhf build took 46 minutes so I didn't increase the timeout
2021-10-19 11:33:31 <ikke> alright, might have been another job running at the same time
2021-10-19 11:57:45 <ncopa> there is a precompiled shellcheck we can use for our CI image https://github.com/koalaman/shellcheck/releases
2021-10-19 12:00:56 <ikke> Fully static?
2021-10-19 12:01:02 <ikke> I was looking at that but was not sure
2021-10-19 12:01:16 <ncopa> yup. looks like it is fully static
2021-10-19 12:01:20 <ikke> Though, their docker image was just a single binary image, so it must be
2021-10-19 12:30:50 <ktprograms> Just wondering, are the alpine builders actual hardware or is it emulated?
2021-10-19 12:31:14 <ikke> actual hardware
2021-10-19 12:31:33 <ikke> armhf / armv7 run on aarch64 in 32-bits mode
2021-10-19 12:32:17 <ktprograms> I see.
2021-10-19 13:45:32 <minimal> can someone please merge !26507
2021-10-19 15:43:46 <omni> when is 3.15 release scheduled?
2021-10-19 15:46:03 <ikke> officially Nov 1st
2021-10-19 15:46:16 <ikke> https://alpinelinux.org/releases/
2021-10-19 15:47:35 <omni> ah, thanks
2021-10-19 15:51:48 <omni> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/81
2021-10-19 15:52:46 <omni> I'm fine with changing ovltmpfsflags to overlaytmpfsflags or overlaytmpfsopts of whatever, even though it's long as it is, but it would be nice to get this in
2021-10-19 15:59:22 <omni> my own usecase is to use minimal amount of ram for my virtual machines but I think it would also solve the issue alandiwix has
2021-10-19 17:28:53 <anjan> is there any way to easily check if the packages Im maintaining have had a new release?
2021-10-19 17:28:59 <anjan> sorry, Im a newbie maintainer 
2021-10-19 17:29:19 <ikke> https://repology.org/projects/
2021-10-19 17:29:35 <ikke> There you can search for packages for which you are the maintainer
2021-10-19 17:29:41 <ikke> and other project have updated it
2021-10-19 17:29:49 <ikke> You can subscribe to new releases on github / gitlab as well
2021-10-19 17:31:32 <anjan> thank you
2021-10-19 17:44:21 <smcavoy> is it possible to have someone review !25773 its been waiting for a review from the maintainer for a while..
2021-10-19 18:36:28 <ncopa> I think i have a working ghc 9.0.1 upgrade
2021-10-19 18:41:50 <ncopa> and i figured out the libffi thingy
2021-10-19 18:50:20 <ncopa> no i just need clean up the commits and figure out how to do cabal
2021-10-19 18:50:26 <ncopa> s/no/now/
2021-10-19 18:53:04 <ikke> \o/
2021-10-19 18:53:56 <ncopa> i have learned more about haskell and ghc than I ever wanted to know the last days
2021-10-19 18:55:14 <ikke> And you'll probably have forgotten it again soon
2021-10-19 19:00:20 <ikke> mps: I guess you pushe a personal branch to alpine/aports
2021-10-19 19:03:41 <mps> where?
2021-10-19 19:03:53 <ikke> alpine/aports:mps/aports-crystal-1.2.0 | Milan P. Stanić | community/crystal: upgrade to 1.2.0 | http://dup.pw/alpine/aports/f4f485d915de
2021-10-19 19:03:55 <mps> and what
2021-10-19 19:04:18 <ikke> Oh sorry, that was jirutka
2021-10-19 19:04:20 <mps> no, I didn't, looks like this is done by jirutka
2021-10-19 19:04:46 <ikke> "Jakub Jirutka @jirutka pushed new branch mps/aports-crystal-1.2.0"
2021-10-19 19:04:55 <ikke> He also deleted it again
2021-10-19 19:05:01 <mps> heh
2021-10-19 19:41:31 <ikke> regarding py3-websockets: https://github.com/aaugustin/websockets/issues/1051 https://bugs.python.org/issue45097
2021-10-19 19:41:48 <ikke> Apparently an issue with python-3.9.7
2021-10-19 19:48:23 <ikke> !13105
2021-10-19 19:48:27 <ikke> #13105
2021-10-19 19:50:16 <andypost[m]> I wonder is there a cleaner way to fix it? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26562#note_186419
2021-10-19 19:53:37 <ikke> Adding it here: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L127
2021-10-19 19:59:45 <nasuna> hello
2021-10-19 20:01:39 <nasuna> im trying to build the zig8.1 merge request apkbuild in a test environment, but i get the following
2021-10-19 20:01:44 <nasuna> https://paste.artixlinux.org/view/raw/bf66c01c
2021-10-19 20:03:09 <nasuna> is this conflict from the llvm12 merge lld changes revert not being available on testing yet?
2021-10-19 21:23:40 <kpcyrd> hm, I can't get https://gitlab.alpinelinux.org/kpcyrd/aports/-/jobs/515995 to pass, it seems the build takes slightly over 1h on armhf
2021-10-19 21:25:48 <PJ[m]> there is something wrong with armhf and it gets stuck
2021-10-19 21:30:04 <PJ[m]> or I think it might be just single runner issue
2021-10-19 21:30:51 <ikke> For some reason armhf is way slower than the rest
2021-10-19 21:30:57 <ikke> even though it runs on the same hw
2021-10-19 21:31:46 <PJ[m]> https://gitlab.alpinelinux.org/panekj/aports/-/jobs/512028
2021-10-19 21:34:25 <PJ[m]> ikke: yeah, but ~40 minutes stuck on symlinks?
2021-10-19 21:35:10 <ikke> PJ[m]: not sure what's happening there
2021-10-19 22:50:13 <PJ[m]> works fine on my own runner: https://gitlab.alpinelinux.org/panekj/aports/-/jobs/516599
2021-10-20 05:45:27 <ikke> regarding libseccomp on s390x: https://github.com/seccomp/libseccomp/issues/338
2021-10-20 06:07:52 <sam_> thanks for the link
2021-10-20 06:37:04 <ncopa> good morning
2021-10-20 06:38:18 <mps> good morning
2021-10-20 06:39:16 <ikke> good morning
2021-10-20 06:39:34 <ncopa> I think we have a problem. it is not possible to install llvm11 and llvm12 in parallel due to recent change in abuild
2021-10-20 06:39:44 <ncopa> abuild: version cmd: providers
2021-10-20 06:40:08 <ncopa> i think we need to revert it and rebuild the 3.15 world :-(
2021-10-20 06:40:22 <mps> ufff
2021-10-20 06:41:30 <psykose> what things break with 12 that they can't be bumped
2021-10-20 06:42:56 <ncopa> problem is that apk will say it is a conlict if two different packages provides same cmd:something but with different versions
2021-10-20 06:43:26 <ddevault> will alpine-conf see a release in time for the new alpine version?
2021-10-20 06:43:52 <ncopa> llvm11 has a number of binaries it provides and llvm12 also provides those, but in different directory
2021-10-20 06:44:17 <ncopa> ddevault: depends on how much time we have
2021-10-20 06:44:40 <ddevault> aight
2021-10-20 06:45:01 <ddevault> it would allow us to start building RISC-V edge ISOs
2021-10-20 06:45:06 <ncopa> the setup-disk with crypto support needs some more testing i think
2021-10-20 06:45:15 <ddevault> that hasn't landed yet, has it?
2021-10-20 06:45:32 <ddevault> I'm more interested in this https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/30
2021-10-20 06:45:34 <ncopa> no because i have not had the needed time to actually test it
2021-10-20 06:45:48 <mps> my hope is that the release will be just in time for next kernel -lts :)
2021-10-20 06:45:55 <ncopa> oh right
2021-10-20 06:46:14 <ncopa> we will likely tag a new release of alpine-conf before the 3.15 release
2021-10-20 06:46:18 <ddevault> cool
2021-10-20 06:46:40 <ncopa> this versioned cmd:* provides worries me though
2021-10-20 06:47:14 <mps> we need plan in advance for such things
2021-10-20 06:47:19 <ikke> ☹️
2021-10-20 06:47:40 <mps> not to just rush for upgrading pkgs
2021-10-20 06:49:28 <ncopa> it was not upgrading the package that broke. it was a change in abuilds behavior that had unexpected consequences
2021-10-20 06:49:31 <ncopa> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/02652f5dd62e51ec02f41d4610e8895f9ff36829
2021-10-20 06:50:36 <mps> oh, I see
2021-10-20 06:51:56 <ncopa> ah... i think it actually is a real, valid conflict
2021-10-20 06:52:30 <ncopa> phew
2021-10-20 06:53:54 <ikke> 😌
2021-10-20 06:53:57 <Ariadne> why are the 3.15 builders in fuck it mode?
2021-10-20 06:54:08 <Ariadne> this is rather spammy
2021-10-20 06:56:00 <ncopa> problem with llvm11 is that aed20f059f8facbddd1b4074ff01a4e7597c47a7 did not bump pkgrel so it is not built in non-default-llvm mode
2021-10-20 07:01:27 <Ariadne> 1:42 AM <ncopa> problem is that apk will say it is a conlict if two different packages provides same cmd:something but with different versions
2021-10-20 07:01:29 <Ariadne> huh?
2021-10-20 07:01:42 <Ariadne> it is the opposite, the solver will prefer the highest version in that case
2021-10-20 07:02:45 <ikke> Ariadne: I switched the to keep going due to the conflicts that block them 
2021-10-20 07:02:57 <ikke> Rather than have someone babysit the builders 
2021-10-20 07:03:19 <Ariadne> i dont think
2021-10-20 07:03:22 <Ariadne> it is building anything
2021-10-20 07:03:35 <PJ[m]> logs are 404
2021-10-20 07:03:54 <ikke> Yeah, I noticed that before. Not sure why this is happening 
2021-10-20 07:04:14 <ikke> We've used this way of building before, but it seems to behave differently 
2021-10-20 07:06:01 <Ariadne> i think it is because every single build is abandoned due to conflict
2021-10-20 07:08:11 <ikke> It should at least publish a build log then
2021-10-20 07:08:39 <ikke> If it skips it due to src/ being present, I would not expect it to announce a build failure 
2021-10-20 07:09:31 <ncopa> Ariadne: in this case we have a real conflict so they cannot be installed in parallel, and apk caught that. I wrongly assumed it was due to versioned cmd: provides
2021-10-20 07:10:05 <ncopa> conflict manifests itself here: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/516356
2021-10-20 07:11:04 <Ariadne> i was going to say, that MR was very informed by what i know of how the solver solves
2021-10-20 07:11:06 <Ariadne> :P
2021-10-20 07:12:01 <Ariadne> ah yes
2021-10-20 07:12:12 <Ariadne> that error is telling you that both of your packages install /usr/bin/llvm-stuff
2021-10-20 07:12:21 <Ariadne> and so obviously they cannot mix
2021-10-20 07:12:32 <Ariadne> it would have errored regardless of the dep being versioned
2021-10-20 07:15:03 <ncopa> yes. i wrongly assumed it was the change in abuild that triggered this
2021-10-20 07:33:51 <donoban> good morning, does anyone noticed segfault on sway?
2021-10-20 07:35:12 <Misthios> good morning, not yet
2021-10-20 07:35:45 <donoban> it seems related with libxkbcommon
2021-10-20 07:36:07 <donoban> I powered off yesterday and now discovered it
2021-10-20 07:37:26 <ikke> ncopa: any ideas why the builders behaved so strangely on armv7/hf?
2021-10-20 07:59:43 <donoban> [   48.356045] sway[4257]: segfault at 8 ip 00007fc624eb17b9 sp 00007ffd37a1ab38 error 6 in libxkbcommon.so.0.0.0[7fc624e9e000+16000]
2021-10-20 07:59:45 <donoban> [   48.356050] Code: 24 08 48 83 c4 18 e9 c0 21 00 00 83 c8 ff 48 83 c4 18 c3 31 c0 39 77 18 77 0f 39 77 1c 72 0a 89 f6 48 6b c6 30 48 03 47 20 c3 <ff> 47 08 48 89 f8 c3 48 85 ff 0f 84 65 01 00 00 41 56 41 55 41 54
2021-10-20 08:00:23 <donoban> I tried restoring sway from older snapshot and rebuilding both sway/libxkbcommon
2021-10-20 08:00:36 <donoban> any idea about what could be the problem?
2021-10-20 08:06:25 <Ariadne> ikke: they appear to be out of disk space
2021-10-20 08:06:53 <donoban> it's broken due suid removing
2021-10-20 08:08:14 <Misthios> u part of the seat group?
2021-10-20 08:09:26 <donoban> probably I'm not
2021-10-20 08:09:39 <mps> yes, /dev/mapper/vg0-lv_root  875G  831G     0 100% /
2021-10-20 08:10:45 <donoban> uhM, I don't have a seat group
2021-10-20 08:14:59 <donoban> I don't have seatd (is that related with seat group?)
2021-10-20 08:24:02 <Misthios> isnt seatd required for sway now?
2021-10-20 08:24:19 <donoban> no it doesn't
2021-10-20 08:24:27 <donoban> it requries libelogind :S
2021-10-20 08:24:38 <donoban> requires*
2021-10-20 08:46:04 <psykose> it needs seatd for (e)logind now yes, though only after 1.6.1
2021-10-20 08:46:20 <psykose> no tagged release since the change
2021-10-20 08:47:24 <psykose> or maybe they changed/reverted it and i forgot how it went
2021-10-20 08:48:36 <psykose> or maybe it's just logind proper
2021-10-20 08:48:56 <omni> 
ACTION decided to stay at 1.6.1-r1

2021-10-20 08:50:03 <omni> wait, wasn't it upgraded?
2021-10-20 08:50:21 <psykose> that is the latest tag
2021-10-20 08:51:04 <omni> yes, hmm.. what was I thinking of then?
2021-10-20 08:51:06 <omni> nevermind me
2021-10-20 08:56:59 <omni> oh, it was wlroots where I decided to stay at 0.13.0-r0
2021-10-20 09:02:08 <omni> so I think I'm at sway 1.6-r1?
2021-10-20 09:04:49 <omni> it works and I didn't have time/energy to look into how to setup seatd and whatnot
2021-10-20 09:05:38 <donoban> uhM, what about reverting the suid remove until it is not better integrated with seatd?
2021-10-20 09:13:44 <ncopa> im cleaning up my lxc containers to reduce disk space usage
2021-10-20 09:15:38 <donoban> I don't have seatd package but I have libseat (is it useful for something without seatd running?)
2021-10-20 09:16:56 <donoban> ah, libseat can work with elogind too
2021-10-20 10:27:24 <omni> donoban: could the segfault be related to what's been fixed in seatd 0.6.3? https://lists.sr.ht/~kennylevinsen/seatd-announce/%3C9OQ81R.8LC9WQHINNYD2%40kl.wtf%3E
2021-10-20 10:27:33 <omni> would wlroots need to be rebuilt?
2021-10-20 10:28:05 <omni> and sway?
2021-10-20 10:36:53 <donoban> I will test it in a while
2021-10-20 11:15:38 <ncopa> llvm11 build passed and no the ghc MR !20134 is green
2021-10-20 11:15:49 <ncopa> we still need to fix cabal
2021-10-20 11:36:38 <ikke> ncopa: no issues with libffi3.3-compat-dev conflicting with libffi-dev?
2021-10-20 11:38:49 <ncopa> no, i solved that by using embedded libffi
2021-10-20 11:38:56 <ikke> right
2021-10-20 11:39:15 <ncopa> i thikn we could use system libffi but its just unecessarily complicated when upgrades
2021-10-20 11:39:35 <ncopa> and libffi is not that big compared to the rest of ghc
2021-10-20 14:43:05 <donoban> omni: I think that I was already running that version when it crashed, but the suid bit fixed the problem, I don't know if there is some sense in testing the previous version without suid
2021-10-20 17:45:19 <ikke> interesting
2021-10-20 17:45:30 <ikke> busybox nproc --all returns 1, while nproc returns 32
2021-10-20 17:45:56 <ikke> Not sure what's going on, but htop seems to be affected by the same issue
2021-10-20 17:46:41 <dalias> it's probably sysconf() mess stuff
2021-10-20 17:46:48 <dalias> busybox reads /proc/cpuinfo aiui
2021-10-20 17:46:59 <dalias> musl has no good model for how to get this info
2021-10-20 17:47:48 <dalias> and while i'm not opposed to getting one, it's one of those things where pretty much everything that wants it wants it for the sake of doing something wrong (look at how many resources the machine has and consume them all as if i'm the only thing running) so i'm not too motivated to work on it :-p
2021-10-20 17:48:25 <ikke> cat /proc/cpuinfo | grep -c processor
2021-10-20 17:48:27 <ikke> 32
2021-10-20 17:53:10 <ikke> On a different host, it does not happen
2021-10-20 17:53:19 <ikke> (htop shows all cores)
2021-10-20 17:54:02 <dalias> strace it
2021-10-20 17:59:44 <ikke> open("/sys/devices/system/cpu", O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
2021-10-20 18:01:52 <ikke> apparently sysfs is not mounted
2021-10-20 18:10:20 <dalias> ah
2021-10-20 18:17:49 <ikke> that's much better
2021-10-20 18:29:03 <ikke> crystal hangs (deadlocks?) on x86_64
2021-10-20 18:35:56 <mps> or to looooong build time
2021-10-20 18:36:57 <ikke> mps: Just on a single g++ invocation?
2021-10-20 18:37:07 <ikke> 1https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/crystal/crystal-1.2.0-r0.log
2021-10-20 18:37:31 <mps> yes, this takes time, it is single threaded
2021-10-20 18:37:42 <ikke> hmm, ok. I'll wait
2021-10-20 18:38:27 <mps> on aarch64 it took about hour when I preparing it
2021-10-20 18:59:56 <Newbyte> would it be acceptable to backport an upstream commit to sudo to resolve !13108?
2021-10-20 19:00:08 <Newbyte> sorry, I meant #13108
2021-10-20 19:00:24 <ikke> Newbyte: probably yes
2021-10-20 19:00:53 <ikke> depends on ABI compatibility
2021-10-20 19:01:25 <ikke> Though, nothing seems to depend on sudo-dev
2021-10-20 19:01:50 <Newbyte> Doesn't look like this would change ABI to me: https://github.com/sudo-project/sudo/commit/00e53b32e5e8a2556eec5ca63ab7a86ed5a7e7c8
2021-10-20 19:42:47 <Saijin_Naib[m]> mps: Thanks for landing that commit to add pinctrl_broxton to linux-edge!
2021-10-20 19:44:16 <mps> Saijin_Naib[m]: you are welcome
2021-10-20 19:44:53 <mps> and sorry I didn't added your MR in commit
2021-10-20 19:45:11 <andypost[m]> Any idea how to make CI to use new libgit2 for rebuilds, ref !25925
2021-10-20 19:47:37 <ikke> andypost[m]: usually that means something is holding it back
2021-10-20 19:51:00 <andypost[m]> ah rust, thank you
2021-10-20 19:51:35 <andypost[m]> need to reorder commits
2021-10-20 19:51:44 <ikke> commit order does not matter
2021-10-20 19:52:01 <ikke> we use ap builddir to order the builds
2021-10-20 19:52:28 <ikke> If the order is wrong, it means something is missing in the dependencies, or there is a cycle
2021-10-20 20:00:02 <andypost[m]> yep, I excluded rust to build in in separate CI job
2021-10-20 20:00:30 <ikke> oh, like that
2021-10-20 20:04:34 <anjan> I have a package which produces a cli binary and gui binary. I want to split this into 2 packages. I read the creating an alpine package but Im still having a hard time understanding how it would work. Do you guys have an example recipe I can look at?
2021-10-20 20:04:46 <anjan> I want a gui subpackage that is
2021-10-20 20:05:11 <PJ[m]> https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Subpackages
2021-10-20 20:05:30 <anjan> thank you PJ[m] I will bookmark
2021-10-20 20:05:52 <ikke> anjan: a subpackages 'picks' the files from the main package that should belong to the subpackage
2021-10-20 20:06:41 <ikke> anjan: so typically you move files from $pkgdir to $subpkgdir
2021-10-20 20:07:01 <ikke> also make sure you adjust the dependencies on the subpackage (in the subpackage split function, you can set depends=..)
2021-10-20 20:07:09 <ikke> by default they inherit dependencies from the parent
2021-10-20 20:09:24 <anjan> this is a bit confusing....the way the maintainer of this code did it, the gui makedepends are checkdepends for the cli app
2021-10-20 20:09:52 <ikke> Just list them as makepends then
2021-10-20 20:10:01 <anjan> Im wondering if I should just put it all in makedepends, build gui and cli in build() and package the gui subpackage in package()
2021-10-20 20:10:04 <anjan> is that safe?
2021-10-20 20:10:13 <ikke> yes
2021-10-20 20:11:00 <ikke> There is not a lot of difference between checkdepends and makedepends, except that checkdepends are not installed if you disable checks
2021-10-20 20:11:20 <ikke> (which we do globally at the moment on ricsc64
2021-10-20 20:11:22 <ikke> )
2021-10-20 20:14:04 <anjan> ikke: how do I get a subpackage's dir
2021-10-20 20:14:11 <ikke> $subpkgdir
2021-10-20 20:14:12 <anjan> well a subpackage's pkgdir
2021-10-20 20:14:24 <anjan> but I can have multiple subpkgdirs right
2021-10-20 20:14:25 <ikke> It's a separate variable available in the split functions
2021-10-20 20:14:47 <ikke> Yes, it's set to the correct dir for each subpackage split function
2021-10-20 20:21:33 <andypost[m]> ikke: as I got rust has cycle on libgit2-dev so I stuck with this upgrade
2021-10-20 20:23:08 <ikke> Only runtime dependency right?
2021-10-20 20:25:09 <andypost[m]> but it's required to rebuild it
2021-10-20 20:25:44 <ikke> Yes, I see
2021-10-20 20:26:09 <andypost[m]> py3-pylibgit affects only salt
2021-10-20 20:28:56 <ikke> basically same with ghc and libffi
2021-10-20 20:31:04 <ikke> technically there should not be an issue, libgit2 1.1.0 should be able to be installed next to libgit 1.3.0
2021-10-20 20:42:07 <andypost[m]> so libgit2-11.compat?
2021-10-20 20:51:01 <ikke> andypost[m]: it's a approach, not sure if there is another better approach
2021-10-20 20:51:26 <ikke> building rust with libgit2 statically if possible
2021-10-20 21:00:54 <andypost[m]> ikke: there's unused libgit2-1.0 in community
2021-10-20 21:02:09 <ikke> oh, maybe an remnant for a similar situation
2021-10-20 21:04:31 <andypost[m]> at least it unused and can be renamed) doing it
2021-10-20 21:05:22 <ikke> nod
2021-10-21 04:24:24 <ericonr> I'm a bit confused; where does the certdata.txt file come from in the ca-certificates APKBUILD
2021-10-21 04:25:39 <ericonr> it only calls "make", which would result in 'all: update-ca-certificates c_rehash certdata.stamp' being called, none of which call 'update:'?
2021-10-21 04:28:34 <ikke> ericonr: someone would call that manually in the upstream project to update it
2021-10-21 04:28:49 <ikke> https://gitlab.alpinelinux.org/alpine/ca-certificates
2021-10-21 04:29:09 <ericonr> so it's ~2y out of date?
2021-10-21 04:30:09 <ikke> it appears so
2021-10-21 04:33:20 <ericonr> having issues with accepting LE-signed certs because openssl seems to be picking the outdated X3 root cert, but it's using void's openssl and alpine's ca-certificates, so I'm unsure what's going on
2021-10-21 04:35:04 <ikke> The DST root is still in there, but I believe it also has to do with the cert chain provided by the website
2021-10-21 04:36:13 <ikke> dl-cdn is using LE certs, but there are no issues validating it
2021-10-21 04:36:29 <ericonr> yeah, alpine curl is also working
2021-10-21 04:41:17 <ikke> apparently certdata.txt is updated every 2/3 months
2021-10-21 04:41:28 <ikke> Might be good to update it before the 3.15 release
2021-10-21 04:45:11 <ericonr> either way, thanks
2021-10-21 04:47:34 <ericonr> rm /etc/ssl/certs/2e5ac55d.* made things work, fwiw :P
2021-10-21 04:47:57 <ikke> ok, so it does not use a bundle?
2021-10-21 04:50:57 <ericonr> not sure... alpine's curl looked directly in /etc/ssl/certs/ca-certificates.crt, our libssl looked in /etc/ssl/certs/...
2021-10-21 05:53:59 <ikke> PureTryOut: usb-moded changed the archive (root dir name changed), could you take a look at it?
2021-10-21 05:54:40 <PureTryOut> Oh yeah that'll probably happen for more packages from the same devs, they moved from their own Gitlab instance to Github 😒
2021-10-21 05:54:43 <PureTryOut> I'll update it
2021-10-21 06:16:07 <PJ[m]> are only security updates allowed to be backported?
2021-10-21 06:23:26 <mps> PJ[m]: bugfixes also
2021-10-21 06:29:05 <PJ[m]> is that strictly "only bugfixes" releases/patches or can it include new features as well?
2021-10-21 06:29:16 <PJ[m]> also seems like s390x run out of space?
2021-10-21 06:29:36 <mps> PJ[m]: no, new features are not fixes
2021-10-21 06:30:35 <ikke> PJ[m]: yes
2021-10-21 06:30:56 <PureTryOut> the s390x builder went in "fuck-it" mode again
2021-10-21 06:31:11 <PureTryOut> ah lack of space, nvm
2021-10-21 06:32:54 <PJ[m]> 🙂
2021-10-21 06:35:40 <ikke> made some free space
2021-10-21 06:38:49 <PureTryOut> Space wasn't an issue in previous releases was it? Why is it now suddenly a problem?
2021-10-21 06:42:25 <ikke> It has always been an issue
2021-10-21 06:42:39 <ikke> But every new release gives us less space to work with
2021-10-21 07:22:17 <ncopa> good morning
2021-10-21 07:22:53 <ncopa> ERROR: libgit2-1.1-1.1.1-r0: trying to overwrite usr/lib/libgit2.so.1.1 owned by libgit2-1.1.1-r2.
2021-10-21 07:22:53 <ncopa> ERROR: libgit2-1.1-1.1.1-r0: trying to overwrite usr/lib/libgit2.so.1.1.1 owned by libgit2-1.1.1-r2.
2021-10-21 07:23:13 <ncopa> im not sure libgit2-1.1-1.1.1-r0 is a good idea
2021-10-21 07:24:01 <pj> good mornin'
2021-10-21 07:26:15 <ikke> ncopa: How do we deal with rust, which depends on itself and libgit2
2021-10-21 07:27:23 <PureTryOut> ikke: I assume old unsupported releases get deleted right? Although I suppose every release becomes a bit bigger
2021-10-21 07:29:10 <ikke> PureTryOut: at least so far, we have not removed older releases
2021-10-21 07:29:31 <PureTryOut> so stuff like Alpine 3.0 are still on there? Damn lol. Maybe time to start removing those?
2021-10-21 07:30:39 <ncopa> we have moved the old ones to an archive
2021-10-21 07:30:51 <ncopa> this libgit thingy is a bit worrying
2021-10-21 07:30:51 <PureTryOut> Ah ok
2021-10-21 07:31:09 <ncopa> i think the archive is offline btw
2021-10-21 07:31:58 <ncopa> libgit2-1.0 got introduced in 6425be941961881e542ff2604ea869f94f51c0a8, but the commit message does not say anything about why
2021-10-21 07:32:46 <ncopa> then libgit2 got updated to 1.1
2021-10-21 07:33:18 <ncopa> to 1.1.1
2021-10-21 07:33:45 <ncopa> that was in 794b35a612cf29fb7c32d03c8a83c0bce2632492
2021-10-21 07:34:08 <ncopa> later libgit2 got updated to 1.2.0 ed5194bc045a08d9935c68d9a22afa5526c83501
2021-10-21 07:34:36 <ncopa> later same day it got downgraded again 1ed97e7075c45f4ae9a43dfc2b52418bd0c31492 no explanation why in commit message
2021-10-21 07:34:48 <ikke> We cannot build rust when libgit2 is upgrwded 
2021-10-21 07:35:43 <ncopa> then libgit2 got upgrade to 1.3.0 e93b54fc15d0a089a810acd30942959721ae0fec
2021-10-21 07:36:54 <ncopa> and libgit2-1.0 got renamed to libgit2-1.1 in fb128e34203844072332544aea14e099bdf1d388
2021-10-21 07:38:33 <ncopa> so problem is that rust needs bootstrapping (eg builds itself) and it depends on libgit2, which makes it complicated to upgrade libgit2
2021-10-21 07:39:05 <ncopa> same problem with libffi and ghc
2021-10-21 07:39:17 <ncopa> and gmp and mpfr and gcc
2021-10-21 07:43:09 <Ariadne> yes, libgit2 needs to be versioned
2021-10-21 07:47:42 <ncopa> either that or ling cargo/rust against statig libgit2
2021-10-21 07:47:50 <ncopa> s/ling/link/
2021-10-21 07:49:38 <ncopa> according to https://github.com/Cogitri/aports/commit/df7545b5fb933d9ebeb7e35afbaace2bc5dfd3bc we dont use system libgit2?
2021-10-21 07:50:03 <ikke> It's still pulls in so:libgit2-1.1
2021-10-21 07:50:16 <ikke> It*
2021-10-21 07:50:42 <ncopa> so we can probably remove the misleading comment in rust/APKBUILD?
2021-10-21 07:54:53 <ncopa> ok apk fix seems to solve it
2021-10-21 08:03:00 <Newbyte> Why is 6.0.0004-rc5 not a valid version?
2021-10-21 08:03:04 <Newbyte> according to abuild
2021-10-21 08:04:17 <Newbyte> Oh it was the dash, I see
2021-10-21 08:38:04 <Newbyte> Why might it be that abuild doesn't try to apply a patch in the sources? I even tried making it malformed and it doesn't care, it doesn't attempt to apply it. 
2021-10-21 08:39:45 <ikke> Does the name end with .patch?
2021-10-21 08:39:50 <Newbyte> Here's my "code": https://gitlab.alpinelinux.org/Newbyte/aports/-/tree/libsamsung-ipc/testing/libsamsung-ipc
2021-10-21 08:40:17 <Newbyte> ikke: yes
2021-10-21 08:40:18 <ikke> Ah
2021-10-21 08:40:38 <ikke> You need to add default_prepare to your prepare function
2021-10-21 08:41:08 <Newbyte> Oh, all right. Thanks!
2021-10-21 08:56:16 <mps> hmmm, I made mistake and merged zig without check on lxc first :|
2021-10-21 08:56:53 <mps> I should put line 'do not touch' to some packages
2021-10-21 08:58:24 <mps> anyway, new lxc is on gitlab !26618
2021-10-21 08:59:36 <PureTryOut> Newbyte: btw since `autogen.sh` is part of the upstream build system, place it in `build()` rather than `prepare()`
2021-10-21 08:59:48 <Newbyte> sure, will do
2021-10-21 08:59:51 <PureTryOut> And of course remove the usual empty variables
2021-10-21 09:00:38 <mps> ncopa: clandmeter: ikke: do we still need to keep lxcfs
2021-10-21 09:00:58 <ikke> I don't think we use it on the builders or other infra
2021-10-21 09:01:32 <mps> maybe move to unmaintained, I don't know that anyone uses it
2021-10-21 09:02:12 <ncopa> andypost[m]: are yo working on rebuilding rust with libgit2-1.3.0?
2021-10-21 09:02:27 <ncopa> i think we should try delete the libgit2-1.1 package
2021-10-21 09:03:06 <ikke> ncopa: he was working on it last night
2021-10-21 09:03:11 <ncopa> ok
2021-10-21 09:05:17 <ikke> After rust has been rebuilt, I think it can be removed 
2021-10-21 09:05:31 <ikke> It's just a transactional package 
2021-10-21 09:05:32 <ncopa> not yet. there are a number of other packages
2021-10-21 09:05:39 <ikke> Oh
2021-10-21 09:05:49 <ncopa> apk list --depends so:libgit2.so.1.1
2021-10-21 09:06:06 <ikke> Check if there are MRs open 
2021-10-21 09:06:20 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25463
2021-10-21 09:14:02 <ikke>   invalid version 0 on git_proxy_options; class=Invalid (3)
2021-10-21 09:23:36 <Newbyte> PureTryOut (matrix.org): lol: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26622#note_186941
2021-10-21 09:24:02 <Newbyte> I'm not sure who to believe 
2021-10-21 09:24:55 <PureTryOut> I disagreed with him on that on one of my own MR's as well but he never answered 😢
2021-10-21 09:29:25 <ikke> We typically use prepare for setting up the build system. things like autoreconf -fi we also put in prepare()
2021-10-21 09:50:47 <PureTryOut> Yes I know
2021-10-21 10:00:49 <maxice8> add a configure() phase to abuild just like void linux :^)
2021-10-21 10:06:47 <ncopa> ugh.....
2021-10-21 10:06:56 <ncopa> im bumping into more issues with ghc
2021-10-21 10:07:02 <ncopa> not cool
2021-10-21 10:08:20 <ncopa> packages built with ghc will link to the dynamic libs shipped with ghc
2021-10-21 10:08:30 <ncopa> which pulls in ghc as runtime for those packages
2021-10-21 10:09:01 <ncopa> ghc pulls in llvm and gmp-dev as runtime
2021-10-21 10:11:05 <ncopa> which means that a tool written in haskell, like uusi, which is 400k, pulls in 42MB (llvm12) + 762MB (ghc) as runtime deps
2021-10-21 10:14:59 <ncopa> i think im back to the idea of kicking out ghc from alpine
2021-10-21 10:19:57 <ncopa> it also means that we cannot build things like pandoc and apostrophe
2021-10-21 10:20:55 <ikke> ..
2021-10-21 10:21:27 <ncopa> ikke: I suppose we can wget a precompiled static binary of shellcheck for our CI?
2021-10-21 10:21:36 <ikke> ncopa: yes, we certainly can
2021-10-21 10:22:02 <ikke> We can just copy from koalaman/shellcheck
2021-10-21 10:22:35 <ncopa> i think that fixing ghc, cabal and shellcheck will cost at least a week of work
2021-10-21 10:22:58 <ncopa> and im pretty sure nobody in the community is willing to do this job at this point
2021-10-21 10:23:17 <ikke> We can send out an e-mail on alpine dev to ask
2021-10-21 10:23:26 <ncopa> Cogitri: are you ok to delete testing/apostrophe?
2021-10-21 10:23:33 <ncopa> yeah, i guess that would make sense
2021-10-21 10:23:51 <ikke> later bootstrapping it again would be a lot more difficult I imagine
2021-10-21 10:24:07 <ncopa> maybe not. there are binaries for alpine from upstream ghc
2021-10-21 10:24:12 <ncopa> precompiled binaries
2021-10-21 10:24:19 <ikke> oh, ok
2021-10-21 10:33:57 <ikke> We can send an email, and if no one responds, we can decide to drop it. 
2021-10-21 11:37:33 <ncopa> email sent
2021-10-21 12:06:24 <Newbyte> what would you use in place of shellcheck for the CI?
2021-10-21 12:06:26 <minimal> can someone please merge !26507
2021-10-21 12:11:02 <ikke> Newbyte: We would still use shellcheck, but a precompiled static version from upstream
2021-10-21 12:13:59 <minimal> ikke: I noticed that upstream build the static version of shellcheck by running cabal with "--enable-executable-static", couldn't the APKBUILD just use this?
2021-10-21 12:14:39 <ikke> minimal: see https://lists.alpinelinux.org/~alpine/devel/%3C20211021133615.32f08070%40ncopa-desktop.lan%3E for details
2021-10-21 12:14:53 <ikke> shellcheck itself is not the issue
2021-10-21 12:16:22 <minimal> ok
2021-10-21 13:00:39 <markand> someone for !25793 ?
2021-10-21 13:14:35 <ktprograms> ncopa: Regarding your email and how to update cabal, I suppose something like in https://github.com/iblazhko/haskell-arm64#Cabal could be used. (I'm not suggesting I would want to maintain Haskell on Alpine but this could be useful if someone does step up to the task)
2021-10-21 13:28:51 <Cogitri[m]> ncopa: Yup, just answered on the ML
2021-10-21 13:29:15 <Cogitri[m]> Kind of annoying it still sends the email that HTML emails are refused but then still accepts the email and converts it to plaintext
2021-10-21 13:41:51 <minimal> Keen to get !26507 merged so it gets into 3.15 release
2021-10-21 13:50:12 <mps> minimal: did you tested it on real hardware
2021-10-21 13:50:45 <minimal> yes, on RPIs specifically
2021-10-21 13:50:53 <mps> ok
2021-10-21 13:52:11 <minimal> mps: if you are able to test it on non-RPI Arm SBCs (especially single core) that would be useful
2021-10-21 13:53:43 <mps> already merged (and wonder why such thing is need, but I hope you know better than me)
2021-10-21 13:54:12 <mps> it builds and that's enough
2021-10-21 13:56:08 <minimal> mps: the jitter stuff is a "modern" replacement for haveged but turned out it needed to be tuned a bit for Arm machines as its initialisation "sanity" checks were using excessive CPU
2021-10-21 13:57:34 <mps> minimal: thanks for explanation (will try to remember)
2021-10-21 14:52:56 <andypost[m]> Cogitry please comment about rust's dependency on libgit2 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25463/diffs#note_186980
2021-10-21 15:22:47 <Hello71> andypost[m]: Cogitri?
2021-10-21 15:23:39 <andypost[m]> ah, sure, waking up(
2021-10-21 15:23:57 <Hello71> andypost[m]: why does it need to disable system libgit2 for all packages, not just rust/cargo?
2021-10-21 15:24:34 <andypost[m]> I've no idea just got that it used to switch to bundled but somehow that stopped to work
2021-10-21 15:24:57 <andypost[m]> it should help to get rid of libgit2-1.1 as ncopa said
2021-10-21 15:25:25 <ddevault> anyone know of a good sample package to use as a starting point for a DKMS module
2021-10-21 15:31:24 <ikke> ddevault: I assume you mean AKMS
2021-10-21 15:31:47 <mps> testing/librem-ec/
2021-10-21 15:31:48 <ddevault> do I?
2021-10-21 15:32:06 <ikke> ddevault: Alpine does not have DKMS
2021-10-21 15:32:09 <ddevault> hm, I had never seen AKMS before
2021-10-21 15:32:16 <ddevault> so, yes. I want to package an out of tree kernel module
2021-10-21 15:32:20 <ikke> jirutka recently created AKMS
2021-10-21 15:32:27 <ikke> which serves the same purpose as DKMS
2021-10-21 15:32:37 <ddevault> thanks mps, I'll start from there
2021-10-21 15:32:42 <ikke> ddevault: https://github.com/jirutka/akms
2021-10-21 15:32:50 <ddevault> cheers ikke
2021-10-21 15:33:45 <mps> some of current out-of-tree modules should be converted to akms
2021-10-21 15:36:05 <ikke> mps: I've already created one for rtl8821ce
2021-10-21 15:36:09 <ikke> But need someone to test it
2021-10-21 15:37:21 <mps> aha, good. no one raises hands
2021-10-21 15:38:19 <mps> I would merge it and wait reaction from users
2021-10-21 15:38:27 <ikke> It's already in testing
2021-10-21 15:39:32 <mps> ah, I see
2021-10-21 15:41:09 <mps> there are more of them
2021-10-21 15:41:15 <ikke> The user requesting it was here as a guest user
2021-10-21 15:41:24 <mps> rtw89-src
2021-10-21 15:41:37 <ikke> rtl8821ce-src
2021-10-21 15:41:50 <mps> yes, I saw it and these second one
2021-10-21 15:42:28 <mps> and rtl88x2bu-src
2021-10-21 15:43:33 <mps> and acpi_call-src in community
2021-10-21 15:44:31 <andypost[m]> Hello71: except cargo tools/rls depends on git2(
2021-10-21 15:58:23 <Cogitri[m]> andypost: Hm yes, had difficulty with that previously too. I guess we might as well use the vendored version then
2021-10-21 16:25:49 <ddevault> how is it possible that bluetooth is *still* utter garbage
2021-10-21 16:25:57 <ddevault> akms bit works fine, though
2021-10-21 16:31:11 <psykose> it's a lot less garbage outside of linux funnily enough
2021-10-21 16:44:32 <Newbyte> How do I check which packages depend on a package?
2021-10-21 16:44:43 <Newbyte> Like, I have package A. I want to get a list of packages that depend on package a
2021-10-21 16:44:56 <ddevault> apk info -r <package a>
2021-10-21 16:45:07 <Newbyte> thanks
2021-10-21 17:00:45 <ikke> I must say, bt has been working on linux fine for me
2021-10-21 17:08:08 <ddevault> you may be the only one https://xkcd.com/2055/
2021-10-21 17:08:36 <ikke> Yes, I know
2021-10-21 17:12:47 <psykose> even with all the time i spent on it, getting the hfp headset profile to work with my headphones still doesn't really work fully
2021-10-21 17:12:55 <psykose> but at least audio playback is now identical to every other device
2021-10-21 17:17:24 <andypost[m]> Cogitri: otoh maybe there's a way to bump it with some patch, I'm not much familiar with cargo internals
2021-10-21 17:18:38 <andypost[m]>  it just need newer version, ikke already added some hack to CI for mater branch notice
2021-10-21 17:19:00 <ikke> I just set the default branch
2021-10-21 17:19:04 <ikke> not really a hack
2021-10-21 17:21:11 <andypost[m]> yes, extra configuration, but cargo has incompatibility and needs patching like 31d907ed45dcb24b71d3e6921c35773a041506c1
2021-10-21 17:53:09 <Newbyte> is it a known issue that zbar-dev can't be installed because of some weird openssl conflict? 
2021-10-21 17:53:18 <Newbyte> like, is this something affecting other packages?
2021-10-21 17:53:40 <Newbyte> I'd like to know whether to open an issue about it
2021-10-21 17:55:01 <ikke> What is the error?
2021-10-21 17:57:14 <Newbyte> ikke: https://paste.centos.org/view/raw/bb9d7c35
2021-10-21 17:58:27 <ikke> Newbyte: seems like you need to do an apk update?
2021-10-21 17:58:40 <ikke> https://pkgs.alpinelinux.org/packages?name=curl-dev&branch=edge
2021-10-21 17:58:54 <ikke> curl-dev-7.79.1-r0
2021-10-21 17:59:32 <Newbyte> Still happens. Maybe my mirror is behind?
2021-10-21 17:59:39 <ikke> What mirror do you use/
2021-10-21 18:00:18 <Newbyte> mirror.yandex.ru
2021-10-21 18:00:36 <Newbyte> or rather, mirror.yandex.ru/mirrors/alpine
2021-10-21 18:01:16 <ikke> edge is a bit behind, but not more than a day, so I would it not expect it to be that behind on curl
2021-10-21 18:01:21 <ikke> https://mirrors.alpinelinux.org/#mirror5
2021-10-21 18:12:32 <Newbyte> I switched to http://dl-cdn.alpinelinux.org/alpine/ and the issue persists 
2021-10-21 18:12:39 <Newbyte> Are you able to install zbar-dev on your system?
2021-10-21 18:13:00 <psykose> installs fine for me
2021-10-21 18:13:34 <ikke> Newbyte: probably held back then
2021-10-21 18:13:43 <ikke> apk del curl-dev
2021-10-21 18:14:07 <Newbyte> I'm still unable to install zbar-dev after deleting curl-dev
2021-10-21 18:14:21 <ikke> Did it mention something?
2021-10-21 18:14:47 <Newbyte> Okay, zbar-dev installs if I delete openssl-dev
2021-10-21 18:14:51 <ikke> right
2021-10-21 18:15:07 <Newbyte> Thanks for the guidance 
2021-10-21 18:15:46 <ikke> in general, it's better to not manually install -dev packages (and keep them lingering)
2021-10-21 18:16:24 <Newbyte> Yeah, I didn't really know what I was doing when I first installed this system. But thank you regardless
2021-10-21 18:16:42 <ikke> just make sure all -dev packages in /etc/apk/world are removed
2021-10-21 18:17:02 <ikke> Same with libraries 
2021-10-21 18:41:02 <bl4ckb0ne> could I have a review for !26375 and !24589 please
2021-10-21 19:22:49 <andypost[m]> rust 1.56 is out) does it fit into 3.15? https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html
2021-10-21 19:24:24 <ikke> The amount of rust packages is limited, so might be possible
2021-10-21 19:25:49 <Hello71> i wonder if the clone3 issue will cause issues on musl
2021-10-21 19:43:36 <ncopa> Hello71does not seem that musl uses clone3 anywhere yet, so no
2021-10-21 19:48:21 <Hello71> i mean https://github.com/rust-lang/rust/issues/89522
2021-10-21 19:52:47 <psykose> running cargo myself on 1.56 seems fine with no zombies, maybe it's something in the sandbox that causes an issue
2021-10-21 19:59:58 <Hello71> well at least for glibc it is an interaction with sandbox. that's why i'm asking for musl
2021-10-21 20:00:26 <Hello71> since i know that glibc has some "special" behaviors regarding forking and locks
2021-10-21 20:09:02 <psykose> i am on musl right now
2021-10-21 20:10:44 <psykose> maybe it's just glibc then
2021-10-21 20:10:47 <Hello71> ok, that's helpful. it can still break with dynamic linking :p
2021-10-21 21:53:54 <Ariadne> yes, lets do rust 1.56
2021-10-21 22:01:00 <andypost[m]> it needs work !26631 as second link tells it needs llvm13 if I got it right
2021-10-21 22:01:50 <andypost[m]> and embedded openssl3 needs review
2021-10-21 22:12:36 <Ariadne> embedded openssl3?
2021-10-21 22:12:42 <Ariadne> whaaaaaaaaaaaa
2021-10-21 22:12:59 <Ariadne> why?
2021-10-21 22:13:28 <Hello71> ah, there is a fix for 1.56: https://github.com/rust-lang/rust/pull/89924
2021-10-21 22:13:44 <Hello71> so it's still broken but probably won't show itself
2021-10-21 22:19:25 <andypost[m]> Ariadne: sorry, mixed with https://nodejs.org/en/blog/release/v17.0.0/
2021-10-21 22:20:11 <Ariadne> :)
2021-10-21 22:20:57 <psykose> ah, i see they bundle it because it's a fork
2021-10-21 22:22:06 <psykose> it appears to be roughly 54 commits on top of 3.0 for quic support and nothing else
2021-10-21 22:22:46 <psykose> can probably be split out relatively easily if the quic fork is also packaged, but is there a reason to split out something when it's the only user of a dep
2021-10-21 22:23:33 <andypost[m]> I think it will be herd to maintain as separate package
2021-10-21 22:24:01 <Ariadne> this wont work
2021-10-21 22:24:02 <Ariadne> because
2021-10-21 22:24:10 <Ariadne> if they bundle their own ABI-incompatible openssl
2021-10-21 22:24:28 <Ariadne> and then users use libraries from the system which also depend on openssl
2021-10-21 22:24:34 <Ariadne> they will get undefined behavior
2021-10-21 22:24:55 <psykose> yes, it would have to be with everything renamed and a ton of patches thrown on
2021-10-21 22:24:58 <psykose> indeed not worth the effort
2021-10-21 22:25:11 <psykose> so perhaps not 'relatively' easily, hah, wrong choice of words there
2021-10-21 22:28:10 <andypost[m]> s390x 3.15 builder finished)
2021-10-21 22:28:40 <Ariadne> no, it didn't
2021-10-21 22:28:47 <Ariadne> there are still failures
2021-10-21 22:31:55 <andypost[m]> qt6-qtdeclarative-dev missing at least
2021-10-21 22:34:06 <Cogitri[m]> andypost: No, patching cargo and all rust crates which pull in libgit2-sys is no fun at all
2021-10-21 22:34:57 <Cogitri[m]> And for bootstrapping the new rust release against the new libgit2 we would still need a temporary rust-oldlibgit package or a statically linked version :/
2021-10-21 22:35:10 <Cogitri[m]> So frankly I’d say just use the vendored version for now
2021-10-21 22:35:38 <andypost[m]> As I see jirutka just commited it)
2021-10-21 22:36:02 <andypost[m]> let's see what 1.56 will show, for some reason there's no clippy tar
2021-10-21 22:38:41 <Cogitri[m]> Hm, maybe they disabled that by default too, like rust-analyzer a few releases ago
2021-10-21 23:02:09 <Ariadne> go ahead and use libgit2 vendored
2021-10-21 23:02:18 <Ariadne> as well as libssh2 vendored imo
2021-10-21 23:17:12 <Cogitri[m]> libssh2 doesn’t have as many API breaks though, or does it?
2021-10-21 23:52:13 <andypost[m]> Cogitri: looks only additions https://abi-laboratory.pro/index.php?view=timeline&l=libssh2
2021-10-22 00:12:13 <craftyguy> is there some service or something that can notify me when there's a CVE against any packages I maintain?
2021-10-22 01:09:16 <orbea> craftyguy: maybe repology.org
2021-10-22 01:11:35 <craftyguy> ah, cool. that doesn't seem to notify folks though, I only see some RSS thing I can use and hopefully notice
2021-10-22 01:12:04 <orbea> i have seen CVE warnings next to package versions there, but I am not sure its comprehensive
2021-10-22 01:12:25 <orbea> its more meant to check for general updates
2021-10-22 01:12:46 <orbea> i imagine a lot of security fixes may not be assigned CVEs too, depends on the project
2021-10-22 01:44:55 <lzsaver> hello! is TBK here?
2021-10-22 02:25:59 <Ariadne> not to my knowledge
2021-10-22 02:33:27 <ktprograms> When I try to run the tests for picom, it can't find the xcffib.xproto module. Which package should be installed for that to work?
2021-10-22 02:45:18 <ktprograms> Nevermind, the tests won't work without a display anyway.
2021-10-22 06:46:18 <Cogitri[m]> craftyguy: You can use the RSS in combination with services like Blogtrottr to get emails when the RSS updates
2021-10-22 06:47:41 <craftyguy> Cogitri[m]: ah cool, I saw a self-hosted thing like that but I'd rather someone else take a turn at hosting (I already self-host too many things..). if you recommend Blogtrottr I'll give that a try
2021-10-22 07:45:20 <Cogitri[m]> Yup, it works pretty nicely for me
2021-10-22 07:46:40 <mps> ncopa: https://invisible-mirror.net/ncurses/announce.html ncurses 6.3 released, should we upgrade it for 3.15
2021-10-22 07:46:49 <mps> good morning
2021-10-22 07:47:21 <mps> in announce I don't see any ABI breaks
2021-10-22 07:48:03 <ikke> If there is no soname bump, I think we can upgrade it
2021-10-22 07:48:48 <mps> tarball is not yet on mirror, when it appears I will test
2021-10-22 07:49:17 <Ariadne> heh
2021-10-22 07:49:53 <mps> it is called invisible-mirror with reason, I think :)
2021-10-22 07:52:30 <pj> https://invisible-mirror.net/archives/ncurses/ncurses-6.3.tar.gz 
2021-10-22 07:53:58 <mps> pj: we need 6.3-20211021.tar.gz
2021-10-22 07:55:34 <pj>   ncurses-6.3.tar.gz 2021-10-21 17:36 3.4M
2021-10-22 07:55:38 <pj> is that not it?
2021-10-22 07:55:56 <mps> no
2021-10-22 07:56:09 <Ariadne> i mean, that is it
2021-10-22 07:56:41 <pj> eventually you might want https://invisible-mirror.net/archives/ncurses/current/ncurses-6.3-20211021.tgz
2021-10-22 07:57:32 <mps> no, Thomas sent another mail that he will make proper tarball soon
2021-10-22 07:57:50 <Ariadne> mmmkay
2021-10-22 07:58:07 <mps> Thomas Dickey, upstream author
2021-10-22 07:59:17 <mps> we can wait one day
2021-10-22 08:25:25 <ncopa> seems like it does not break abi so i think we can include it
2021-10-22 08:25:32 <ncopa> good morning btw :)
2021-10-22 13:29:00 <ktprograms> Any idea why the build log for php7-exif is returning 404? (I'm trying to see if it built ok since ldd gives a bunch of symbol not found errors on exif.so) https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/php7-exif/php7-exif-7.4.25-r0.log
2021-10-22 13:35:03 <ikke> Disappeared in the bit bucket 
2021-10-22 13:35:55 <clandmeter> i guess somebody had to create some space
2021-10-22 13:35:56 <ikke> Archived in /dev/null
2021-10-22 13:44:04 <ktprograms> Bit weird since it was updated a day ago, but thanks anyway.
2021-10-22 14:22:39 <andypost[m]> There should not be log because ecif is part of php 
2021-10-22 18:24:56 <kernel-shutdowns> hi guys, i wrote few days ago re:issue 
2021-10-22 18:26:02 <kernel-shutdowns> with unexpected kernel-shutdowns with kernel 5.10.x in a  number of servers with different motherboards from
2021-10-22 18:26:09 <kernel-shutdowns> different manufacturers
2021-10-22 18:26:38 <kernel-shutdowns> we now have a machine with reproducible behavior
2021-10-22 18:27:55 <kernel-shutdowns> linux-lts 5.10.61 from branch 3.14 and 5.10.75 from branch edge are shutting down the server without any messages in /var/log/messages
2021-10-22 18:28:46 <kernel-shutdowns> shutdown is point blank, without errrors - the machine just goes down immediately with black screen with no messages whatsoever - as if the server oower cable has been pulled
2021-10-22 18:29:19 <mps> kernel-shutdowns: could you add serial console and debug
2021-10-22 18:29:32 <kernel-shutdowns> when we compile 5.10.75 from kernel.org ("nomod" configuration) -- the machine is stable and is not rebooting
2021-10-22 18:30:23 <kernel-shutdowns> with alpine linux-lts 5.10.75 - the machine turns itself off within a minute after boot
2021-10-22 18:30:43 <kernel-shutdowns> all daemons are disabled - no sshd, no cron, no ntpd no nothing
2021-10-22 18:31:06 <kernel-shutdowns> yes, i can provide all the logs
2021-10-22 18:31:06 <ikke> kernel-shutdowns: can you compare lsmod between the 2 kernels?
2021-10-22 18:31:46 <mps> also, can you try with linux-edge
2021-10-22 18:32:18 <kernel-shutdowns> machine is mac mini 7,1 but we have had similiar issues, although much less often on embedded servers manufactured by gigabyte and mitac
2021-10-22 18:32:25 <ikke> maxice8: py3-twisted is failing
2021-10-22 18:32:31 <maxice8> yeah
2021-10-22 18:32:32 <maxice8> it is driving me mad
2021-10-22 18:32:48 <maxice8> it is correct in src/twisted/python/test/test_version.py
2021-10-22 18:32:50 <mps> kernel-shutdowns: what arch is it
2021-10-22 18:32:58 <maxice8> but in build/lib/twisted/python/test/test_version.py it is wrong
2021-10-22 18:33:20 <Nulo> Would Tenacity (Audacity fork, no release yet) be accepted into aports? tenacityaudio.org/
2021-10-22 18:33:49 <kernel-shutdowns> mps: intel x64
2021-10-22 18:34:32 <mps> to repeat, could you try linux-edge
2021-10-22 18:35:53 <psykose> Nulo: don't see why it wouldn't
2021-10-22 18:35:54 <kernel-shutdowns> mps - ok - trying linux-edge
2021-10-22 18:36:02 <psykose> i would wait for a release though
2021-10-22 18:36:10 <Nulo> psykose, okay
2021-10-22 18:39:12 <maxice8> @andypost: thanks for fixing it, didn't even notice
2021-10-22 18:40:02 <andypost[m]> maxice8: np, I used to add the patch)
2021-10-22 18:40:33 <ikke> I suppose it was broken, tests patched, and now fixed?
2021-10-22 18:43:08 <maxice8> we didn't upgrade incremental together with it so upstream fixed the tests https://twistedmatrix.com/trac/ticket/10112 but instead of upgrading incremental we just reverted the fix to match the old version of incremental we had
2021-10-22 18:43:30 <maxice8> now that I upgraded incremental because the new py3-twisted hard depends on it, the tests started to fail because of the patch
2021-10-22 18:47:37 <andypost[m]> Exacaly
2021-10-22 18:53:41 <ikke> Anyone has an idea what can provide dbm_open in aports? apr-utils was switched to use ndmb, but that is apparently only a header, it seems to look for dbm_open in a few libraries, but none that we have
2021-10-22 18:55:16 <ikke> well, we still have libdb, we we try to avoid it
2021-10-22 18:56:21 <ikke> gdbm only provides gdbm_open
2021-10-22 19:02:07 <psykose> i think the apr-util build should be changed to --with-dbm=gdbm then
2021-10-22 19:02:29 <ikke> Hmm, good point
2021-10-22 19:02:39 <ikke> Didn't even think it would support that
2021-10-22 19:02:40 <psykose> it's a valid configure option at least
2021-10-22 19:02:47 <psykose> as well as 10 other dbms
2021-10-22 19:02:47 <psykose> hah
2021-10-22 19:06:47 <ikke> hmm, it seems not have been built against libgdbm.so
2021-10-22 19:07:33 <psykose> there is also a --with-gdbm=DIR option that i assume wants the header dir, if it somehow doesn't auto find it
2021-10-22 19:07:47 <psykose> and then it checks -lgdbm and gdbm_open symbol in configure or something
2021-10-22 19:08:12 <ikke> I don't even see it checking for gdbm.h
2021-10-22 19:08:23 <psykose> then it definitely wants the --with-gdbm opt
2021-10-22 19:08:58 <ikke> It just says "checking for default DBM... gdbm"
2021-10-22 19:10:43 <ikke> DBM={sdbm,gdbm,ndbm,db,db1,db185,db2,db3,db4,db4X,db5X,db6X} 
2021-10-22 19:10:47 <ikke> no gdmb in there
2021-10-22 19:11:17 <ikke> but later it mentions gdbm
2021-10-22 19:11:44 <ikke> let me try what you suggeted
2021-10-22 19:12:05 <ikke> oh, gdmb != gdbm
2021-10-22 19:12:50 <ikke> That works better
2021-10-22 19:13:38 <ikke> for some values of better :P
2021-10-22 19:13:44 <ikke> test failure
2021-10-22 19:16:31 <psykose> yeah it needs --with-gdbm=/usr like the apr option, then scanelf shows libgdbm, and yes a dbm test seems to fail
2021-10-22 19:17:16 <ikke> it works for me without =/usr
2021-10-22 19:17:32 <psykose> ah, it was just the first thing i tried
2021-10-22 19:17:38 <psykose> without it didn't link
2021-10-22 19:18:01 <psykose> but yeah not sure if the tests are legit broken
2021-10-22 19:18:08 <psykose> there is also a newer release of 1.7.0
2021-10-22 19:18:11 <psykose> wonder if anything changed
2021-10-22 19:18:45 <ikke> psykose: I fell for that one
2021-10-22 19:18:51 <ikke> apr != apr-util
2021-10-22 19:19:18 <psykose> hahaha
2021-10-22 19:19:19 <psykose> me too then
2021-10-22 20:08:22 <ikke> I'm stuck debugging this :/
2021-10-23 02:35:29 <Ariadne> it seems that every time we do a release, libtorrent-rasterbar is a source of contention for tests
2021-10-23 02:35:34 <Ariadne> can we just disable tests
2021-10-23 02:35:35 <Ariadne> for it
2021-10-23 02:39:12 <psykose> are the constantly broken tests actually indicative of fixes ever
2021-10-23 02:39:18 <psykose> or are the only fixes for the tests alone
2021-10-23 02:43:36 <Ariadne> the tests have a deadlock bug
2021-10-23 03:02:59 <andypost[m]> it means tests are untestable in CI
2021-10-23 03:03:31 <psykose> sounds like a good disable reason then
2021-10-23 03:03:49 <andypost[m]> it looks weird that builders spending 2 days in flacky tests
2021-10-23 04:03:52 <anjan> can someone please review this patch? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26607
2021-10-23 04:07:18 <anjan> Also, Im trying to get this in for 3.15 since I want better bluetooth support: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26640
2021-10-23 04:07:24 <anjan> I have no idea why it's not compiling
2021-10-23 04:07:27 <anjan> please help...
2021-10-23 04:19:58 <Ariadne> anjan: its not compiling because pipewire needs to build first
2021-10-23 04:20:35 <Ariadne> anjan: pipewire fails to build because it tries to download an external dependency, which is blocked by abuild-meson
2021-10-23 04:20:46 <Ariadne> anjan: src/daemon/meson.build:40:2: ERROR: Automatic wrap-based subproject downloading is disabled
2021-10-23 04:21:02 <anjan> oh I see....
2021-10-23 04:21:11 <anjan> Sorry Im not familiar with errors that meson spits out
2021-10-23 04:21:15 <anjan> I havent used it alot
2021-10-23 04:21:26 <anjan> so I apologize if Im just asking you to read me the error ahaha
2021-10-23 04:21:47 <psykose> i get the exact same media-session error with pipewire already built on my system
2021-10-23 04:21:57 <Ariadne> yes, because
2021-10-23 04:22:02 <Ariadne> the new aport
2021-10-23 04:22:04 <anjan> any idea how to fix?
2021-10-23 04:22:08 <Ariadne> is dependent on pipewire >=0.3.39
2021-10-23 04:22:13 <psykose> i assume they didn't set up the build correctly and it doesn't work with .38
2021-10-23 04:22:16 <Ariadne> if you build against .38
2021-10-23 04:22:19 <Ariadne> yeah
2021-10-23 04:22:20 <psykose> yes, it's fixed in media-session master
2021-10-23 04:22:29 <psykose> but on the 0.4.0 tag it accepts 0.3.38
2021-10-23 04:22:34 <psykose> unlucky
2021-10-23 04:22:43 <Ariadne> (the APKBUILD should probably depend on pipewire>=0.3.39-r0)
2021-10-23 04:22:52 <psykose> yep
2021-10-23 04:22:58 <psykose> alternatively, you could drop media-session
2021-10-23 04:23:01 <psykose> and package wireplumber instead
2021-10-23 04:23:02 <anjan> okay
2021-10-23 04:23:18 <anjan> the problem is, pipewire does not compile without media session
2021-10-23 04:23:22 <psykose> it does
2021-10-23 04:23:26 <psykose> you pass the new -D flag
2021-10-23 04:23:28 <Ariadne> uhh, it has to
2021-10-23 04:23:38 <Ariadne> since media-session depends on it
2021-10-23 04:23:38 <psykose> -Dsession-managers
2021-10-23 04:23:42 <anjan> psykose: new -D flag to?
2021-10-23 04:23:46 <psykose> pipewire
2021-10-23 04:23:56 <psykose> default is media-session, which is what pulls the autodep
2021-10-23 04:24:00 <psykose> you need to set it to empty
2021-10-23 04:24:15 <Ariadne> anyway, i will leave this in psykose's hands
2021-10-23 04:24:16 <psykose> since it's a separate and not joint build
2021-10-23 04:24:21 <Ariadne> i don't use pipewire yet
2021-10-23 04:24:33 <anjan> ya, thanks you Ariadne I really appreciate it
2021-10-23 04:24:35 <Ariadne> given that it comes from GNOME i automatically have doubts about its reliability
2021-10-23 04:24:36 <psykose> it works pretty alright, but i give another 6 months to be a bit more mature
2021-10-23 04:24:42 <psykose> it's better than everything before it
2021-10-23 04:25:03 <Ariadne> doubt intensifies
2021-10-23 04:25:16 <Ariadne> pipewire 0.5 will probably depend on systemd
2021-10-23 04:25:29 <anjan> ugh that would suck
2021-10-23 04:25:42 <anjan> I like pipewire cause I need bluetooth audio
2021-10-23 04:25:50 <anjan> ik bluetooth audio sucks
2021-10-23 04:26:00 <anjan> but ppl come over and I need it =(
2021-10-23 04:26:31 <psykose> anjan: anyway, on main pipewire pass -Dsession-managers=""
2021-10-23 04:26:41 <anjan> ya, I'm testing that ps
2021-10-23 04:26:45 <psykose> the rest should fix itself
2021-10-23 04:26:53 <psykose> i also recommend throwing in wireplumber if you have the time
2021-10-23 04:27:07 <anjan> Ill take a look
2021-10-23 04:27:20 <psykose> and don't feel bad about bluetooth audio, pipewire is the first thing i've used that seems to support it with minimal issues for playback
2021-10-23 04:27:23 <anjan> psykose: do I need to do anything else to make sure pipewire-media-session works with pipewire?
2021-10-23 04:27:38 <anjan> cause Im disabling it in the compile flag
2021-10-23 04:27:44 <psykose> as far as i can tell all the issues are from the version fail
2021-10-23 04:27:56 <psykose> and that flag is just for the stacked/combined build, building it as subproject
2021-10-23 04:28:00 <psykose> i think that is the only change you need
2021-10-23 04:28:09 <psykose> oh, and the dep in media-session
2021-10-23 04:28:16 <psykose> pipewire>=0.3.39-r0
2021-10-23 04:28:26 <psykose> since it's not set correctly in the meson config on the 0.4.0 tag
2021-10-23 04:28:35 <psykose> that should be fine, then we'll see
2021-10-23 04:28:36 <anjan> ok, makedepends or depends?
2021-10-23 04:28:53 <psykose> depends i think
2021-10-23 04:29:04 <psykose> can't run it without pipewire afterall
2021-10-23 04:29:32 <anjan> makedepends on pipewire-dev>=0.3.39 right
2021-10-23 04:29:36 <Ariadne> yes
2021-10-23 04:29:37 <psykose> yep
2021-10-23 04:30:49 <anjan> psykose: https://paste.sr.ht/~anjan/b4e6de5fcba024c9cc67934151b70a221d912c56
2021-10-23 04:31:36 <psykose> that looks like you're missing an update
2021-10-23 04:31:47 <psykose> ah, it's in testing only
2021-10-23 04:31:58 <psykose> er, i mean edge
2021-10-23 04:32:06 <anjan> but pipewire is in community
2021-10-23 04:32:15 <psykose> it is in community, i meant it's not on 3.14
2021-10-23 04:32:41 <anjan> oh
2021-10-23 04:32:46 <anjan> I guess Ill compile those programs
2021-10-23 04:32:51 <anjan> and install manually
2021-10-23 04:32:55 <psykose> all of those are more recent than the 3.14 release so makes sense
2021-10-23 04:36:00 <psykose> you also need gettext-dev instead of libs, and you don't need cmake i don't think in makedepends
2021-10-23 04:39:49 <anjan> ohhh interesting, ya I saw that pipewire compiles without cmake
2021-10-23 04:39:52 <anjan> Ill fix those, thanks
2021-10-23 04:39:57 <anjan> looks like pipewire is working....
2021-10-23 04:40:39 <psykose> should be fine then :)
2021-10-23 04:43:33 <anjan> hmm, 3 of the 17 tests failed ps
2021-10-23 04:43:40 <anjan> psykose: should I just push?
2021-10-23 04:43:56 <psykose> for wireplumber you would only need -Dsystem-lua=true, lua5.4-dev (or 5.3, but idk which is preferred here), glib-dev, and elogind-dev (but i'm unsure if this makes it optional afterward)
2021-10-23 04:43:59 <psykose> sure, lets see it on ci
2021-10-23 04:51:59 <anjan> psykose: https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/519521
2021-10-23 04:52:36 <psykose> this looks like a missing libintl-dev error, but i'm not sure why it triggers
2021-10-23 04:54:07 <psykose> ah, it flags as intl support = yes in the build configure, which means it found it and tries to use it, but then the versions or w/e are wrong
2021-10-23 04:54:23 <anjan> maybe I should just disable it
2021-10-23 04:54:50 <anjan> actually idk, translation support is important...
2021-10-23 04:55:36 <psykose> it pulls in libintl by something in the dep chain, you could just try add libintl-dev and see if that fixes it
2021-10-23 04:55:52 <psykose> i don't think it's actually used though
2021-10-23 04:57:29 <psykose> by the comment in the meson.build this is just for freebsd anyway, but since there's no flag you would have to patch the lines otherwise, since meson doesn't have a --option to disable a specific optional dep
2021-10-23 04:58:35 <anjan> ok pushed v3 of the pipewire
2021-10-23 04:58:46 <anjan> lets see if I can package wireplumber while it's building
2021-10-23 04:59:49 <psykose> ah, you should add !s390x to session too
2021-10-23 04:59:54 <psykose> same as in pipewire
2021-10-23 05:00:03 <psykose> and for wireplumber as well
2021-10-23 05:00:55 <psykose> also i don't know where i pulled libintl-dev from as it doesn't actually exist :p
2021-10-23 05:01:22 <anjan> lmfao ya
2021-10-23 05:01:32 <anjan> I just checked the CI and it's complaining....
2021-10-23 05:01:40 <anjan> ok lmk if you find the missing dependency ps
2021-10-23 05:01:47 <anjan> how did this compile on my machine?????
2021-10-23 05:07:59 <psykose> fails to build on mine with the same error actually
2021-10-23 05:08:11 <anjan> ok lemme try to build this on my pinebook pro
2021-10-23 05:09:21 <psykose> probably missing something really obvious
2021-10-23 05:10:42 <anjan> psykose: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26714
2021-10-23 05:10:50 <anjan> I got everything except the checks
2021-10-23 05:12:24 <psykose> you need the -D lua stuff so it doesn't use embedded lua
2021-10-23 05:12:43 <anjan> oh sorry
2021-10-23 05:12:48 <anjan> I remember you saying that
2021-10-23 05:13:13 <psykose> and its 5.4 or .3, not .1 for makedepends
2021-10-23 05:13:15 <psykose> it's alright
2021-10-23 05:13:34 <psykose> also you don't need the pipewire-dev>= version here as it's correct in the meson file
2021-10-23 05:22:42 <psykose> i'm really confused by this error, because the previous version builds fine and the intl function have been there for months
2021-10-23 05:22:44 <anjan> oh hey, I got it compiling
2021-10-23 05:22:50 <psykose> and they are provided by musl libintl
2021-10-23 05:22:53 <anjan> on my aarch64
2021-10-23 05:23:09 <anjan> let it finish and Ill push my changes
2021-10-23 05:23:19 <psykose> what did you change
2021-10-23 05:23:25 <anjan> I forgot
2021-10-23 05:23:31 <anjan> I dont wanna touch anything
2021-10-23 05:23:37 <anjan> but Ill git diff when it's done
2021-10-23 05:23:47 <anjan> psykose should I be using abuild-meson?
2021-10-23 05:23:55 <psykose> uh probably
2021-10-23 05:24:41 <anjan> -       libintl-dev
2021-10-23 05:24:44 <anjan> +       libintl
2021-10-23 05:24:52 <anjan> but it fails on linking
2021-10-23 05:24:56 <anjan> should i git push?
2021-10-23 05:25:20 <psykose> you don't need libintl in there, but yeah we're just back to before
2021-10-23 05:44:58 <anjan> ok I kind of give up lol
2021-10-23 05:45:04 <anjan> hopefully bart can help me
2021-10-23 05:45:12 <anjan> PureTryOut: cc ^
2021-10-23 05:45:33 <psykose> blech, idk how to fix it, building it locally with gettext-dev providing libintl.h also fails with any set, and passes with musl-libintl, but you can't use that with the configured features as they end up depending on gettext-dev
2021-10-23 05:45:50 <psykose> just another weird libintl case i guess, but it makes me wonder why the previous builds worked
2021-10-23 05:47:27 <psykose> ah, .38 and .39 changed the meson.build libintl search
2021-10-23 05:47:37 <psykose> i think that fucks up something with the compile flags to do with musl
2021-10-23 05:47:51 <psykose> .38 -> .39* i mean
2021-10-23 05:47:54 <psykose> that is the difference
2021-10-23 05:49:03 <psykose> but based on the way it passes and what the configure reports... it looks like it should be the same
2021-10-23 05:50:13 <psykose> ah, the difference is it's dependency('intl') instead of cc.find_library('intl)
2021-10-23 05:50:17 <psykose> probably passes on the first
2021-10-23 05:52:29 <anjan> okay....
2021-10-23 05:52:32 <anjan> so what do? psykose 
2021-10-23 05:52:52 <psykose> i am testing a small patch
2021-10-23 05:53:05 <anjan> ok im going to sleep soon
2021-10-23 05:53:12 <psykose> it is 8am for me
2021-10-23 05:53:16 <anjan> feel free to post in the MR about any issues or solutions you run into
2021-10-23 05:53:20 <anjan> 2 am for me lol
2021-10-23 05:53:26 <psykose> i fixed it
2021-10-23 05:53:32 <anjan> oh hey!
2021-10-23 05:53:34 <anjan> send pls\
2021-10-23 05:53:40 <psykose> well, the tests fail
2021-10-23 05:53:48 <anjan> Id love to have bluetooth support fixed before I sleep
2021-10-23 05:54:00 <anjan> ya, they fail on wireplumber too....
2021-10-23 05:54:05 <psykose> https://termbin.com/c3ppc but this patch fixes the build
2021-10-23 05:54:19 <psykose> it's a revert to the old libintl search
2021-10-23 05:54:26 <anjan> ok
2021-10-23 05:54:32 <anjan> name and email of author? ;)
2021-10-23 05:54:48 <psykose> credit yourself ;)
2021-10-23 05:56:40 <psykose> the actual fix is something with the way meson handles the difference between dependency() and cc.get_library(), but i know nothing about that or why it ends up making different flags
2021-10-23 05:56:44 <psykose> i might explore another time
2021-10-23 05:56:54 <anjan> ok
2021-10-23 05:56:58 <anjan> is disabling tests ok?
2021-10-23 05:57:01 <anjan> what should I say?
2021-10-23 05:57:09 <anjan> # tests fail psykose ?
2021-10-23 05:57:18 <psykose> i don't know if they are actual failures
2021-10-23 05:57:27 <psykose> i guess you can do that, but it's not well researched
2021-10-23 05:57:45 <psykose> in the meantime; it builds, you can just install it from the build, but i would recommend being on edge if you really want to do that
2021-10-23 05:58:03 <psykose> since it is an edge-community package cause of the new deps properly
2021-10-23 05:58:29 <anjan> psykose: I just want it to be included in alpine 3.15
2021-10-23 05:58:36 <anjan> so it can roll down to pmos
2021-10-23 05:58:43 <psykose> in that case the maintainer needs to go look at the tests
2021-10-23 05:58:46 <anjan> and I can finally have working bluetooth on my pienphone lol
2021-10-23 05:58:47 <psykose> but the build is fine with the patch for now
2021-10-23 05:58:55 <anjan> ok, I wont disable the tests. Ill ping Bart
2021-10-23 05:58:57 <anjan> thanks psykose 
2021-10-23 05:59:07 <psykose> sleep well
2021-10-23 06:00:19 <psykose> and i would push the changes for now, just add the patch and remove the libintl-dev that doesn't exist hah
2021-10-23 06:08:37 <psykose> anjan: you forgot to remove the one dep :p
2021-10-23 06:09:07 <anjan> psykose: refresh, I fixed it ;)
2021-10-23 06:09:11 <psykose> ^^
2021-10-23 06:09:12 <psykose> :)
2021-10-23 06:09:15 <anjan> sorry, I git commit --amend alot lol
2021-10-23 06:09:18 <psykose> that's fine
2021-10-23 06:09:52 <psykose> i wanted to say that 5 minutes ago but just afraid of nagging you
2021-10-23 06:10:00 <anjan> no worries
2021-10-23 06:10:05 <anjan> I appreciate the nag
2021-10-23 06:10:17 <psykose> think it's actual time we both head to bed
2021-10-23 06:10:30 <anjan> is there any reason newapkbuild gives a meson template that doesnt have abuild-meson?
2021-10-23 06:10:43 <psykose> i've no idea on the difference between them
2021-10-23 06:11:01 <psykose> ah
2021-10-23 06:11:07 <psykose> it sets the defaults, for dirs
2021-10-23 06:11:11 <anjan> ya, but I think the template shouldnt recommend a nonrecommended option lol
2021-10-23 06:11:19 <psykose> you can see in /usr/bin/abuild-meson, easy to see
2021-10-23 06:11:24 <anjan> oh i see
2021-10-23 06:11:24 <psykose> yeah, i think the template needs an update
2021-10-23 06:11:32 <anjan> ok, Ill send a patch for that template too
2021-10-23 06:11:34 <anjan> might as well
2021-10-23 06:11:39 <anjan> I have slept at 3 am every night
2021-10-23 06:11:41 <anjan> lol
2021-10-23 06:11:54 <psykose> ditto for morning
2021-10-23 06:22:25 <anjan> ok sent 
2021-10-23 06:22:33 <anjan> didnt take long. grep is a nice tool
2021-10-23 06:23:17 <psykose> grep (or well, rg) is probably the most typed thing i have along with the text editor
2021-10-23 06:23:35 <anjan> haha ya, grep, git and emacs
2021-10-23 06:23:42 <anjan> I dont know how people programmed without them
2021-10-23 06:24:16 <psykose> :p
2021-10-23 06:35:48 <pj> a bit of persistence
2021-10-23 06:38:30 <pj> also, good morning Europe
2021-10-23 06:39:29 <ikke> o/
2021-10-23 07:08:48 <smcavoy> I was going to attempt to get the rock-pi-4b (rk3399 based) SBC enabled in `linux-lts` and wondering if anyone has any useful info. It is supported in mainline and I have a booting system but figuring out what modules are needed is fairly hit and miss.. 
2021-10-23 07:12:31 <mps> smcavoy: look at testing/linux-gru, it is rk3399 chromebook, I'm using it for about 2-3 years with mainline linux (from 5.1 iirc)
2021-10-23 07:16:11 <smcavoy> thanks, I will take a look. 
2021-10-23 10:29:00 <ktprograms> Why does nextcloud depend on php8? The official documentation says php 7.2, 7.3 or 7.4 is required
2021-10-23 10:32:32 <ikke> I guess because it can, or do you have issues with it?
2021-10-23 10:32:38 <ikke> 6409f8ab2f93e170bae06d765ab89a3a3fea61d2
2021-10-23 10:39:18 <ktprograms> ikke: php8 installs the php8 command but nextcloud occ wants /usr/bin/php which comes with php7
2021-10-23 10:39:41 <ktprograms> So now I have 2x the php modules on my system (1 set for php8 and 1 set for php7)
2021-10-23 10:40:23 <ikke> simple local fix would be to symlink php to php8
2021-10-23 10:40:34 <PureTryOut> Fun, someone upgraded py3-requests and it's now broken due to missing an unpackaged dep
2021-10-23 10:40:35 <ikke> The goal is to switch php to php8
2021-10-23 10:40:42 <ikke> PureTryOut: yay
2021-10-23 10:41:40 <ktprograms> ikke: Ok I'll do that. BTW is there fish completion for the nextcloud occ command? It doesn't seem to have a manpage for fish to use either
2021-10-23 10:43:10 <ikke> I don't think it comes with any completion
2021-10-23 10:44:23 <ktprograms> Ok, thanks anyway
2021-10-23 10:49:29 <PureTryOut> ikke: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26721 fixes it
2021-10-23 10:49:56 <PureTryOut> upstream switched the py3-chardet dep to py3-charset-normalizer, but this has been ignored while upgrading py3-requests. I'm assuming nobody tested that upgrade
2021-10-23 10:50:02 <ikke> No maintainer, though 
2021-10-23 10:52:32 <PureTryOut> yeah I have no interest in maintaining that package
2021-10-23 11:19:10 <PureTryOut> Cogitri: what's the reason to pass `-v` (verbose) to meson while running tests? Don't we just need to see logs of failing tests?
2021-10-23 11:19:38 <PureTryOut> I just had to switch to `-q` and `--print-errorlogs` just to be able to find why a test was failing as my terminal was filled all the way up with verbose stuff otherwise
2021-10-23 11:43:43 <PureTryOut> anjan: sorry I found it easier to do the upgrade myself 😅 !26724
2021-10-23 11:51:34 <Cogitri[m]> PureTryOut (matrix.org): Ah it’s just that I prefer it to be verbose since getting the test log from the builders is a bit of a nuisance
2021-10-23 11:51:47 <Cogitri[m]> And sometimes there’s valuable info in the rest of the log
2021-10-23 11:53:42 <PureTryOut> I really don't see why a log of a successful test is useful but sure 😛
2021-10-23 11:55:23 <ikke> I'm thinking of moving all libtorrent-rasterbar related packages to unmaintained
2021-10-23 12:01:02 <PureTryOut> It has a maintainer though? Or are they not active anymore?
2021-10-23 12:01:08 <ikke> correct
2021-10-23 12:01:19 <ikke> and librasterbar tests keep hanging
2021-10-23 12:01:25 <ikke> libtorrent-rasterbar
2021-10-23 12:02:29 <Sheila> is that the one rtorrent wants?
2021-10-23 12:02:37 <PureTryOut> yeah I saw it in #_oftc_#alpine-commits:matrix.org.
2021-10-23 12:03:10 <ikke> Sheila: no, it just depends on libtorrent
2021-10-23 12:03:24 <ikke> only btfs depends on it
2021-10-23 12:03:29 <ikke> and python3 modules
2021-10-23 12:03:48 <Sheila> ah.
2021-10-23 12:04:09 <ikke> oh, qbittorrent-nox as well
2021-10-23 12:04:45 <ikke> but v2.0.4 is out and we're still on 1.2.14
2021-10-23 12:08:33 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26571
2021-10-23 12:08:56 <omni> should the config files rather go under some doc/examples dir?
2021-10-23 12:09:15 <omni> I'm also tempted to put this in community
2021-10-23 12:09:54 <omni> !26571
2021-10-23 12:10:07 <omni> (so you know what it is without having to follow the link)
2021-10-23 12:11:05 <ikke> too late :( :P
2021-10-23 12:14:41 <ikke> with cmake, is there an easy way to list what knobs are available?
2021-10-23 12:14:47 <ikke> for a specific project
2021-10-23 12:15:20 <PureTryOut> knobs as in options? Not really, you'll have to check all `CMakeLists.txt`'s for `option()` statements
2021-10-23 12:16:09 <ikke> ok
2021-10-23 12:17:21 <PureTryOut> That's one thing I really love about meson, the `meson_options.txt` file
2021-10-23 12:49:23 <ktprograms> Should the nextcloud.conf php-fpm configuration (installed with nextcloud-initscript) contain user = nextcloud and group = nextcloud so that the php-fpm8 service can start without error?
2021-10-23 13:09:18 <Hello71> cmake -LH
2021-10-23 13:10:11 <Hello71> or open gui, i think it is cmake-gui
2021-10-23 13:31:57 <j--r> Hi, could someone tell me why my merge request to aports wasn't merged since more than a month and did not really receive any comment, except from an aproval?
2021-10-23 13:32:19 <j--r> The merge request I'm talking about could be found here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25609
2021-10-23 13:32:35 <mps> !25609
2021-10-23 13:37:19 <ikke> anoying when make install tries to build the source again :/
2021-10-23 13:40:12 <ikke> maybe it's something different
2021-10-23 13:47:52 <j--r> ikke: you mean the telegram-tdlib package I just updated?
2021-10-23 13:47:56 <ikke> no
2021-10-23 13:48:06 <ikke> I'm working on something myself
2021-10-23 13:49:12 <j--r> Oh now I see, just missed some backlog
2021-10-23 13:52:47 <PureTryOut> j--r: limited time and most developers are doing this in their free time. Note that most PR's get less attention when their CI is still red, in your case the s390x architecture is failing and needs fixing
2021-10-23 13:52:59 <PureTryOut> Also please reword the first commit to say "upgrade" rather than "update"
2021-10-23 14:09:21 <j--r> PureTryOut: I can't fix the s390x architecture, because telegram-tdlib couldn't be build on it, but both other packages are technically architecture independent
2021-10-23 14:09:41 <PureTryOut> Then disable the package on that architecture
2021-10-23 14:10:42 <j--r> Okay, I wasn't sure about it, but if you say so I will do it
2021-10-23 14:10:50 <ikke> I would not expect someone running tg on s390x :P
2021-10-23 14:12:01 <j--r> Fair point xD
2021-10-23 14:30:48 <j--r> PureTryOut: I adjusted the commit message and got the CI green, thanks for your tips
2021-10-23 14:30:57 <Newbyte> It wouldn't be too out there of an idea to run a userbot on s390x 
2021-10-23 14:31:29 <PureTryOut> j--r: please reword "update" to "upgrade" in the commit messages
2021-10-23 14:32:42 <j--r> PureTryOut: I did reword it...
2021-10-23 14:33:14 <PureTryOut> Oh sorry, Gitlab did not update the message 😒
2021-10-23 14:33:22 <PureTryOut> You did indeed, thanks!
2021-10-23 14:34:22 <ikke> The description is not updated when you update the commit message
2021-10-23 14:35:03 <PureTryOut> nah I was looking at the commit overview
2021-10-23 14:35:08 <ikke> right
2021-10-23 14:35:14 <ikke> Then it would just show the same commit indeed
2021-10-23 14:35:15 <PureTryOut> I just had to refresh the page, but I expected it to update automatically
2021-10-23 14:45:47 <j--r> PureTryOut: thanks for merging
2021-10-23 14:46:10 <PureTryOut> np
2021-10-23 14:49:33 <Saijin_Naib[m]> Not sure who Leo is on here, but I believe I've addressed their review for !26708
2021-10-23 14:50:59 <ikke> maxice8
2021-10-23 14:51:20 <maxice8> cleaning room
2021-10-23 15:13:22 <Newbyte> Saijin_Naib: I think it just should be "community/flatseal: move from unmaintained"
2021-10-23 15:14:28 <Saijin_Naib[m]> Damn... I was unsure since the example was moving from main to community
2021-10-23 15:14:40 <Saijin_Naib[m]> I didn't know if from Unmaintained was a special case or not
2021-10-23 15:14:42 <Saijin_Naib[m]> Thank you for the correction
2021-10-23 15:26:18 <Saijin_Naib[m]> Newbyte: I think this should be to spec, or at least better
2021-10-23 15:27:04 <Newbyte> looks good to me
2021-10-23 15:27:38 <mps> Saijin_Naib[m]: read the COMMITSTYLE.md
2021-10-23 15:27:42 <Saijin_Naib[m]> Thank you all for your patience and assistance haha
2021-10-23 15:27:51 <Saijin_Naib[m]> I did, but not carefully enough it seems
2021-10-23 15:28:13 <mps> - `$newrepository/$pkgname: move from $oldrepository`
2021-10-23 15:29:00 <Saijin_Naib[m]> Yep. I didn't know it unmaintained was a special case
2021-10-23 15:29:15 <Saijin_Naib[m]> The example is demoting main to community
2021-10-23 15:29:35 <mps> it is just example
2021-10-23 15:36:24 <PJ[m]> if in doubt, you can search for previous commits
2021-10-23 16:00:40 <Saijin_Naib[m]> Fair, thank you
2021-10-23 16:36:31 <Newbyte> Saijin_Naib: you should also remove the draft status that Leo added if you want it to get merged
2021-10-23 16:44:52 <Saijin_Naib[m]> That doesn't happen once it passes some type of review? Or is me adding draft signaling that I'd like a review?
2021-10-23 16:44:59 <Saijin_Naib[m]> Removing draft, rather
2021-10-23 17:03:47 <Newbyte> Saijin_Naib: draft means that you are not done with it 
2021-10-23 17:03:57 <Newbyte> so it's up to you to remove that generally 
2021-10-23 17:28:34 <anjan> PureTryOut: no worries, I didnt want to maintain those packages anyways ahaha
2021-10-23 17:28:49 <anjan> I just wanted to make sure it was in 3.15 for pmOS 
2021-10-23 17:28:59 <anjan> glad my patch helped tho
2021-10-23 17:36:57 <psykose> hm, for some reason the wireplumber package depends on a bunch of -dev packages in runtime, even though i've ran it this whole time without them
2021-10-23 17:38:01 <psykose> or rather, the apk depends on them
2021-10-23 17:40:56 <psykose> all -dev provides is header files that don't get used, i wonder why it triggered the dependency in packaging
2021-10-23 17:44:03 <Hello71> the build log explains
2021-10-23 17:44:18 <Hello71> (if the APKBUILD doesn't)
2021-10-23 17:45:11 <ikke> A symlink to a dev file might cause that
2021-10-23 17:46:39 <psykose> yep, the install includes headers and a .pc with references to the other -dev's
2021-10-23 18:00:14 <psykose> ah, it just needs a wireplumber-dev subpackage declared
2021-10-23 18:01:32 <ikke> victoria-metrics is anoying
2021-10-23 18:01:37 <ikke> seems like a rounding difference
2021-10-23 18:01:44 <ikke> but locally I don't get that
2021-10-23 18:02:08 <ikke> value: 11.54873935725775, expected: 11.548739357257748
2021-10-23 18:03:38 <Hello71> link?
2021-10-23 18:03:42 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/victoria-metrics/victoria-metrics-1.68.0-r0.log
2021-10-23 18:11:51 <PureTryOut> anjan: ah yeah sure. Note that I would have upgraded it today anyway, I just didn't get the chance because you were quicker lol
2021-10-23 18:12:38 <anjan> oh ok, no worries
2021-10-23 18:12:41 <anjan> appreciate the work
2021-10-23 18:12:48 <anjan> now to make a bluetooth metapackage for sxmo
2021-10-23 18:36:44 <Hello71> ikke: the test is wrong in the first place, but i'm not sure why it would be different on builder vs local
2021-10-23 18:37:00 <Hello71> assuming both native x86_64
2021-10-23 18:37:09 <ikke> yup
2021-10-23 18:37:18 <ikke> both lxc on x86_64
2021-10-23 18:37:48 <Hello71> oh, go uses its own sinh, not libc
2021-10-23 18:38:08 <Hello71> er, wait, no, hold on
2021-10-23 18:39:49 <Hello71> odd, it uses its own go impl except for s390x, where it uses its own asm impl
2021-10-23 18:47:01 <Hello71> er, i got distracted. i think it may produce different results depending on if you have avx and fma
2021-10-23 18:48:18 <Hello71> i haven't closely investigated the implementation (my asm is not that good) but use of fma generally does cause different ("more accurate") results
2021-10-23 18:49:36 <Hello71> so i think disable tests and report upsream
2021-10-23 18:54:22 <ikke> ahuh
2021-10-23 18:55:31 <ikke> Hello71: fyi, cpuflags from the builders: https://tpaste.us/lyPN
2021-10-23 18:56:12 <ikke> avx on that one
2021-10-23 18:56:56 <ikke> The one where it succeeds has avx and fma
2021-10-23 19:42:17 <ngortheone> PureTryOut: I think I found a bug in pipewire-alsa package. Please check out #13118
2021-10-23 19:43:27 <ngortheone> I also think pipewire-alsa should depend on `alsa-plugins` (nothing worked until I installed it), or there is something wrong pipewire-alsa package, that is accidentally fixed by alsa-plugins
2021-10-23 19:43:50 <PureTryOut> Sounds sane that it depends on alsa-plugins
2021-10-23 19:44:06 <PureTryOut> I don't use Pipewire myself that way so I hadn't noticed any problems, and neither did I create that subpackage
2021-10-23 19:44:10 <PureTryOut> thanks for finding out!
2021-10-23 19:44:15 <PureTryOut> could you make a MR for those changes?
2021-10-23 19:44:53 <ngortheone> sure. do you want me to add dependency in the same MR or should I create separate issue + mr?
2021-10-23 19:46:23 <ngortheone> about alsa-plugins - I don't know how alsa really works. But it seems that pipewire-alsa should't depend on alsa-plugins. Simply check out contents of both packages: those plugins should be independent...
2021-10-23 19:48:50 <PureTryOut> add it to same MR
2021-10-23 19:50:32 <PureTryOut> I don't really know how alsa works either...
2021-10-23 19:55:31 <psykose> alsa playback works for me with just the conf.d move
2021-10-23 20:00:45 <ngortheone> I'll uninstall alsa-plugins and see if it works for me..
2021-10-23 20:03:02 <ngortheone> ok, it works. It was late yesterday, I must have confused something. MR incoming
2021-10-23 20:06:34 <PureTryOut> ah good 😄
2021-10-23 20:06:38 <PureTryOut> please link it once you made it
2021-10-23 20:06:48 <PureTryOut> it might actually fix audacity on my system lol
2021-10-23 20:13:27 <ngortheone> still cloning aports..
2021-10-23 20:18:34 <vyivel> ngortheone: with --depth=1?
2021-10-23 20:21:11 <ngortheone> no, full:)
2021-10-23 20:28:16 <ngortheone> alsa-plugins puts symlinks into /etc/alsa/conf.d/ but I don't see what creates the symlink in https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/alsa-plugins/APKBUILD#L97-107
2021-10-23 20:28:27 <ngortheone> How do I do this in pipewire-alsa?
2021-10-23 20:29:21 <ngortheone> or maybe symlinking from /usr/share/alsa/alsa.conf.d/ is not a good idea?
2021-10-23 20:29:35 <ikke> That doesn't create any symlinks, at most, it moves existing symlinks
2021-10-23 20:29:49 <ikke> They would've been created here: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/alsa-plugins/APKBUILD#L84
2021-10-23 20:30:16 <ngortheone> i see
2021-10-23 20:35:47 <ngortheone> #26740
2021-10-23 20:35:56 <ngortheone> hmm...
2021-10-23 20:36:05 <ngortheone> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26740
2021-10-23 20:36:37 <ngortheone> PureTryOut: this ^^^ should do it, but don't take my word for it. I didn't built it locally
2021-10-23 20:37:37 <PureTryOut> You need to bump the pkgrel
2021-10-23 20:38:07 <PureTryOut> Looks fine otherwise
2021-10-23 20:39:05 <ngortheone> fixed
2021-10-23 20:40:04 <PureTryOut> Cool. Could you rebase it on master?
2021-10-23 20:40:14 <PureTryOut> (otherwise I can't seem to merge from web ui)
2021-10-23 20:40:27 <ngortheone> done
2021-10-23 20:46:07 <Hello71> ikke: could be. https://github.com/golang/go/blob/master/src/math/sinh.go calls https://github.com/golang/go/blob/master/src/math/exp_amd64.go which varies based on cpu.X86.HasAVX && cpu.X86.HasFMA
2021-10-23 20:46:38 <ikke> Hello71: https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1738
2021-10-23 20:46:55 <Hello71> ok, i will add some links
2021-10-23 21:06:38 <ngortheone> This still shows files in old location. https://pkgs.alpinelinux.org/contents?branch=edge&name=pipewire-alsa&arch=x86_64&repo=community
2021-10-23 21:07:01 <ngortheone> Is file index lags behind package builds?
2021-10-23 21:09:03 <NCommander> So, I'm dealing with a situation that I'm not sure is a bug or user error
2021-10-23 21:09:13 <NCommander> so I wanted to check here before filing a report
2021-10-23 21:09:44 <NCommander> I've got alpine mounting an encrypted iSCSI target. The LUKS device is unlocked via keyfile, and both crypttab and /etc/fstab have _netdev in options
2021-10-23 21:09:46 <psykose> ngortheone: it hasn't pushed yet
2021-10-23 21:10:03 <psykose> the package is -r1, your commit is -r2, just takes a bit of time
2021-10-23 21:10:15 <NCommander> what happens is that netmount runs before iscsi is running, and so the mounts fail.
2021-10-23 21:10:16 <ngortheone> ack, thanks psykose
2021-10-23 21:10:26 <NCommander> It seems I need a use iscsid, but I'm not sure that's correct.
2021-10-23 21:11:15 <psykose> NCommander: you can make the thing that starts iscsi be `before netmount` in it's script
2021-10-23 21:12:20 <NCommander> psykose, should I assume this is a bug and file it? I can test that in a moment
2021-10-23 21:12:53 <psykose> idk really, it just sounds like specific configuration to your usecase
2021-10-23 21:13:07 <NCommander> Well, it seems like any iscsi target can't be automounted
2021-10-23 21:13:12 <NCommander> because netmount will run before iscsi can
2021-10-23 21:13:25 <NCommander> I'm just adding encryption ontop of it, and iscsi is in core
2021-10-23 21:14:33 <psykose> then perhaps
2021-10-23 21:20:51 <NCommander> hrm, well, ... adding before netmount to iscsid sorta worked, just the crypttab didn't get loaded. I suspect I'm going to have to put something in a late running shellscript
2021-10-23 21:21:16 <NCommander> but crypttab and fstab do specifically list _netdev as a supported option. I guess I'll file a bug and see what folks say
2021-10-23 21:21:22 <NCommander> and see if I can figure out all the edits needed
2021-10-23 21:23:54 <NCommander> psykose, thank you
2021-10-23 21:24:14 <psykose> sadly i've never tried to use any network disks so i can't say much more :p
2021-10-24 05:37:18 <ngortheone> can someone check if man bwrap looks right? On my machine man page is a bit ...screwed up
2021-10-24 05:38:02 <psykose> ditto
2021-10-24 05:38:11 <psykose> looks like it wasn't generated correctly
2021-10-24 05:38:35 <psykose> bubblewrap-doc needs a looking at i guess
2021-10-24 08:51:26 <PureTryOut> andypost: note that you don't need to bump the pkgrel when you're only modifying the `check()` function (re: pkgrel bump of `community/mycroft-skills-manager`)
2021-10-24 08:52:19 <ikke> That is, when you try to fix existing build failures. 
2021-10-24 08:53:30 <PureTryOut> the test result does not appear in the resulting package, so why would you ever need to bump pkgrel?
2021-10-24 08:54:06 <ikke> Potentially to expose bugs
2021-10-24 09:00:51 <PureTryOut> I don't understand. The tests have that potential yes but why would that need bumping the pkgrel?
2021-10-24 09:01:28 <ikke> to trigger the tests to be run on the builders
2021-10-24 09:01:32 <andypost[m]> PureTryOut: as I see 3.15 builders doing something differently so better to make sure it also rebuilds in edge
2021-10-24 09:01:50 <PureTryOut> ikke: but modifying the package already triggers the builders to rebuild it no?
2021-10-24 09:01:55 <ikke> no
2021-10-24 09:02:07 <PureTryOut> then why do we not have to bump when re-enabling arches? 🤔
2021-10-24 09:02:07 <ikke> The builders verify if the package already exist
2021-10-24 09:02:13 <ikke> ^
2021-10-24 09:02:14 <PureTryOut> Oh...
2021-10-24 09:02:16 <PureTryOut> Huh
2021-10-24 09:02:19 <PureTryOut> That's a TIL.
2021-10-24 09:02:24 <PureTryOut> Ok ignore my comment then 🤗
2021-10-24 09:05:06 <ikke> buildrepo is used, which compares the packages in aports with the packages in REPODEST
2021-10-24 12:33:15 <mps> andypost[m]: ikke: I posted bug report for ncurses https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00040.html lets wait answer for some time (hope not long)
2021-10-24 12:44:48 <andypost[m]> mps: maybe just create empty dir and point configure there? It just need to exist
2021-10-24 14:50:50 <mps> andypost[m]: how to do that from APKBUILD? and I don't this is proper solution
2021-10-24 14:51:22 <andypost[m]> mps: I already failed to make it
2021-10-24 14:51:37 <andypost[m]> even inside of srcdir
2021-10-24 14:51:39 <mps> simpler and more clean solution would be to add some pkg which creates /usr/lib/pkgconfig imo
2021-10-24 14:52:25 <mps> I mean, temporarily till upstream fixes it
2021-10-24 14:52:33 <andypost[m]> I think better to have the dir created when pkgconf installed)
2021-10-24 14:52:44 <andypost[m]> but atm the issue with builders
2021-10-24 14:53:22 <mps> if we need /usr/lib/pkgconfig we should add it in alpine-base then
2021-10-24 14:54:53 <mps> I would wait till tomorrow for upstream answer and if we don't get it then we should do something to fix it in alpine, maybe patching configure
2021-10-24 15:01:20 <andypost[m]> mps: is the error means that the file is not created? maybe because /usr/local/lib as ikke said
2021-10-24 15:01:22 <andypost[m]> https://build.alpinelinux.org/buildlogs/build-edge-x86/main/ncurses/ncurses-6.2_p20211017-r0.log
2021-10-24 15:01:53 <andypost[m]> so we should fix builders first
2021-10-24 15:02:59 <andypost[m]> at least edge-x86_64 fails for strange reason
2021-10-24 16:26:23 <ikke> I feel this is some shortcomming of the ncurses autoconf logic
2021-10-24 16:26:39 <ikke> it checks if the path exists, but does not properly handle the case where it does not exist
2021-10-24 16:27:08 <ikke> If we specify what the pkgconf lib path is, it should just use / create that
2021-10-24 16:27:15 <ikke> and not depend on other packages having already created it
2021-10-24 16:27:50 <ikke> The currnent logic is: "does a path exist, then we should put pc files there"
2021-10-24 16:27:58 <ikke> but fails when no path exists
2021-10-24 16:48:00 <mps> ikke: yes, and that is how it worked till 6.2-20211009 release. on next release this is changed (and that is what I reported upstream)
2021-10-24 16:48:58 <ikke> So I don't think there is something we have to change
2021-10-24 16:49:09 <mps> and this mail is where it is anounced https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00024.html
2021-10-24 16:49:16 <mps> look at bottom
2021-10-24 16:49:55 <ikke> revise configure option --with-pkg-config-libdir,
2021-10-24 16:50:00 <mps> 'revise configure option --with-pkg-config-libdir, using the actual search path from pkg-config or pkgconf using the output from --debug'
2021-10-24 16:50:24 <mps> :)
2021-10-24 16:50:30 <mps> you are faster
2021-10-24 16:51:26 <mps> lets wait some time upstream (Thomas) is usually responsive
2021-10-24 16:52:02 <mps> if not, we could make patch for configure
2021-10-24 16:59:21 <ikke> yes, indeed
2021-10-24 18:11:03 <ddevault> how would we feel about setting GOPROXY=direct as the default for the Go toolchain in Alpine
2021-10-24 18:11:14 <ddevault> the current default behavior is to route all packages fetches through google's servers
2021-10-24 18:13:14 <ddevault> I don't feel that Google has adequately disclosed this behavior per GDPR et al, for one
2021-10-24 18:13:22 <ddevault> but also we should generally patch software which phones home
2021-10-24 18:14:20 <ddevault> that said, there are some broader consequences to disabling the proxy. It acts as a crutch for packages which use outdated dependencies, which causes packages to build correctly despite having broken dependencies
2021-10-24 18:14:26 <ddevault> so it goes unnoticed for many projects
2021-10-24 18:14:34 <ddevault> https://drewdevault.com/2021/08/06/goproxy-breaks-go.html
2021-10-24 18:32:26 <ikke> omni: ping
2021-10-24 18:39:55 <ddevault> I'm preparing a patch to submit to aports for further discussion
2021-10-24 18:44:40 <ikke> ddevault: did you also consider GOSUMDB then, which wouldo also be a 'phone home' option.
2021-10-24 18:45:35 <ddevault> yeah
2021-10-24 18:45:37 <ddevault> same story
2021-10-24 18:47:27 <PJ[m]> Your blog post doesn't make any sense
2021-10-24 18:48:00 <PJ[m]> > This cache never expires, which can cause some problems: you can keep fetching a module from proxy.golang.org long after the upstream version has disappeared.
2021-10-24 18:48:21 <PJ[m]> Other registries like NPM or Crates work like that as well
2021-10-24 18:48:29 <ikke> That's the whole point of the proxy
2021-10-24 18:48:31 <ddevault> the go proxy is not a registry
2021-10-24 18:48:39 <PJ[m]> It kinda is
2021-10-24 18:48:44 <ddevault> it kind of is not
2021-10-24 18:48:57 <ddevault> Go can fetch packages without phoning home, so we should configure it to
2021-10-24 18:49:11 <ddevault> and tbh just because the same problem applies to NPM et al does not mean it's not a problem
2021-10-24 18:49:21 <PJ[m]> lol
2021-10-24 18:50:40 <ikke> https://golang.org/ref/mod#go-mod-file-retract is a better way to restract versions though. It won't prevent projects from still using it, but it does warn about them
2021-10-24 18:51:01 <ddevault> agreed
2021-10-24 18:51:04 <ddevault> this still happens in the wild, though
2021-10-24 18:51:45 <ikke> go's rational is that code that built once should continue to build, no matter what upstream does
2021-10-24 18:51:51 <ikke> (whether that makes sense or not)
2021-10-24 18:55:34 <ikke> ddevault: wondering, without any proxy, wouldn't you receive even more traffic from people building go stuff?
2021-10-24 18:56:00 <ddevault> at sourcehut? probably not
2021-10-24 18:56:14 <ddevault> Google runs a crawler which fetches at regular intervals
2021-10-24 18:56:23 <ddevault> moreover, they have the whole proxy service loadbalanced, and each node has its own internal fetcher
2021-10-24 18:56:30 <ddevault> so the traffic from google is severely amplified
2021-10-24 18:56:35 <ikke> oh, that's anoying
2021-10-24 18:56:40 <ddevault> yeah, it's fucking awful
2021-10-24 18:56:46 <ddevault> not that they'll do anything about it any time soon
2021-10-24 18:57:05 <ddevault> I have half a mind to blackhole their shitty servers, but seeking to shut off GOPROXY in downstreams seems like a better solution for everyone
2021-10-24 18:58:13 <ddevault> oh, and when their crawler goes in, it fetches hundreds of packages back to back, which spikes the load a lot more than joe random running go build on his workstation
2021-10-24 18:58:29 <ikke> That's not a proxy then
2021-10-24 18:58:44 <ddevault> no, it's not
2021-10-24 18:58:48 <ddevault> it's a DDoS machine
2021-10-24 18:58:50 <psykose> "eager" proxy (lol)
2021-10-24 18:59:50 <ddevault> a full 14% of all git.sr.ht traffic goes to goproxy
2021-10-24 19:03:55 <ikke> I think if we were to make such a change, we need to make sure we have something in place to store modules on distfiles
2021-10-24 19:04:44 <ddevault> can you elaborate? I don't understand what you have in mind
2021-10-24 19:05:01 <ddevault> as in to ensure Alpine packages can build if the upstreams fuck up their deps?
2021-10-24 19:05:04 <ikke> right now, we keep a local copy of every fetched archive for stable releases
2021-10-24 19:05:05 <ikke> yes
2021-10-24 19:05:17 <ddevault> I think I would rather it break
2021-10-24 19:05:23 <ddevault> so that we are alerted to the problem and can address it
2021-10-24 19:05:45 <ddevault> we can always fetch that dep from proxy.golang.org if we need it urgently
2021-10-24 19:05:47 <ikke> If we can address it
2021-10-24 19:06:25 <ikke> Fixing mixing upstreams is already plenty of work now
2021-10-24 19:06:33 <ddevault> we could even set GOPROXY to the Google server for the builders so that any packages they build get cached up there
2021-10-24 19:06:50 <PJ[m]> What is the difference if package breaks randomly vs only during upgrade bump
2021-10-24 19:07:20 <ddevault> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26774
2021-10-24 19:08:16 <ikke> So we do already get 'alerted' twice per year about this for archives
2021-10-24 19:08:20 <ddevault> we could also fairly easily run our own goproxy for the builders which caches all of the upstreams by alpine release
2021-10-24 19:08:55 <omni> ikke: pong
2021-10-24 19:09:10 <ikke> omni: uutils-coreutils test suite is flaky
2021-10-24 19:09:37 <ikke> It fails with "No file descriptors available"
2021-10-24 19:10:55 <ikke> I already tried setting ulimit -n 2048, but that does not help
2021-10-24 19:11:21 <omni> ouch
2021-10-24 19:11:32 <PJ[m]> if the resources are available, then it's better to run own proxy/sumdb
2021-10-24 19:11:49 <ddevault> I would not recommend running one for end-users, just for the builders
2021-10-24 19:12:01 <ddevault> and even that tbh
2021-10-24 19:12:06 <ddevault> broken packages should break
2021-10-24 19:12:21 <ddevault> go is in community anyway
2021-10-24 19:13:08 <ikke> it's just anoying to do on a larger scale
2021-10-24 19:13:18 <ikke> If you just build your own package, you can easily spend time in fixing things
2021-10-24 19:13:39 <ikke> but if you rebuild the world because of a go security issue, dealing with mixing upstreams is just anoying
2021-10-24 19:13:49 <ddevault> annoying, yes, but I would prefer not to institutionalize bad practices
2021-10-24 19:13:54 <ikke> It should be fixed, but it's nice to be able to defer it
2021-10-24 19:14:02 <PJ[m]> so, you build package, it works fine, someone removes dependency, all Go packages are rebuilt due to Go upgrade, and now the package fails
2021-10-24 19:14:05 <PJ[m]> that's stupid
2021-10-24 19:14:05 <ddevault> and again, worst case, we can just grab it from proxy.golang.org like everyone else
2021-10-24 19:14:23 <omni> ikke: only on x86_64?
2021-10-24 19:14:34 <ikke> omni: It did fail on aarch64 as well before
2021-10-24 19:14:34 <ddevault> why is that stupid? if upstream vanishes for any other package then it causes issues for them too
2021-10-24 19:15:04 <PJ[m]> no, because the modules are cached
2021-10-24 19:15:35 <ddevault> I would rather not be running mystery code based on the faint memory of a package held by a cache on google's servers
2021-10-24 19:16:15 <ikke> ddevault: aren't the hashes in go.sum guaranteeing that you get the exact same code?
2021-10-24 19:16:24 <PJ[m]> yes they are
2021-10-24 19:16:25 <ddevault> yes, but a hash is not auditable or debuggable
2021-10-24 19:16:36 <PJ[m]> you can clone package from proxy
2021-10-24 19:16:39 <ddevault> I can't report a bug or send a patch upstream to a hash
2021-10-24 19:16:44 <PJ[m]> that's exactly what `go get` does 
2021-10-24 19:16:57 <ddevault> I'm well aware of how go get works
2021-10-24 19:16:59 <ikke> PJ[m]: for now
2021-10-24 19:17:09 <ikke> that functionality is deprecated
2021-10-24 19:17:26 <PJ[m]> installing packages via go get is deprecated
2021-10-24 19:17:43 <PJ[m]> go get for grabbing modules still stands at is is
2021-10-24 19:17:54 <PJ[m]> as it is*
2021-10-24 19:17:54 <ikke> "Building and installing packages with get is deprecated. In a future release, the -d flag will be enabled by default, and 'go get' will be only be used to adjust dependencies of the current module."
2021-10-24 19:18:17 <ddevault> ikke: PJ[m] is right and this is a tangental line of inquiry
2021-10-24 19:18:25 <ikke> it is
2021-10-24 19:18:25 <PJ[m]> that is what I said
2021-10-24 19:18:36 <ikke> "only adjust dependencies" implies "not download modules"
2021-10-24 19:18:46 <ddevault> it's just the label on the tin
2021-10-24 19:18:50 <ddevault> the contents of the tin are unchanged
2021-10-24 19:19:06 <PJ[m]> adjusting dependencies does download modules
2021-10-24 19:19:13 <PJ[m]> modules = deps
2021-10-24 19:19:20 <PJ[m]> many words, same meaning
2021-10-24 19:19:49 <bunny> the part that's deprecated is using it to build and install binaries and stuff, you just use go install for that now
2021-10-24 19:20:28 <PJ[m]> and even then go install doesn't work if go mod includes replacement directive 
2021-10-24 19:20:36 <PJ[m]> which annoys me so much
2021-10-24 19:21:12 <PJ[m]> going back to GOPROXY discussion, I would really like to not connect to Google servers (yay) but I also don't think disabling it completely is the correct action
2021-10-24 19:21:25 <ddevault> it just disables it by default. Quite easy to turn it back on
2021-10-24 19:21:40 <ddevault> s/opt-out/opt-in/
2021-10-24 19:22:18 <PJ[m]> What I would really like to see is proxy.golang.org alternative
2021-10-24 19:22:31 <PJ[m]> Maybe Eclipse could stir something up
2021-10-24 19:22:31 <ddevault> well, we'll soon be running one at godocs.io
2021-10-24 19:22:38 <ddevault> but I don't think this is a good idea
2021-10-24 19:23:09 <PJ[m]> I prefer something from someone who has power (read: money)
2021-10-24 19:23:29 <ddevault> godocs.io is operated by sourcehut, and we have a budget
2021-10-24 19:23:31 <ddevault> but why
2021-10-24 19:23:48 <omni> ikke: is it the same test that fail and it doesn't always fail?
2021-10-24 19:24:33 <ikke> omni: I believe it's always the same test
2021-10-24 19:25:02 <PJ[m]> why what
2021-10-24 19:25:14 <ddevault> why do you want someone with "power (read: money)" to operate it
2021-10-24 19:25:16 <ikke> omni: it has been failing consistently on x86_64
2021-10-24 19:25:41 <andypost[m]> omni: yes, exactly the same test and error
2021-10-24 19:26:06 <PJ[m]> because they have resources to do so at larger scale?
2021-10-24 19:26:21 <ddevault> what scale does it even need?
2021-10-24 19:26:28 <ddevault> godocs.io could easily cope with alpine's traffic
2021-10-24 19:26:33 <ddevault> but again, I don't think it's a good idea
2021-10-24 19:27:10 <PJ[m]> that's why I said that I would like to see an alternative
2021-10-24 19:27:21 <ddevault> you're not really making any sense to me
2021-10-24 19:27:29 <andypost[m]> jfrog has something
2021-10-24 19:28:03 <PJ[m]> I'll be as blunt as I can be, your little service is nothing, I'm talking about a replica of proxy.golang.org, 1:1, same scale, not Google 
2021-10-24 19:28:12 <PJ[m]> does that makes sense?
2021-10-24 19:28:21 <ddevault> lol
2021-10-24 19:28:38 <fluix> I think Drew has more issues with it than just the operator being Google
2021-10-24 19:28:38 <yyp> Looking forward to Microsoft setting up a Go proxy
2021-10-24 19:29:09 <PJ[m]> most likely won't happen, they are more interested in Rust
2021-10-24 19:29:29 <ddevault> my "little service" could easily handle all of alpine's go traffic, and probably all of linux's go traffic
2021-10-24 19:29:34 <ddevault> you can eat shit
2021-10-24 19:29:57 <ddevault> if you want another mothership to send your go traffic to, you can go find one
2021-10-24 19:29:59 <PJ[m]> will do 🙂
2021-10-24 19:30:05 <ikke> Please keep it civilizedf
2021-10-24 19:30:13 <ddevault> yeah, please do
2021-10-24 19:30:20 <yyp> PJ[m]: that was supposed to be a joke about "same scale", but yeah
2021-10-24 19:31:26 <PJ[m]> i mean, it would be nice if they did
2021-10-24 19:32:20 <yyp> You're exchanging one megacorp for another megacorp, nothing really changed
2021-10-24 19:34:21 <PJ[m]> comparing it that way, yes, nothing changed
2021-10-24 19:36:43 <yyp> How else should I compare them?
2021-10-24 19:49:55 <andypost[m]> ddevault: I'm using https://jfrog.com/open-source/ and to proxy docker/npm/composer
2021-10-24 19:50:26 <andypost[m]> it needs a bit of polishing but easy to tune
2021-10-24 19:50:58 <ddevault> is there a good reason to do this? I don't understand how this is useful/an improvement/not just another third-party to scoop up your data
2021-10-24 19:51:18 <ikke> You can run it locally
2021-10-24 19:51:47 <andypost[m]> I need to split private/public repos per developers/projects/ci
2021-10-24 19:52:22 <andypost[m]> also handy to manage releases
2021-10-24 19:56:06 <ikke> seems like 3.15 armhf finished
2021-10-24 19:56:15 <ikke> and aarch64 as well
2021-10-24 19:56:36 <omni> \o/
2021-10-24 19:58:36 <ddevault> >locally
2021-10-24 19:58:38 <ddevault> ah, that makes more sense
2021-10-24 19:59:30 <ddevault> I think there are already small independent GOPROXY server software packages, though
2021-10-24 19:59:34 <ddevault> which I would be more inclined to prefer
2021-10-24 19:59:49 <ddevault> that said, all of it is pretty dumb when you can just tell Go to fetch directly from the upstream source
2021-10-24 19:59:56 <ddevault> no need for a middleman at all
2021-10-24 19:59:57 <ikke> jfrog software is java based, which I'm not inclined to run
2021-10-24 20:07:34 <pj> yyp: for example, by what they do, how they do, etc.
2021-10-24 20:08:16 <yyp> What could a service with an identical interface and required functionality do differently?
2021-10-24 20:10:53 <ikke> sorry, aarch64 is not ready yet
2021-10-24 20:11:12 <pj> if you are comparing services, then nothing I guess, if you would compare megacorps though...
2021-10-24 20:15:37 <andypost[m]> omni: x86_64 passed now
2021-10-24 20:16:25 <omni> andypost[m]: without !26775 ?
2021-10-24 20:16:49 <ikke> tes
2021-10-24 20:16:52 <andypost[m]> yes) ikke just retried it few times
2021-10-24 20:17:05 <ikke> not for that specific reason, but yes :P
2021-10-24 20:17:29 <andypost[m]> and now ncurses broken on this builder too
2021-10-24 20:18:12 <ikke> The thread on ncurses received some replies
2021-10-24 20:18:40 <ikke> `https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00040.html
2021-10-24 20:24:04 <mps> ikke: there is yet another msg but still not on WEB interface ;)
2021-10-24 20:24:12 <ikke> ok
2021-10-24 20:24:33 <ikke> Anything concrete? I just saw a refernce to some release, but not sure what to do with that
2021-10-24 20:26:35 <mps> ikke: I asked him to post 'fix for this may be small :-)' (to quote him)
2021-10-24 20:27:01 <ikke> right, but that's just the empty path
2021-10-24 20:27:26 <ikke> But I guess you did not mention the search list issue we have on some arches
2021-10-24 20:28:43 <mps> patch just arrived in mailbox
2021-10-24 20:29:07 <ikke> ok
2021-10-24 20:29:29 <mps> it is for 6.3 but will try anyway
2021-10-24 20:30:24 <ikke> 6.3 too big of an upgrade, or not lts?
2021-10-24 20:32:30 <mps> 6.3 is next stable
2021-10-24 20:32:39 <ikke> ah ok
2021-10-24 20:32:44 <ikke> not yet released
2021-10-24 20:32:48 <mps> and 6.2 will not be developed
2021-10-24 20:33:25 <mps> 6.3 is released two days ago, but don't have 'proper' tarball for us yet
2021-10-24 20:33:37 <ikke> ok
2021-10-24 20:33:58 <ikke> and probably will require some rebuilds
2021-10-24 20:34:08 <mps> Thomass patch works but I've got 'ln: /home/mps/aports/main/ncurses/pkg/ncurses-dev/usr/lib/pkgconfig/ncurses.pc'
2021-10-24 20:34:33 <mps> ikke: I don't see anything about ABI changes
2021-10-24 20:34:46 <ikke> ok
2021-10-24 20:38:36 <andypost[m]> it was fast https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00044.html
2021-10-24 20:40:35 <mps> yes, if you don't have better things to work you can try patch posted there
2021-10-24 20:41:17 <mps> because I'm not sure I will finish all tests, and want to go earlier to bed (at least on sundays)
2021-10-24 20:41:53 <mps> else, I would do this in morning tomorrow
2021-10-24 20:42:30 <andypost[m]> yep, I will update MR soon
2021-10-24 20:46:01 <mps> andypost[m]: thanks. I'm preparing for bed now. good night
2021-10-24 20:49:44 <ikke> andypost[m]: i'm going to sleep soon as well, but if you get something, I can merge it
2021-10-24 20:50:43 <andypost[m]> I just back home, need sometime
2021-10-24 20:51:37 <andypost[m]> ikke: mps: pkgconf-dev or gmp-dev) ?
2021-10-24 20:51:49 <ikke> andypost[m]: it should not need to depend on either
2021-10-24 20:51:52 <mps> andypost[m]: no one is needed
2021-10-24 20:52:19 <ikke> the only reason it helped because it made sure /var/lib/pkgconfig existed
2021-10-24 20:52:35 <mps> but .pc files is moved in pkg/ncurses and will need fix in dev()
2021-10-24 20:54:00 <psykose> would there be an issue with creating a font- package using a .ttc instead of many .ttf's on the same subpackage? afaik fontconfig handles the former fine, or at least i've never had something that didn't work with ttc
2021-10-24 20:55:13 <ikke> andypost[m]: no need to hurry, probably someone else can merge it as well
2021-10-24 20:57:40 <andypost[m]> ikke: it still fails in CI https://gitlab.alpinelinux.org/alpine/aports/-/jobs/521199
2021-10-24 20:58:47 <ikke> andypost[m]: can you check if that file is located somewhere else?
2021-10-24 20:59:47 <mps> but .pc files is moved in pkg/ncurses and will need fix in dev()
2021-10-24 20:59:55 <ikke> configure: WARNING: no PKG_CONFIG_LIBDIR was found
2021-10-24 21:00:08 <ikke> I suppose because that directory is not present, it will now not install any pc files at all
2021-10-24 21:00:25 <mps> andypost[m]: add this back ' --with-pkg-config-libdir="/usr/lib/pkgconfig" \'
2021-10-24 21:00:56 <andypost[m]> it's strange because it passes locally but not in CI
2021-10-24 21:00:59 <mps> (will I sleep this night :) )
2021-10-24 21:01:15 <ikke> andypost[m]: do you have /var/lib/pkgconfig locally?
2021-10-24 21:02:10 <mps> andypost[m]: https://tpaste.us/KM9w
2021-10-24 21:02:24 <andypost[m]> ikke: no
2021-10-24 21:02:31 <ikke> sorry, /usr/lib/pkgconfig
2021-10-24 21:02:37 <mps> but this need fix in dev() function
2021-10-24 21:05:22 <andypost[m]> yep, commented out and pushed - still can't reproduce locally
2021-10-24 21:05:25 <ikke> andypost[m]: what does the relevant configure output show for you locally?
2021-10-24 21:07:09 <andypost[m]> https://tpaste.us/ovEM
2021-10-24 21:07:23 <mps> ikke: with diff I posted above dev() function must be rewritten to move .pc files
2021-10-24 21:07:48 <ikke> mps: I suppose because ncurses doesn't do it itself anymore?
2021-10-24 21:07:50 <mps> that's all what is missing, I think
2021-10-24 21:08:00 <mps> ikke: I think so
2021-10-24 21:08:34 <ikke> strange why this changed
2021-10-24 21:09:01 <ikke> My expectation is that if you say that the directory is X, it should just use X and put files there
2021-10-24 21:09:20 <andypost[m]> ikke: and https://tpaste.us/jNRe
2021-10-24 21:09:53 <mps> maybe add '--with-pkg-config-libdir' to ./configure
2021-10-24 21:09:54 <andypost[m]> finally green https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/97664
2021-10-24 21:10:19 <ikke> andypost[m]: so it seems you do have /usr/lib/pkgconfig on your system
2021-10-24 21:10:22 <ikke> that's why it passes
2021-10-24 21:10:52 <mps> oh no, it is already there
2021-10-24 21:11:06 <andypost[m]> ikke: I'm using fresh docker container and there's no this dir
2021-10-24 21:11:11 <ikke> hmm
2021-10-24 21:11:16 <ikke> strange
2021-10-24 21:11:33 <andypost[m]> yep, autoconf magic
2021-10-24 21:11:35 <ikke> Note: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/521215#L3128
2021-10-24 21:11:55 <ikke> no pkgconfig files are present anymore
2021-10-24 21:12:27 <andypost[m]> oh they are in ncurses itself
2021-10-24 21:12:54 <ikke> yes
2021-10-24 21:13:03 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/521215#L3128
2021-10-24 21:14:15 <andypost[m]> and there's broken link "https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/97664"
2021-10-24 21:14:34 <andypost[m]> "ncurses++.pc -> ncurses++w.pc"
2021-10-24 21:18:08 <mps> hmm, sorry, good night (now really)
2021-10-24 21:18:09 <ikke> I wanted to investigate how this search list was determined, but didn't get that far yet
2021-10-24 21:18:12 <ikke> o/
2021-10-24 21:20:21 <mps> https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00048.html
2021-10-24 21:20:35 <mps> just looked inbox
2021-10-24 21:25:11 <andypost[m]> mps: ikke: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26761/diffs?diff_id=192340&start_sha=021fcbdd18177b8e3ee07b9b93b91b8897e8ea0e working locally - waiting CI
2021-10-24 21:33:15 <andypost[m]> the last issue is that "default_dev" does not move .pc files
2021-10-24 21:47:41 <andypost[m]> because files created in srcdir(
2021-10-24 21:57:07 <andypost[m]> anyway I find it ready
2021-10-25 05:20:55 <ikke> go is failing on armhf (3.15): https://tpaste.us/xnR1 
2021-10-25 05:20:58 <ikke> test failure
2021-10-25 05:38:20 <ikke> https://github.com/golang/go/issues/19381
2021-10-25 07:13:58 <ncopa> good morning
2021-10-25 07:15:39 <mps> good morning
2021-10-25 07:16:40 <mps> ikke: andypost[m]: I see that jirutka fixed ncurses in somewhat hackish way, by keeping pkgconf-dev in makedepends
2021-10-25 07:16:58 <bratkartoffel> ikke: i've updated !26354 and split the change into multiple commits, can you please review and merge this? thanks!
2021-10-25 07:17:47 <mps> just tested build of the ncurses-6.3-20211021 and it also works with this workaround
2021-10-25 07:19:12 <mps> I'm thinking to merge this for now, and talk later again with upstream to find proper solution. what you thinks about this?
2021-10-25 07:19:16 <Ariadne> i really don't like this pkgconf-dev business
2021-10-25 07:19:32 <ikke> Ariadne: yes, it's not the solution
2021-10-25 07:19:39 <Ariadne> the build system should unconditionally install .pc files to $libdir/pkgconfig
2021-10-25 07:19:40 <mps> Ariadne: I agree, and upstream is willing to fix it
2021-10-25 07:19:45 <ikke> Ariadne: it's just a coincidence why it works
2021-10-25 07:19:53 <Ariadne> that is all that needs to be done
2021-10-25 07:20:04 <ikke> Ariadne: Yes, I agree
2021-10-25 07:20:08 <ikke> that was my assesment was well
2021-10-25 07:20:34 <ikke> It tries to do some autodiscovery depending on whether that path exists and ignores explicit configuration
2021-10-25 07:21:20 <Ariadne> okay, well
2021-10-25 07:21:36 <Ariadne> with my pkgconf maintainer hat on, i should state that i intend to break that functionality
2021-10-25 07:22:03 <mps> which one
2021-10-25 07:22:12 <Ariadne> whatever one the ncurses configure script is doing
2021-10-25 07:22:45 <ikke> Ariadne: I also noticed some inconsistency between builders, not sure if it's pkgconf related or not. On some builders, it includes /usr/local/lib/pkgconfig in the paths that were part of the search list
2021-10-25 07:23:08 <Ariadne> the search list is defined in the pkgconf APKBUILD.
2021-10-25 07:23:33 <mps> ikke: I think that was because I removed --with-pkg-config-libdir=/usr/lib/pkgconfig
2021-10-25 07:23:51 <ikke> mps: even with that set it would not take it
2021-10-25 07:24:15 <mps> ikke: right, not in current build
2021-10-25 07:24:52 <mps> but with patch Thomas posted last night it will not use /usr/local
2021-10-25 07:25:12 <Ariadne> why
2021-10-25 07:25:14 <Ariadne> can't it
2021-10-25 07:25:20 <Ariadne> just do what EVERY OTHER PACKAGE does on the planet
2021-10-25 07:25:29 <Ariadne> and install to $sysroot/$prefix/$libdir/pkgconfig/foo.pc
2021-10-25 07:25:41 <Ariadne> why, why, why
2021-10-25 07:25:52 <mps> bugs happens
2021-10-25 07:26:00 <Ariadne> my name is thomas dickey, and this is jackass
2021-10-25 07:26:20 <Ariadne> bugs happen???
2021-10-25 07:26:29 <Ariadne> you have to go out of your way to make it do this
2021-10-25 07:26:49 <mps> hmm, could you calm down please
2021-10-25 07:26:54 <Ariadne> this means that mr. dickey had a cogent thought, "hey! i know, i'll ask pkgconf where to install the .pc files, it will be so cute"
2021-10-25 07:27:15 <Ariadne> and this is not a thought anyone should have
2021-10-25 07:30:32 <mps> Thomas is kind and responsive and always ready to help and fix issues
2021-10-25 07:31:02 <Ariadne> great, that still creates a problem for *me*
2021-10-25 07:31:23 <Ariadne> because it is more *bullshit* that i am going to have to "fix" in pkgconf
2021-10-25 07:32:25 <Ariadne> stop trying to make "smart" tools, make dumb ones instead
2021-10-25 07:32:39 <Ariadne> and why is ncurses not maintained in git or whatever
2021-10-25 07:32:55 <mps> :)
2021-10-25 07:32:57 <psykose> well, git is a "smart" tool :p
2021-10-25 07:33:44 <Ariadne> like 50% of pkgconf
2021-10-25 07:33:47 <Ariadne> is basically mitigations
2021-10-25 07:33:50 <Ariadne> for upstream idiocy
2021-10-25 07:33:59 <Ariadne> and that number is only growing
2021-10-25 07:35:13 <mps> imo upstreams have the rights to do whatever they want
2021-10-25 07:35:35 <Ariadne> yes, and guess what, i am an upstream too
2021-10-25 07:35:54 <Ariadne> was i consulted when he decided to write this nonsense in ncurses configure?
2021-10-25 07:35:56 <Ariadne> nope
2021-10-25 07:36:14 <mps> :)
2021-10-25 07:36:19 <Ariadne> had i been, i would have said, "just install it to $prefix/$libdir/pkgconfig like everyone else, and do not try to be smart"
2021-10-25 07:39:25 <Ariadne> how to fix this correctly
2021-10-25 07:39:27 <Ariadne> just remove
2021-10-25 07:39:31 <Ariadne> CF_WITH_PKG_CONFIG_DIR
2021-10-25 07:39:33 <Ariadne> from configure.in
2021-10-25 07:39:35 <Ariadne> kill it, with fire
2021-10-25 07:39:44 <Ariadne> it literally
2021-10-25 07:39:57 <Ariadne> tries to parse the --debug output of pkg-config and pkgconf
2021-10-25 07:40:15 <Ariadne> this is NOT a stable interface, it is ABSOLUTELY subject to change whenever the hell i fucking feel like it
2021-10-25 07:40:31 <Ariadne> i don't care anymore
2021-10-25 07:40:34 <Ariadne> we are switching to netbsd curses
2021-10-25 07:40:38 <Ariadne> i do not give two shits
2021-10-25 07:40:41 <Ariadne> how many bugs it introduces
2021-10-25 07:40:49 <Ariadne> i will fix them all, in a rage of spite-driven development
2021-10-25 07:41:35 <alandiwix> after the latest upgrade sway refuses to start due to libseat being unable to connect to seatd socket (permission denied), unless I add my user to seat group. Is it supposed to work like that?
2021-10-25 07:42:14 <donoban> alandiwix: it happened to me some days ago, I needed to restore suid on something (maybe sway binary?), let me check
2021-10-25 07:42:31 <donoban> ah well if you have seatd running better to add you to seat group
2021-10-25 07:42:37 <psykose> you do need to be in seat group yeah
2021-10-25 07:42:49 <alandiwix> ok, thanks
2021-10-25 08:03:11 <Ariadne> hmm, "innovation happened" or "innovation™️ happened"
2021-10-25 08:17:47 <PureTryOut> fcolista: the package webalizer fails because it seems their website and their source hosting is down
2021-10-25 08:19:40 <Ariadne> mps: please direct thomas to this helpful documentation: https://ariadne.space/2021/10/25/dont-do-clever-things-in-configure-scripts/
2021-10-25 08:24:01 <Ariadne> (also that comment about pkgconf optionally ignoring $PKG_CONFIG_LIBDIR like it is a bad thing is just ignorant, it has to be possible to ignore it for some situations involving sysroot)
2021-10-25 08:28:07 <mps> Ariadne: I think you would better explain this to him than me
2021-10-25 08:28:23 <Ariadne> i do not want to talk to him because i might literally have an aneurysm if i do
2021-10-25 08:28:36 <mps> :D
2021-10-25 08:29:01 <Ariadne> his innovation, my multi-year nightmare
2021-10-25 08:30:07 <mps> iirc this was posted from someone else on mailing list and not his innovation. his mistake is that he accepted this
2021-10-25 08:39:28 <Ariadne> its his now
2021-10-25 08:41:25 <Ariadne> the buck always stops with the maintainer
2021-10-25 09:08:22 <piraty> ncurses needs to go
2021-10-25 09:08:28 <piraty> years ago
2021-10-25 09:08:48 <PureTryOut> is there not a notcurses replacement thing?
2021-10-25 09:08:55 <piraty> there is
2021-10-25 09:09:05 <piraty> not drop-in though
2021-10-25 09:09:05 <PureTryOut> I suppose it's not a drop-in replacement?
2021-10-25 09:09:08 <PureTryOut> ah ok
2021-10-25 09:09:09 <PureTryOut> too bad
2021-10-25 09:09:20 <Ariadne> somebody could write one
2021-10-25 09:09:29 <piraty> Cogitri[m]: i assume gnome-authenticator requires a rebuild after recent glib bump
2021-10-25 09:09:39 <piraty> 
ACTION looks at somebody

2021-10-25 09:09:41 <Ariadne> but, really, the curses API is awful
2021-10-25 09:11:05 <ncopa> good morning
2021-10-25 09:11:25 <ncopa> shouldn't have bumped the pkgrel? 69ef197ad93e104b25de6e2a89ca52324c2bc719
2021-10-25 09:12:40 <Ariadne> yes
2021-10-25 09:12:43 <Ariadne> needs pkgrel bump
2021-10-25 09:12:49 <Ariadne> but upstream needs clue-by-four
2021-10-25 09:12:54 <Ariadne> like i said, at this point
2021-10-25 09:13:02 <Ariadne> i do not care what is wrong with netbsd-curses
2021-10-25 09:13:06 <Ariadne> i will *personally* fix it
2021-10-25 09:15:42 <ncopa> i think its not first time ncurses do "weird" things in configure script
2021-10-25 09:17:37 <Ariadne> seriously though, netbsd-curses
2021-10-25 09:17:39 <Ariadne> smaller
2021-10-25 09:17:41 <Ariadne> simpler
2021-10-25 09:17:55 <Ariadne> upstream does not do weird things in configure
2021-10-25 09:17:59 <Ariadne> im just saying
2021-10-25 09:29:20 <Newbyte> what determines whether a package has a -dbg subpackage? 
2021-10-25 09:29:37 <Ariadne> if the maintainer added it
2021-10-25 09:29:40 <Ariadne> thats it
2021-10-25 09:29:42 <Ariadne> seriously
2021-10-25 09:31:06 <Newbyte> thank you
2021-10-25 09:31:32 <Newbyte> so I just add `$pkgname-dbg` to subpackages?
2021-10-25 09:31:44 <ncopa> yup. add it first
2021-10-25 09:31:55 <ncopa> we add -dbg packages when needed
2021-10-25 09:32:00 <ncopa> or requested
2021-10-25 09:32:01 <Ariadne> i'm quite serious
2021-10-25 09:32:04 <Ariadne> about netbsd-curses
2021-10-25 09:32:18 <ncopa> i believe you, and i dont disagree :)
2021-10-25 09:32:50 <ncopa> im just not convinved its worth it
2021-10-25 09:33:10 <ncopa> s/convinved/convinced/
2021-10-25 09:34:08 <ncopa> mps: i wonder if 6d4129d6abeb1b74626c1bbb30a436da517a261a should be reverted due to 69ef197ad93e104b25de6e2a89ca52324c2bc719
2021-10-25 09:34:23 <Ariadne> though really the problem is that mps removed --with-pkg-config-libdir to begin with
2021-10-25 09:34:30 <Ariadne> anyone who knows pkg-config would know that is a bad idea
2021-10-25 09:34:53 <Ariadne> you do *not* want automagic detection of anything related to pkg-config, because it will prefer stuff like /usr/local
2021-10-25 09:36:15 <Ariadne> after all, pkgconf would check there first
2021-10-25 09:36:27 <ikke> Ariadne: mps removed it because CI failed because the dir did not exist and before it was clear what the actual issue was
2021-10-25 09:36:38 <ncopa> yeah, relying on automatic detection for was clearly not a good idea
2021-10-25 09:36:53 <Ariadne> ikke: maybe the CI failing
2021-10-25 09:36:59 <Ariadne> ikke: should have been a sign to stop
2021-10-25 09:37:03 <ikke> :)
2021-10-25 09:37:13 <ikke> mps had the idea CI / builders were faulty
2021-10-25 09:37:27 <Ariadne> then you reproduce using rootbld
2021-10-25 09:37:27 <ikke> Later I made it clear to him it was because his local environment was not clean
2021-10-25 09:38:04 <Ariadne> the real fix would have been, and still is, to rip all of that macro out
2021-10-25 09:38:10 <Ariadne> and just default to $libdir/pkgconfig
2021-10-25 09:38:17 <ikke> yes, I agree
2021-10-25 09:38:35 <Ariadne> but innovation is important
2021-10-25 09:38:53 <Ariadne> somebody might try to compile ncurses on a slackware 8.0 system
2021-10-25 09:39:03 <Ariadne> which uses $libdir/pkg-config instead of $libdir/pkgconfig
2021-10-25 09:39:05 <Ariadne> have to check
2021-10-25 09:39:07 <Ariadne> ;)
2021-10-25 09:39:07 <ikke> It's called autoconf™ for a reason :P
2021-10-25 09:39:14 <Ariadne> autopain
2021-10-25 09:48:20 <mps> ncopa: current ncurses are fixed by jirutka
2021-10-25 09:48:47 <mps> with hack yes, but builders are not blocked
2021-10-25 09:49:24 <mps> I will later today try to fix it with 6.3 release
2021-10-25 09:52:58 <mps> with patch upstream posted last night build works but .pc files are put in wrong dir
2021-10-25 09:54:28 <ikke> yes, because of the incorrect auto discovery logic
2021-10-25 09:56:02 <mps> and I don't like to do anything in 'rush manner', but it will be fixed
2021-10-25 09:57:18 <mps> ikke: if I checkout one of stable branches in aports will the rootbld use deps and tools from that branch
2021-10-25 09:57:27 <fcolista> PureTryOut, yes
2021-10-25 10:05:33 <Ariadne> mps: do not use the auto detection
2021-10-25 10:06:11 <Ariadne> mps: by design, it will use /usr/local/lib/pkgconfig, because that is first on the search path.
2021-10-25 10:06:37 <Ariadne> mps: just specify it directly.  its the best way.
2021-10-25 10:08:48 <mps> Ariadne: I know
2021-10-25 10:09:05 <Ariadne> and kill this pkgconf-dev dep
2021-10-25 10:09:25 <mps> but as you know 'we' (alpine) prefers if upstream fixes packages
2021-10-25 10:09:28 <Ariadne> and, seriously, hammer on upstream with the blog i wrote until he ditches this automatic crap
2021-10-25 10:09:50 <Ariadne> alpine also prefers if upstream is sane
2021-10-25 10:09:55 <mps> sorry but I don't like to 'hammer' anyone
2021-10-25 10:10:22 <Ariadne> this automatic detection is wrong for distros
2021-10-25 10:10:32 <Ariadne> it is appropriate for an end user, though
2021-10-25 10:10:33 <mps> sure is is
2021-10-25 10:10:45 <mps> ohm
2021-10-25 10:10:51 <mps> yes, agree
2021-10-25 10:11:13 <Ariadne> but even for an end user, if it just defaulted to $libdir/pkgconfig
2021-10-25 10:11:16 <Ariadne> it would be fine
2021-10-25 10:12:22 <mps> it should follow whatever is defined in --with-pkg-config-libdir
2021-10-25 10:12:52 <Ariadne> anyway, he should stop scraping debug output
2021-10-25 10:12:58 <Ariadne> before i decide to change it
2021-10-25 10:13:01 <Ariadne> just to ruin his day
2021-10-25 10:15:14 <mps> Ariadne: here is ML thread https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00048.html (though my last msg is not yet in web ui)
2021-10-25 10:22:18 <Ariadne> mps: how does one subscribe to this ML?
2021-10-25 10:23:27 <mps> let me check
2021-10-25 10:24:07 <Ariadne> i figured it out
2021-10-25 10:25:39 <mps> To: bug-ncurses-request@gnu.org
2021-10-25 10:25:55 <mps> Subject: subscribe to ncurses
2021-10-25 10:26:30 <mps> subscribe mail@dom.ain
2021-10-25 10:41:24 <ncopa> ikke: are you working on go for build-3-15-armhf?
2021-10-25 10:41:50 <ikke> yes
2021-10-25 10:45:18 <ikke> ncopa: one test is failing, probably because it's slower (timeout)
2021-10-25 10:45:35 <ikke> ncopa: apparently GO_TEST_TIMEOUT_SCALE=2 makes it pass
2021-10-25 11:14:00 <ikke> ncopa: go has been bootstrapped now
2021-10-25 11:35:30 <Ariadne> mps: i have sent a gentle email to the ncurses list asking for a rethink on this
2021-10-25 11:49:23 <skarnet> Ariadne on social media: <angry dog>  Ariadne on mailing-lists: <Cheems>
2021-10-25 11:49:43 <Ariadne> no
2021-10-25 11:49:48 <Ariadne> first of all, i am never a dog
2021-10-25 11:50:09 <Ariadne> i am just annoyed when i have other people's technical debt handed to me
2021-10-25 11:50:11 <skarnet> in memes, you can
2021-10-25 11:50:49 <skarnet> and yeah I totally understand where you're coming from and I also get super angry when people break my stuff because they're stupid
2021-10-25 11:51:24 <skarnet> it's just that I find the discrepancy funny between the places where you police your own tone and the places where you don't :D
2021-10-25 11:51:51 <Ariadne> i police my own tone when i feel like it will be helpful, yes
2021-10-25 11:52:03 <Ariadne> i think that is typical of most people though
2021-10-25 11:52:15 <skarnet> it is, but it is very visible with you
2021-10-25 11:57:42 <Ariadne> oh, my trick is that i wait for a while before engaging with stupid
2021-10-25 12:19:28 <mps> Ariadne: your msg to ncusrs ML still not arrived in my inbox
2021-10-25 12:19:43 <Ariadne> yeah i think
2021-10-25 12:19:48 <Ariadne> gnu mailing list server
2021-10-25 12:19:50 <Ariadne> is FUBAR
2021-10-25 12:20:08 <mps> probably some checking for first message
2021-10-25 12:22:36 <Ariadne> no, it took like 37 minutes
2021-10-25 12:22:45 <Ariadne> for my confirmation email to arrive
2021-10-25 12:22:54 <Ariadne> i think it is just a really slow mail server
2021-10-25 12:22:56 <Ariadne> :P
2021-10-25 12:23:25 <Ariadne> no
2021-10-25 12:39:12 <nero> gnu ML are moderated, tone needs to stay professional
2021-10-25 12:41:25 <skarnet> you can say all the moronic bullshit you want, you just need to be courteous when saying it
2021-10-25 12:44:45 <ericonr> Ariadne: netbsd-curses lacks mouse support, which might be sad for some users :P
2021-10-25 12:46:52 <skarnet> > text interface
2021-10-25 12:46:55 <skarnet> > mouse support
2021-10-25 12:48:41 <nero> usecase: exit htop when terminal emulator uses F10 to open its own menu
2021-10-25 12:49:19 <mercenary> ericonr: I would see that as a positive thing
2021-10-25 12:50:04 <ericonr> I think most people would, just saying *some* might not :P
2021-10-25 12:53:51 <skarnet> nero: q
2021-10-25 12:54:58 <Ariadne> oh ffs
2021-10-25 12:55:56 <psykose> afaik you need mouse support to scroll with a mouse
2021-10-25 12:57:43 <nero> the mouse scoll is implemented in the terminal emulator
2021-10-25 12:59:47 <ericonr> physically scrolling up a curses application is basically useless
2021-10-25 12:59:55 <Ariadne> no
2021-10-25 12:59:59 <Ariadne> the terminal emulator
2021-10-25 13:00:05 <Ariadne> converts scroll events
2021-10-25 13:00:08 <Ariadne> into pagedown/pageup
2021-10-25 13:00:13 <Ariadne> usually
2021-10-25 13:00:21 <ericonr> hm, I see. would 
2021-10-25 13:00:36 <psykose> nero: ah, that makes sense, i assume then it just emits the equivalent up/down movement
2021-10-25 13:00:38 <ericonr> s/lemme check how weechat does with netbsd curses/
2021-10-25 13:00:58 <ericonr> well that substitution makes no sense
2021-10-25 13:02:26 <Ariadne> nonetheless
2021-10-25 13:02:33 <Ariadne> scraping pkg-config debug output
2021-10-25 13:02:35 <Ariadne> is insane
2021-10-25 13:02:50 <Ariadne> i really hope thomas rethinks this
2021-10-25 13:03:07 <Ariadne> because, that is like the exact opposite of what he should be doing
2021-10-25 13:03:12 <ericonr> Ariadne: never doubted you there for a sec :P
2021-10-25 13:04:22 <Ariadne> to be clear, the pkgconf debug output
2021-10-25 13:04:26 <Ariadne> is subject to change
2021-10-25 13:04:33 <Ariadne> whenever i feel like changing it
2021-10-25 13:04:46 <Ariadne> i am pretty certain it is the same in other implementations
2021-10-25 13:04:55 <ericonr> hm wtf
2021-10-25 13:05:03 <nero> i think nobody questioned that
2021-10-25 13:05:05 <ericonr> mouse clicking is working in weechat built with netbsd-curses
2021-10-25 13:05:17 <Ariadne> yes it has some mouse support now
2021-10-25 13:05:19 <ericonr> I no longer know what's going on
2021-10-25 13:05:20 <Ariadne> i think
2021-10-25 13:05:21 <ericonr> ooh
2021-10-25 13:05:30 <Ariadne> but the sabotage fork lacks it
2021-10-25 13:05:47 <Ariadne> any proposal to switch to netbsd curses would be to switch to netbsd curses, not the sabotage fork
2021-10-25 13:06:28 <ericonr> but I'm using the sabotage fork >.>
2021-10-25 13:07:00 <Ariadne> who knows then
2021-10-25 13:07:06 <Ariadne> maybe it supports mice now
2021-10-25 13:07:46 <Ariadne> i mean, simply switching to netbsd-curses does not rid ourselves of code written by this person though
2021-10-25 13:07:52 <Ariadne> for that, we will need to get rid of xterm
2021-10-25 13:11:25 <Ariadne> i can dream, though
2021-10-25 13:12:57 <Ariadne> mps: anyway what i sent was https://tpaste.us/yprp
2021-10-25 13:13:11 <Ariadne> i’m sure the gnu mail server will send it out sometime soon
2021-10-25 13:19:15 <mps> Ariadne: yes, probably will arrive when someone 'confirm' your subscription
2021-10-25 13:20:13 <mps> and text is written with 'acceptable' language (to my eyes not well versed in english)
2021-10-25 13:22:10 <markand> can we have time to discuss and formalize my last comment: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22933#note_184147
2021-10-25 13:24:46 <eris[m]> written by which person
2021-10-25 13:25:32 <psykose> i believe the other day someone sent a patch to change newapkbuild output to use abuild-meson instead of just meson
2021-10-25 13:25:39 <psykose> it was just an oversight as far as i believe
2021-10-25 13:26:01 <Ariadne> yes, but we really need a developer manual
2021-10-25 13:26:02 <psykose> aside from that, all the other options are indeed set by abuild-meson so you can accept the change
2021-10-25 13:26:17 <psykose> that we do
2021-10-25 13:47:20 <ddevault> would anyone here happen to know where the default limits are assigned should they not appear in limits.conf?
2021-10-25 13:49:11 <psykose> afaik cat /proc/1/limits shows you the defaults as they come from kernel
2021-10-25 13:49:56 <ddevault> yep, thanks
2021-10-25 13:49:58 <ddevault> just found that myself
2021-10-25 13:59:14 <skarnet> that's not quite accurate, pid 1 could adjust the limits before it starts spawning other processes
2021-10-25 13:59:30 <skarnet> but in most cases that will work
2021-10-25 14:01:35 <ddevault> I wanted to find where the buck stops
2021-10-25 17:49:11 <mps> andypost[m]: what do you mean by compatible #13119
2021-10-25 17:49:55 <mps> iotop-c is not made as replacement for iotop (old one)
2021-10-25 17:50:50 <mps> if you install iotop-c it will replace iotop
2021-10-25 17:51:25 <mps> that is only 'compatibility' I'm aware of
2021-10-25 17:55:46 <andypost[m]> mps: I mean command line arguments ans output, to said it replacement
2021-10-25 17:56:33 <mps> andypost[m]: I don't know, didn't used much old one, just few times
2021-10-25 17:57:28 <andypost[m]> Sane to me) just not sure how to deal with abandoned sources
2021-10-25 17:57:44 <ikke> is it abandoned? Seems like hosting had an issue
2021-10-25 17:58:15 <ikke> 500 server error
2021-10-25 17:58:21 <andypost[m]> Host and not clear where src now
2021-10-25 17:58:52 <ikke> Source is at repo.or.cz, but no nice archives there
2021-10-25 17:59:17 <ikke> https://repo.or.cz/iotop.git
2021-10-25 18:00:15 <ikke> https://web.archive.org/web/20210820081054/http://guichaz.free.fr/iotop/
2021-10-25 18:00:37 <ikke> fwi, we still have the archive at distfiles
2021-10-25 18:03:41 <andypost[m]> Yep, and looks should continue to use it
2021-10-25 18:04:35 <ikke> I already moved it in place, but someone disabled it already
2021-10-25 18:05:21 <ikke> https://distfiles.alpinelinux.org/distfiles/v3.15/iotop-0.6.tar.bz2
2021-10-25 18:55:27 <andypost[m]> Cogitri: please review !26755 it blcoks 3.15 builders as I can't fix build of current version
2021-10-25 18:58:52 <Cogitri[m]> andypost: well if all deps have been rebuild and still run properly then it’s fine by me
2021-10-25 19:02:51 <andypost[m]> I did a quick check and can't find bugs
2021-10-25 19:07:38 <ikke> Then LGTM
2021-10-25 19:15:09 <Cogitri[m]> 👍
2021-10-25 19:21:22 <ikke> I think gitg has to do with glib
2021-10-25 19:28:44 <Cogitri[m]> No, probably due to a meson upgrade
2021-10-25 19:28:50 <ikke> oh, ok
2021-10-25 19:28:55 <Cogitri[m]> > data/meson.build:8:5: ERROR: Function does not take positional arguments.
2021-10-25 19:30:26 <Cogitri[m]> Putting input: in front of the variable might fix it
2021-10-25 19:31:48 <ikke> There is already a named input: argument
2021-10-25 19:31:55 <ikke> the first argument is called 'desktop'
2021-10-25 19:36:55 <mps> ikke: andypost[m]: ncopa: https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00052.html
2021-10-25 19:37:45 <Cogitri[m]> ikke: Oh right. Huh I wonder what that positional argument is for then. At least in modern meson I suppose just removing that line should be fine and fix the build
2021-10-25 19:38:26 <ikke> Cogitri[m]: yeah, I'm looking at the history of merge_file, but cannot find where it was actually used for
2021-10-25 19:41:41 <ikke> Cogitri[m]: seems to build
2021-10-25 19:50:02 <Cogitri[m]> Neat, good to merge then
2021-10-25 19:50:59 <ikke> 👍
2021-10-25 19:55:31 <ikke> Cogitri[m]: There is still a test failure
2021-10-25 19:55:37 <ikke> which is what got me thinking it was glib related
2021-10-25 19:55:40 <ikke> but not sure
2021-10-25 19:55:51 <ikke> the output is a bit confusing to me
2021-10-25 19:57:28 <Cogitri[m]> > Bail out! GLib-FATAL-CRITICAL: g_date_time_format: assertion 'datetime != NULL' failed
2021-10-25 19:57:28 <Cogitri[m]> Is the bit that makes the tests fail I guess 
2021-10-25 19:57:41 <Cogitri[m]> Doesn’t seem like a GLib bug but more like a missing check for NULL
2021-10-25 20:28:42 <Hello71> smells more like it's upset about missing TZ
2021-10-25 20:29:14 <ikke> Cogitri[m]: Yes, that was my guess as well
2021-10-25 20:35:29 <mps> https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00053.html
2021-10-25 21:36:01 <andypost[m]> mps: so another upgrade required?
2021-10-25 21:40:21 <andypost[m]> I think Cogitri is ok with upgrade if armhf will pass !26812
2021-10-25 21:40:44 <mps> andypost[m]: yes, I have ncurses-6.3-20211021 with a patch
2021-10-25 21:41:50 <mps> but don't want to post it till all this 'bad things' about ncurses are settled
2021-10-25 22:30:07 <andypost[m]> Looks meson update caused more errors like "data/meson.build:2:5: ERROR: Function does not take positional arguments."
2021-10-25 23:04:40 <Ariadne> i’ll settle it by replacing it with netbsd-curses
2021-10-25 23:25:01 <andypost[m]> Ariadne: for 3.15 it looks too cruel 
2021-10-25 23:25:20 <Ariadne> i don't think it is realistic anyway
2021-10-25 23:25:34 <Ariadne> forking ncurses is though
2021-10-26 02:08:09 <andypost[m]> filed #13135 as all gnome aports fails to build with 0.60
2021-10-26 02:13:07 <anjan> can someone please review this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26607
2021-10-26 09:07:37 <ncopa> good morning
2021-10-26 09:12:03 <mps> good morning
2021-10-26 09:15:34 <Cogitri[m]> Morning
2021-10-26 09:19:57 <ikke> good morning
2021-10-26 09:22:58 <mps> ncurses, https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00055.html
2021-10-26 10:41:08 <Ariadne> still annoyed
2021-10-26 10:41:54 <Ariadne> but i’m annoyed because of the fact that he decided my debug output was stable interface to use for his needs
2021-10-26 11:24:41 <markand> anyone for !25793 and !26120 ?
2021-10-26 13:35:43 <ikke> andypost[m]: https://www.openwall.com/lists/oss-security/2021/10/26/7
2021-10-26 13:59:00 <alandiwix> Is it me or qt5-qtwebengine compiled without pulse support?
2021-10-26 14:02:50 <andypost[m]> ikke: yes, it's strange one as it needs local server access
2021-10-26 14:04:21 <ikke> Yes, but usually these bugs are chained
2021-10-26 14:04:52 <ikke> So one bug that allows you to do remote things as an unprivileged user, then a local privilege escalation gain root
2021-10-26 14:11:02 <psykose> alandiwix: not sure, but according to the apkbuild and the qt5 configure -webengine-pulseaudio is auto and the apkbuild doesn't pull in pulseaudio-dev for it to detect it
2021-10-26 14:13:18 <psykose> checking the build log gets a not found/use pulseaudio = no
2021-10-26 14:13:24 <alandiwix> would it be possible to support it just by adding pulseaudio-dev to makedepends?
2021-10-26 14:13:40 <psykose> it should then auto to yes, you can verify that yourself by changing only that and trying to build it
2021-10-26 14:13:56 <psykose> it will be immediately visible as soon as configure is done, you can just cancel it then
2021-10-26 14:14:02 <psykose> as for if anything breaks if you enable pulse, no idea :)
2021-10-26 14:15:20 <alandiwix> could we enable it in the repo in case it works?
2021-10-26 14:15:25 <psykose> that should be fine
2021-10-26 14:18:22 <andypost[m]> ikke: as I see new releases will out soon, even 7.3
2021-10-26 14:18:37 <ikke> ok
2021-10-26 14:22:26 <andypost[m]> ikke: FYI 7.4 and 8.0 already fixed, 7.3 waiting for release and 8.1 will out in next 2 days
2021-10-26 14:26:11 <ikke> good
2021-10-26 14:35:13 <Hello71> alandiwix: why can't you use alsa-plugins-pulse or apulse?
2021-10-26 14:36:10 <Hello71> er, apulse is the other way around
2021-10-26 14:38:10 <mps> please don' build anything with PA server by default
2021-10-26 14:39:53 <alandiwix> I'm trying to sandbox it and passing alsa access there (correct me if I'm wrong) is like opening front door AFAIK, just pa socket (that goes into pipewire) should be better solution I guess
2021-10-26 14:40:29 <alandiwix> also pipewire's pulse interface works way better for me
2021-10-26 14:42:58 <alandiwix> @mps yea, I meant to just add libpulse (being pulse client) there, how to do it correctly?
2021-10-26 14:44:51 <psykose> you build it with pulseaudio-dev, then install it, then check it works with either still
2021-10-26 15:14:34 <psykose> alandiwix: also i will check for you, but you know, takes like 500 years to build this :p
2021-10-26 15:17:48 <Hello71> if you use webengine with hardware graphics acceleration you're already SOL as far as real security goes
2021-10-26 15:18:08 <alandiwix> psykose: many thanks, I only have celeron N3350 right now, so you will probably complete it even faster
2021-10-26 15:18:38 <psykose> 20% on chromium so far
2021-10-26 15:18:59 <psykose> also i am not entirely sure on how the architecture of the audio goes, but the alsa playback goes through pipewire-alsa just fine
2021-10-26 15:30:23 <alandiwix> will libpulse really hurt? I would use pipewire-alsa then, but I don't know how to pass only pipewire pcm into the sandbox
2021-10-26 15:30:30 <alandiwix> besides, we have support for alsa, pulse and jack in mpv for example
2021-10-26 15:31:54 <psykose> it wouldn't hurt no
2021-10-26 15:32:26 <psykose> assuming the regular alsa output still works, i would guess it does, (50% compiled so far :p)
2021-10-26 15:36:02 <PureTryOut> Oh I did not realize it did not build with libpulse yet. I'm building Qt6Webengine with Pulse currently and Qt5Webengine should too
2021-10-26 15:37:29 <psykose> i notice you have pipewire-dev in qt6-web, does it come with native pipewire playback too now
2021-10-26 15:38:31 <PureTryOut> No it uses that for screensharing
2021-10-26 15:38:57 <psykose> ah, makes sense
2021-10-26 17:08:31 <alandiwix> PureTryOut: so we can expect  qt5-webengine in Alpine repos to support libpulse in near future?
2021-10-26 17:09:27 <PureTryOut> Sure
2021-10-26 17:09:43 <alandiwix> many thanks
2021-10-26 17:47:17 <markand> yes add pulseaudio by default, we're not building an opinionated distribution
2021-10-26 17:52:13 <mps> :-/
2021-10-26 17:53:07 <mps> it is already opinionated, as all distro are
2021-10-26 17:53:45 <psykose> it doesn't force you to install pulseaudio
2021-10-26 17:56:21 <mps> psykose: it does force me to install libpulse
2021-10-26 17:59:14 <psykose> that doesn't do anything, and along with another 46 .so's, yes
2021-10-26 17:59:37 <alandiwix> and it's small enough. mpv, by comparison, pulls in whole jack server
2021-10-26 18:00:54 <psykose> i think that's because nobody made jack-libs, but maybe there is an actual technical reason
2021-10-26 18:01:04 <nmeum> mpv just pulls in a bunch of jack's shared libraries which just happen to be in the same package as jackd
2021-10-26 18:02:13 <nmeum> we could split -libs for jack but jackd is just a 34 KiB binary
2021-10-26 18:44:31 <PureTryOut> Oh is that why I have jack on my system, I was wondering about that but never bothered to check
2021-10-26 20:30:56 <mps> huh, why libreoffice is disabled on some arches
2021-10-26 20:33:30 <dalias> probably some broken dep that was disabled rather than being fixed :/
2021-10-26 20:34:45 <mps> hmm
2021-10-26 20:35:47 <psykose> the mr that disables them has a few words
2021-10-26 20:36:08 <psykose> at least for the recent few
2021-10-26 20:36:20 <mps> hmm, I see git log, not much informative
2021-10-26 20:38:42 <mps> lets try build on edge without this last commit
2021-10-26 20:48:31 <mps> huh, this will eat all builder disk
2021-10-26 21:03:08 <andypost[m]> mps: the reason looks missing boost_filesystem ##13141
2021-10-26 21:07:44 <mps> andypost[m]: this happened with latest boos upgrade?
2021-10-26 21:07:53 <andypost[m]> I bet it is
2021-10-26 21:07:53 <mps> boost*
2021-10-26 21:08:24 <mps> I'm trying to build on edge right now, on aarch64
2021-10-26 21:09:05 <andypost[m]> maybe some issue with builders
2021-10-26 21:11:30 <mps> could be
2021-10-26 21:11:53 <mps> but I think it will not finish soon
2021-10-26 21:12:20 <mps> I will let it to build over night and look tomorrow results
2021-10-26 21:20:26 <mps> andypost[m]: well, it passes building on edge aarch64
2021-10-26 21:21:30 <mps> checkout 2cf3fe063b1b9e308372af7e2c2348e9e494a135
2021-10-26 21:26:41 <andypost[m]> mps: the issue is only on 3.15
2021-10-26 22:10:45 <smcavoy> anyone have thoughts/policy/opinions on packages that would require the use of rust nightly builds to compile?
2021-10-26 22:13:12 <psykose> it's probably not impossible assuming it can be a nightly bumped every release or something, but it seems a bit effortful
2021-10-26 22:14:57 <psykose> afaik that /would/ be fine for the most part, my experience with nightly rust packages is that they just use the nightly apis, no actual 'nightly' dependency
2021-10-26 22:16:17 <psykose> although it's something i don't particularly like about rust, how they've had nightly-only apis for years now unstabilised (i think?), making it essentially an alternate compiler
2021-10-26 22:17:21 <psykose> every time i read the release notes they stabilise a few things but there's hundreds of unstable features
2021-10-26 22:20:01 <Hello71> smcavoy: like which?
2021-10-26 22:20:26 <smcavoy> see !13134
2021-10-26 22:20:31 <smcavoy> err...
2021-10-26 22:20:41 <smcavoy> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13134
2021-10-26 22:22:03 <smcavoy> package in testing has been renamed upstream and the requirements have changed to needing rust nightly builds to compile
2021-10-26 22:26:15 <psykose> testing/keepassxc-proxy-static doesn't look like it installs nightly with rustup, just regular rust, and it was a temp workaround for a bug
2021-10-26 22:32:20 <Hello71> https://github.com/dani-garcia/vaultwarden/commit/1e950c7dbc8bfaca0df4fd2d97d12e8b7d1fbc55 says you can just use stable rust
2021-10-26 22:32:53 <Hello71> https://github.com/dani-garcia/vaultwarden/issues/712
2021-10-26 22:42:45 <psykose> you can't build it with stable, the latest tag fails on a specific subdep that needs at least a 3 year old nightly version
2021-10-26 22:42:57 <psykose> and master specifies 1.57 with the new edition field that lets you specify minversion
2021-10-26 22:43:24 <psykose> but according to the discussion this was mostly due to rocket being nightly-only, and now it can build on stable, so they might figure it out in some time
2021-10-26 22:49:40 <psykose> oh i had the wrong tag, hehe
2021-10-26 22:49:47 <psykose> the latest tag also has 1.57 as minversion
2021-10-26 22:58:03 <ngortheone> sorry for cross-posting: I am trying to find out who/what creates plugdev group. Grepping aports does not give any results..
2021-10-26 22:59:43 <psykose> solaar, udevil, networkmanager, libftdi1
2021-10-26 23:00:28 <psykose> networkmanager-elogind, though that's redundant to the previous
2021-10-26 23:02:55 <psykose> smcavoy: lowering version to 1.56 and updating rocket to the latest stable-allowed release, then removing rocket_contrib as it's now in rocket itself, allows for the compile to get to the point where it fails just due to the imports needing to be changed (or at least that's over 90% of the error output)
2021-10-26 23:03:03 <psykose> so, it should work on stable once upstream fixes up some things :)
2021-10-26 23:03:41 <psykose> they might want to wait for 0.5 proper instead of -rc.1, but Eventually it'll work
2021-10-26 23:22:50 <ngortheone> psykose: maybe you know a better approach - I need firefox to be able to use my yubikey for u2f. At the moment it can't detect when I press yubikey to perform validation. I think it is a permission thing
2021-10-26 23:23:29 <ngortheone> I remember there was a udev rule that automatically permissions yubikey devices to plugdev, but I can't find it
2021-10-26 23:23:32 <psykose> do you have yubikey-manager
2021-10-26 23:23:45 <ngortheone> I do not, but I can install it
2021-10-26 23:23:51 <ngortheone> why?
2021-10-26 23:24:48 <psykose> and then enabling pcscd
2021-10-26 23:25:24 <ngortheone> I have pcscd, and I can use yubikey with gpg already
2021-10-26 23:26:52 <psykose> aside from that searching u2f in about:config should be enabled for the 1 option
2021-10-26 23:27:02 <psykose> i don't think the device perms matter
2021-10-26 23:27:06 <ngortheone> I think this is it https://pkgs.alpinelinux.org/package/edge/community/x86_64/libu2f-host
2021-10-26 23:27:44 <psykose> yeah, it's a dep of yubikey-manager
2021-10-26 23:28:57 <psykose> ah, and it does indeed use plugdev in the udev file, you were right
2021-10-26 23:29:08 <ngortheone> I think that's all I need.. lemme try that
2021-10-26 23:29:14 <psykose> if you don't have it you can just addgroup plugdev and adduser you plugdev and relog
2021-10-26 23:29:21 <ngortheone> thanks for rubber-duck therapy!
2021-10-26 23:29:40 <psykose> hope it works
2021-10-26 23:47:18 <smcavoy> Thanks psykose and Hello71 
2021-10-27 02:11:41 <ktprogra1s> One of the tests for the (not yet merged) swi-prolog package is failing with a SEGFAULT on s390x. I've tried to debug it but QEMU user mode emulation doesn't implement ptrace so gdb doesn't work.
2021-10-27 02:14:50 <Hello71> SEGFAULT isn't supposed to be capitalized
2021-10-27 02:15:35 <Hello71> for your question, https://www.google.com/search?q=gdb+qemu-user&hl=en
2021-10-27 02:15:42 <ktprogra1s> Ok, that's how the output of ctest was.
2021-10-27 02:42:54 <andypost[m]> 3.15 builders passed except x86_64 and aarch64!
2021-10-27 03:54:07 <andypost[m]> aarch64 also passed
2021-10-27 06:26:52 <mps> good morning
2021-10-27 06:27:28 <mps> andypost[m]: ikke: ncopa: !26872 looks like upstream fixed ncurses bug
2021-10-27 06:49:44 <ikke> @ncopa enabled an automatic merge when the pipeline for a7f55994 succeeds 2 minutes ago
2021-10-27 06:51:00 <mps> ahm, I see
2021-10-27 06:57:24 <ncopa> nice that they fixed it
2021-10-27 06:57:36 <ncopa> and thank you for following up with upstream
2021-10-27 06:58:18 <mps> np :)
2021-10-27 06:58:24 <ikke> Do they still use pkgconf --debug output?
2021-10-27 06:58:57 <mps> if we keep civilized communication most problems could be solved
2021-10-27 07:00:37 <mps> ikke: this is something that Thomas (upstream) told that it will look how to make it better
2021-10-27 07:01:50 <mps> ncurses is used on a lot of different systems (and really old ones) so I understand it is not easy task to keep it work flawlesly everywhere
2021-10-27 07:07:27 <ikke> btw: https://utcc.utoronto.ca/~cks/space/blog/programming/GoVersionOfYourSource
2021-10-27 07:08:22 <ikke> Might need to start working on preventing aports commit hashes leaking into go binaries
2021-10-27 08:58:47 <alandiwix> Does anyone have problems with qutebrowser or any other qt5-webengine browsers? Like eternal hangs on start in 50% of runs?
2021-10-27 08:59:35 <alandiwix> Doesn't happen in void chroot or flatpak though.
2021-10-27 09:21:38 <omni> I use qutebrowser, in sway/wayland on x86_64, and haven't experienced any issues lately
2021-10-27 10:08:17 <alandiwix> omni: do you happen to also use libudev-zero?
2021-10-27 12:10:18 <Ariadne> working on a new gcc 10.3 snapshot
2021-10-27 12:13:05 <Ariadne> would be nice to have rust 1.56
2021-10-27 12:28:50 <Ariadne> i plan to switch to gcc 11 after this
2021-10-27 13:24:16 <PureTryOut> does apk overwrite config files in /etc if they're untouched, or does it still make an .apknew variant?
2021-10-27 13:25:26 <clandmeter> overwrite
2021-10-27 13:41:48 <omni> alandiwix: no, eudev
2021-10-27 13:42:11 <omni> I guess, it was a long time since I thought about this part of my setup
2021-10-27 13:43:04 <mps> arm builder is out of disk space
2021-10-27 13:43:42 <mps> avail 1.4M (yes M)
2021-10-27 15:16:45 <omni> floppy!
2021-10-27 16:11:34 <andypost[m]> FYI meson clised issue https://github.com/mesonbuild/meson/issues/9441
2021-10-27 16:14:44 <ikke> Ok, so it will be a warning again in 0.61, and downstream maintainers are urged to fix their projects
2021-10-27 16:17:29 <artok> regression fixes to meson coming really soon anyways
2021-10-27 16:17:50 <ikke> it's not a regression
2021-10-27 16:18:15 <artok> oh that was the gnome one
2021-10-27 16:19:05 <ikke> gnome projects passed an optional argument to i18n.merge_file, but that was never supported, didn't do anything, and now it's turned into an actual error
2021-10-27 17:09:38 <andypost[m]> I find cmake also fast on deprecations
2021-10-27 17:10:05 <ikke> this is not something that was supported and deprecated
2021-10-27 17:10:23 <ikke> this was something that was not supported, but accepted
2021-10-27 17:11:33 <andypost[m]> I mean deprecations supposed to turn to error only in major
2021-10-27 17:16:11 <andypost[m]> ikke: as I see ghc is only blocker left?
2021-10-27 17:16:52 <ikke> andypost[m]: https://tpaste.us/1E8Q 
2021-10-27 17:20:04 <andypost[m]> Gitea easy to fix and I find it better to disable community/greenbone-security-assistant for now
2021-10-27 18:00:49 <andypost[m]> Looks xorg server went to meson for 21.1)
2021-10-27 18:08:49 <mps> yes, I'm preparing upgrade
2021-10-27 18:09:23 <mps> we need libxcvt separate lib to add to aports and it is already in my local branch
2021-10-27 18:10:33 <mps> I don't know how to add this licence text to aports/APKBUILD https://gitlab.freedesktop.org/xorg/lib/libxcvt/-/blob/master/COPYING
2021-10-27 18:11:01 <andypost[m]> mps: maybe "custom" and package a copy
2021-10-27 18:12:33 <mps> already set it to 'custom'
2021-10-27 18:13:17 <mps> so I should add text in aports and copy it with libxcvt or libxcvt-doc? or libxcvt-dev?
2021-10-27 18:15:30 <andypost[m]> mps: looking at boost "$pkgdir"/usr/share/licenses/$pkgname/LICENSE
2021-10-27 18:16:45 <mps> aha, I see, thanks
2021-10-27 18:17:18 <ikke> Seems like it's MIT?
2021-10-27 18:17:33 <ikke> https://spdx.org/licenses/MIT.html#licenseText
2021-10-27 18:20:28 <mps> but it is not explicit about it
2021-10-27 18:20:36 <andypost[m]> btw https://archlinux.org/packages/extra/x86_64/libxcvt/
2021-10-27 18:21:15 <mps> aha, they are also set 'custom'
2021-10-27 18:21:16 <ikke> mps: usually like that with MIT
2021-10-27 18:22:04 <mps> ikke: so, what is you advice? MIT?
2021-10-27 18:23:13 <mps> ok, I will create MR with custom and if someone experienced in this could review
2021-10-27 18:23:47 <ikke> The first 2 are MIT, the 3rd is different
2021-10-27 18:25:35 <mps> !26889
2021-10-27 18:26:14 <mps> uhm, I don't have 'l' at the beginning of pkgdesc :|
2021-10-27 18:26:34 <fcolista> hi C coders, i need help with gvm-libs. As usual, openvas is very glibc oriented. 
2021-10-27 18:26:36 <fcolista> https://dpaste.com/8YLWUHAJB
2021-10-27 18:27:02 <fcolista> they use __in6_u which does not exist on posix, so I've patched it with s6_addr
2021-10-27 18:27:12 <fcolista> but i got that error.
2021-10-27 18:27:37 <fcolista> I suppose that I cannot copy two structs in this way..
2021-10-27 18:27:45 <fcolista> but I sucks with C
2021-10-27 18:28:11 <mps> ikke: libxcvt description is to long, should it be split to two lines (I know this is not acceptable) or reword it somehow
2021-10-27 18:28:36 <ikke> https://repology.org/project/libxcvt/information for examples from other projects
2021-10-27 18:29:16 <mps> ikke: nice, thanks
2021-10-27 18:38:19 <ikke> mps: https://fedoraproject.org/wiki/Licensing:MIT#Old_Style
2021-10-27 18:39:39 <mps> ohm, what a numbers of them
2021-10-27 18:44:55 <ikke> But it still seems to be a MIT variant
2021-10-27 19:07:49 <mps> the question is: is it too late to upgrade xorg-server to new major release
2021-10-27 19:08:00 <mps> for 3.15 I mean
2021-10-27 19:09:37 <ikke> Does it break ABI?
2021-10-27 19:10:52 <mps> announce says: xfree86: bump video ABI version to 25.0
2021-10-27 19:11:51 <mps> and some other bumps of ABI
2021-10-27 19:13:00 <Hello71> theoretically nothing should link against xorg-server except xf86 modules
2021-10-27 19:13:16 <Hello71> i would be more concerned about api than abi
2021-10-27 19:35:21 <mps> ok, I merged libxcvt to testing. if 'we' decide to upgrade xorg then we can move it community
2021-10-27 19:51:52 <andypost[m]> mps: how many packages will need rebuild if abi changed?
2021-10-27 19:56:43 <mps> didn't checked yet
2021-10-27 19:57:22 <mps> and not sure we should upgrade now (in freeze time)
2021-10-27 19:57:43 <mps> though it is interesting release with nice new features
2021-10-27 19:58:00 <mps> tempting really :)
2021-10-27 20:02:32 <dalias> fcolista, ret->addr6 = host->addr6;
2021-10-27 20:02:53 <dalias> their original poking at the member made no sense. they want to assign the whole struct, so just do that
2021-10-27 20:04:22 <dalias> same could be done for the ipv4 case immediately above
2021-10-28 02:19:29 <andypost[m]> can someone merge !26893 as jrutka already approved
2021-10-28 06:40:04 <ncopa> andypost[m]: whoopps... i think fixing ghc just became significantly harder with ghc deleted from edge
2021-10-28 06:44:37 <ncopa> i do not see any other option than to drop ghc from alpline v3.15 now. getting back ghc once its deleted means we need bootstrap it one way or the other. manually
2021-10-28 06:47:09 <ncopa> andypost[m]: do you think you could help somehow get back the ghc package for edge?
2021-10-28 06:49:40 <andypost[m]> ncopa: I see no other packages depends on it, but I used to try fix tests but failed with cabal
2021-10-28 07:01:08 <endinferno1> Does anyone know why my log cannot print in func apk_db_open
2021-10-28 07:01:35 <ikke> ncopa: I was afraid for that to happen ☹️
2021-10-28 07:02:26 <ikke> FYI, I already switched CI to use upstream shellcheck 
2021-10-28 07:03:34 <endinferno1> I git clone apk-tool's source code to debug, add some print in func apk_db_open and func main in apk.c. But the print in func main can print successfully, in func apk_db_open, cannot print anything out 
2021-10-28 07:05:59 <endinferno1> Very weird thing 
2021-10-28 07:07:36 <ikke> Just a sanity check: is that function even executed? 
2021-10-28 07:07:45 <ikke> I would expect so, but still 
2021-10-28 07:10:45 <endinferno1> That's the point, I also thought that the func was not executed. But there is no other func's name called apk_db_open : (
2021-10-28 07:11:41 <ncopa> andypost[m]: ghc depends on ghc-boostrap, which is provided by ghc.
2021-10-28 07:11:55 <ncopa> so ghc depends on ghc to build
2021-10-28 07:22:24 <fcolista> dalias, thanks a lot.
2021-10-28 07:22:26 <fcolista> https://dpaste.org/py31
2021-10-28 07:22:55 <ikke> ncopa: I still have a local built ghc package from the MR
2021-10-28 07:23:23 <ikke> No cabal though 
2021-10-28 07:27:50 <clandmeter> when was it removed?
2021-10-28 07:28:24 <ikke> Last night 
2021-10-28 07:28:34 <clandmeter> which repo?
2021-10-28 07:28:54 <clandmeter> https://nl3.alpinelinux.org/alpine/edge/community/x86_64/
2021-10-28 07:29:06 <clandmeter> https://nl3.alpinelinux.org/alpine/edge/community/x86_64/cabal-3.2.0.0-r1.apk
2021-10-28 07:29:20 <clandmeter> https://nl3.alpinelinux.org/alpine/edge/community/x86_64/ghc-8.8.4-r2.apk
2021-10-28 07:30:23 <clandmeter> out of space mirror :)
2021-10-28 07:40:31 <andypost[m]> ncopa: maybe just move this packages to testing?
2021-10-28 07:47:04 <ikke> We cannot move them without rebuilding 
2021-10-28 07:58:06 <andypost[m]> ikke: I dont know how
2021-10-28 08:01:22 <andypost[m]> ncopa: release notes could mention ldc upgrade !23777
2021-10-28 08:02:12 <ikke> andypost[m]: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.15.0
2021-10-28 08:02:14 <ikke> please add it there
2021-10-28 08:03:15 <ikke> #13099
2021-10-28 08:05:12 <fcolista> ikke, i think we should add the removal of ghc
2021-10-28 08:21:58 <andypost[m]> added a bit 
2021-10-28 08:24:51 <mps> andypost[m]: you asked move libxcvt to community. do you think we should upgrade xorg server also?
2021-10-28 08:26:08 <andypost[m]> mps: it's really depends on abi changes
2021-10-28 08:26:28 <andypost[m]> maybe try to bump few packages, I bet there's not a lot of dependencies
2021-10-28 08:27:28 <mps> andypost[m]: https://tpaste.us/kxdz
2021-10-28 08:27:59 <mps> result of 'ap revdep xorg-server-dev' in community
2021-10-28 08:28:56 <andypost[m]> From release notes the Glamor additions may cause circular deps
2021-10-28 08:29:36 <mps> this could be fixable, I think
2021-10-28 08:31:34 <andypost[m]> anyway it will be interesting to see in edge)
2021-10-28 08:31:57 <mps> sure
2021-10-28 08:32:39 <mps> I built it last night but with ./configure because meson didn't worked
2021-10-28 08:33:21 <mps> build went fine
2021-10-28 08:33:23 <andypost[m]> I can't get why it does not allow to override HOME for tests #26273
2021-10-28 08:33:41 <andypost[m]> 26273!
2021-10-28 08:33:42 <andypost[m]> #26273
2021-10-28 08:33:44 <andypost[m]> !26273
2021-10-28 08:34:02 <andypost[m]> one of disable from community
2021-10-28 09:07:54 <andypost[m]> ncopa: are you ok with bugfix upgrade !26897
2021-10-28 09:08:47 <clandmeter> ikke: are those the files you where looking for?
2021-10-28 09:08:58 <ikke> clandmeter: yes
2021-10-28 09:09:00 <clandmeter> i think we want to fix the mirror
2021-10-28 09:09:18 <ikke> dl-4, dl-5?
2021-10-28 09:09:21 <clandmeter> i increased the size of the disk so enabling it would remove those files again
2021-10-28 09:09:37 <ikke> clandmeter: they are even still on dl-master
2021-10-28 09:09:48 <ikke> http://dl-master.alpinelinux.org/alpine/edge/community/x86_64/ghc-8.8.4-r2.apk
2021-10-28 09:09:57 <clandmeter> ok?
2021-10-28 09:10:04 <ikke> ^
2021-10-28 09:10:07 <clandmeter> but you mention thery are gone?
2021-10-28 09:10:17 <ikke> I think they are not automatically removed when disabled
2021-10-28 09:10:54 <clandmeter> hmm
2021-10-28 09:11:01 <clandmeter> ok so i can just enable the mirror again
2021-10-28 09:11:37 <ikke> yes
2021-10-28 09:12:20 <clandmeter> oh
2021-10-28 09:12:23 <clandmeter> its full again
2021-10-28 09:12:25 <clandmeter> wtf
2021-10-28 09:12:45 <clandmeter> moving this to infra
2021-10-28 09:38:18 <mps> why everyone likes to release their 'new and shiny' software when alpine is in freeze :/ "We are pleased to release v2.3.17 of Dovecot."
2021-10-28 09:39:32 <ikke> Software is constantly being updated. We'll always miss out on some update 
2021-10-28 09:40:18 <ikke> And I think dovecot does not have anything depending on it that needs to be rebuilt? 
2021-10-28 09:42:19 <mps> dovecot-fts-xapian only
2021-10-28 09:43:03 <mps> lets see how will check() work
2021-10-28 09:44:34 <mps> hah, this was easy one of upgrades, lets test on armv7
2021-10-28 09:49:38 <mps> andypost[m]: I don't have experience with gitea anymore. last time I build it was in time when I used go for programming (and that is more than 4 years)
2021-10-28 09:53:48 <andypost[m]> I found that it was not reported upstream(
2021-10-28 09:58:57 <alandiwix> anyone using qutebrowser with libudev-zero?
2021-10-28 10:04:48 <mps> alandiwix: why?
2021-10-28 10:07:16 <alandiwix> I seems qt has some nasty race when used with libudev-zero. This results in 50% chance of catching deadlock on start, but only if I give the app access to my gpu.
2021-10-28 10:09:23 <mps> wonder how this could be related to libudev-zero, or udev
2021-10-28 10:09:56 <alandiwix> Seems to work on my eudev machine, so just wanted to make sure
2021-10-28 10:10:19 <mps> maybe you need some rules to add to mdev.conf
2021-10-28 10:14:12 <alandiwix> well, I've got rules for hotplug of input and drm, any other ones I should have?
2021-10-28 10:15:39 <mps> these should be enough
2021-10-28 10:15:54 <mps> audio?
2021-10-28 10:17:11 <mps> what to do with !25043 for 3.15
2021-10-28 10:17:56 <alandiwix> mps:  works fine
2021-10-28 10:18:12 <mps> alandiwix: ?
2021-10-28 10:18:21 <alandiwix> audio
2021-10-28 10:18:25 <mps> ah
2021-10-28 10:18:48 <mps> I meant do you need set rules for audio
2021-10-28 10:20:36 <alandiwix> not sure, pipewire handles audio for me and does great
2021-10-28 10:21:40 <mps> ha (pipewire :) )
2021-10-28 10:22:18 <alandiwix> the thing is, the qtwebengine runs ok if I just block access to /sys/devices/pci* (with bwrap for example)
2021-10-28 10:22:21 <ikke> fcolista: kubernetes is failing on x86
2021-10-28 10:23:07 <alandiwix> but in this case I don't have hw acceleration obviously
2021-10-28 10:23:42 <mps> alandiwix: don't know for such complicated setup with a lot of 'moving parts'. firefox works fine
2021-10-28 10:24:24 <alandiwix> yea, firefox is ok, although I really miss some qutebrowser features
2021-10-28 10:24:29 <mps> gpu works fine with libudev-zero on few of my machines
2021-10-28 10:24:41 <alandiwix> also, qutebrowser works fine in flatpak
2021-10-28 10:50:48 <mps> with rootbld we don't have /dev/random nor /dev/urandom
2021-10-28 10:57:16 <ikke> It does --dev-bind /dev /dev
2021-10-28 10:59:09 <ikke> (to bwrap)
2021-10-28 11:05:27 <mps> aha, thanks
2021-10-28 11:06:06 <mps> I have to use it by 'abuild --dev-bibd /dev /dev rootbld'?
2021-10-28 11:06:29 <mps> meh, no
2021-10-28 11:13:35 <fcolista> ikke, yes I saw that. Trying to figure how to fix it
2021-10-28 11:18:14 <fcolista> https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/kubernetes/kubernetes-1.22.3-r0.log
2021-10-28 11:18:41 <fcolista> looks that has been built correctly
2021-10-28 11:19:35 <fcolista> i wonder if it's due to memory
2021-10-28 11:20:24 <ikke> The builder hs 64G mem
2021-10-28 11:20:35 <ikke> 2G per core
2021-10-28 11:20:35 <fcolista> x86 does not see 64gb of mem
2021-10-28 11:20:58 <ikke> Address space per process is ~3G
2021-10-28 11:21:28 <fcolista> still is built now
2021-10-28 11:21:42 <fcolista> without any change
2021-10-28 11:21:55 <fcolista> wondering what els could be
2021-10-28 11:22:01 <ikke> race condition?
2021-10-28 11:22:15 <fcolista> good point
2021-10-28 11:22:30 <fcolista> perhaps i should disable parallel build?
2021-10-28 11:22:43 <ikke> It happened on armv7 as well
2021-10-28 11:22:52 <fcolista> yes, saw that
2021-10-28 11:42:10 <andypost[m]> PureTryOut: Looks after fixed pcre2 it went greed !24066
2021-10-28 12:12:20 <andypost[m]> ncopa: glib-networking needs to be enabled #13107 also mercurial gt another release...building
2021-10-28 12:35:53 <mps> andypost[m]: ikke: 'apk version xorg-server' => xorg-server-21.1.0-r0                   > 1.20.13-r0
2021-10-28 12:36:04 <mps> so, it works \o/
2021-10-28 12:38:09 <mps> Xorg -version => https://tpaste.us/OrXY
2021-10-28 12:38:38 <mps> I'm testing it now to see if something is buggy
2021-10-28 12:43:34 <andypost[m]> mps: did you get what they did with modeseting?
2021-10-28 12:44:45 <mps> as is mentioned in changelog it should be improved
2021-10-28 12:47:03 <mps> DPI reporting is better, now I get it correct on this chromeebook
2021-10-28 12:47:51 <mps> and I read there are gestures added for input
2021-10-28 12:48:17 <mps> but don't have time now to test (and I don't think I need gestures)
2021-10-28 13:14:07 <minimal> mps: the recent config changes you made to linux-edge-virt appears to have some issues, I've booted a VM using that kernel and cannot login (nothing appears at login prompt), I believe this is due to you changing CONFIG_INPUT_KEYBOARD from "y" to "n"
2021-10-28 13:18:34 <Newbyte> What should I do about this error exactly: https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/524295
2021-10-28 13:19:29 <Newbyte> Should I add either wireplumber or pipewire-media-session as explicit dependency? 
2021-10-28 13:27:04 <ikke> sounds like a provider_priority needs to be added to those other 2 packages
2021-10-28 13:36:25 <mps> minimal: yes, I changed it. didn't expected that someone use keyboard for VM
2021-10-28 13:37:13 <mps> minimal: you can install non -virt flavor
2021-10-28 13:37:33 <mps> till we decide what to do about it
2021-10-28 13:38:11 <Newbyte> ikke: so I'd, for example, make wireplumber have a higher priority than pipewire-media-session?
2021-10-28 13:38:40 <minimal> mps: VMs have consoles like any other machine. I'm using -virt kernel specifically because its an Alpine image tailors for VM use (i.e. virtio/Virtualbox/Cloud provider, etc)
2021-10-28 13:39:50 <mps> minimal: I'm sure you know that console doesn't necesarily means keyboard 
2021-10-28 13:40:07 <mps> serial or net consoles
2021-10-28 13:40:24 <minimal> mps: I'm referring to non-serial/net console, which VMs often do have
2021-10-28 13:41:00 <mps> keyboard, mice, displays are usually related to 'bare metal'
2021-10-28 13:41:32 <mps> minimal: np, and sorry. I should ask before I changed this
2021-10-28 13:42:13 <minimal> mps: nope, for example AWS was (until recently) unusual for not providing a console, the majority of cloud provided do provide a console
2021-10-28 13:42:14 <mps> minimal: if it is urgent to you I will revert this in a hour
2021-10-28 13:42:39 <mps> and which arch you use
2021-10-28 13:42:58 <minimal> also I see you also removed mouse support - I don't use that but someone could validly want to run a graphical VM with mouse input (e.g. using virtio graphics)
2021-10-28 13:44:52 <mps> yes, with same reasoning as for keyboard
2021-10-28 13:45:25 <minimal> mps: its not urgent, indeed many of the changes you made to edge-virt are ones that I was going to raise an Gitlab issue/open TSC issue to change for linux-virt as well. However some of your changes seem a bit excessive, you've disabled CONFIG_PTP_1588_CLOCK_VMW for exanmple which is for VMWare
2021-10-28 13:45:41 <Newbyte> Is there any apk command to query why a certain dependency gets pulled in when installing a package?
2021-10-28 13:46:45 <mps> CONFIG_PTP_1588_CLOCK_VMW is for aarch64?
2021-10-28 13:47:17 <minimal> mps: I'm looking at x86_64
2021-10-28 13:47:22 <mps> I thought about it but as no one ever asked for it I disabled it
2021-10-28 13:47:37 <andypost[m]> mercurial is ready to be merged !24713
2021-10-28 13:48:36 <mps> I work to consolidate config options for virt kernels and would like to have as much as possible common configs for them
2021-10-28 13:48:38 <minimal> you've also disabled CONFIG_VIRTIO_VDPA and CONFIG_VBOXSF_FS (Virtualbox) as well
2021-10-28 13:50:10 <mps> minimal: ok, could you tell anything else which is needed
2021-10-28 13:50:41 <ikke> Newbyte: apk dot comes closest
2021-10-28 13:50:56 <ikke> it generates the dependency graph in graphviz format
2021-10-28 13:51:26 <mps> (I'm now irritated with meson, which don't do what I say it to do)
2021-10-28 13:52:24 <minimal> mps: Its a bit hard for me to tell you currently as I cannot log into the VM using that updated linux-edge-virt kernel as you disabled keyboard... :-)
2021-10-28 13:52:46 <mps> :)
2021-10-28 13:53:20 <mps> ok, will do with basic things
2021-10-28 13:53:42 <minimal> mps: I'm only using it for testing purposes, its not an emergency, I usually use linux-virt, I just wanted to see the effect of your changes and immediately hit the unable-to-login problem (plus an init.d error as you'd disabled the vboxsf module for Virtualbox
2021-10-28 13:54:51 <minimal> mps: I agree with the majority of your changes for a virt kernel - disabling HW sensors, disabling PATA/SATA, disabling ACPI ac and battery, etc.
2021-10-28 13:56:10 <mps> minimal: 'we' want small and simple, aren't we ;)
2021-10-28 13:56:38 <mps> or "doesn't we"
2021-10-28 13:57:28 <ikke> "don't we" :)
2021-10-28 13:57:56 <mps> ikke: thanks for correction
2021-10-28 13:59:22 <minimal> mps: for virt kernel I'd say "we" want the kernel as small as possible whilst supporting as many hypervisors as possible, with as few modules in initramfs as required to boot a VM and any other VM-specific drivers built as modules
2021-10-28 14:00:16 <mps> minimal: that is good worded, imo
2021-10-28 14:01:23 <mps> but I'm not sure we need PSMOUSE for virt?
2021-10-28 14:02:17 <minimal> mps: well that's what I've been working on in preparation to open an Issue (once 3.15 is out) to "streamline" the linux-virt config
2021-10-28 14:03:12 <minimal> mps: I think the "problem" for mice is that there's no virtio spec for them so some hypervisors use PS/2 mice, some (I assume like aarch64) use USB mice
2021-10-28 14:03:14 <mps> minimal: I appreciate your intention, please open it
2021-10-28 14:04:19 <mps> I didn't worked with other hypervisors except qemu/kvm (and UML loooong ago) so don't know what they need
2021-10-28 14:04:31 <ncopa> ikke: re ghc. i was thinking that it would be nice with a ghc-bootstrap APKBUILD which pulls the precompiled static binary from upstream ghc
2021-10-28 14:05:12 <mps> but I usually enable options when someone asks (and explain why) for them
2021-10-28 14:05:16 <minimal> mps: you also missed enabling CONFIG_GVE (new Google NIC for some of their VMs)
2021-10-28 14:06:19 <mps> minimal: nice list and thank you. now I better know what is needed to enable
2021-10-28 14:06:47 <minimal> mps: I test regularly on both QEMU and Virtualbox. Haven't set up VMware yet. I also need to find some time to test various cloud providers.
2021-10-28 14:07:52 <mps> 
ACTION is angry now on meson, expected it is simpler than automake/autoconf

2021-10-28 14:08:17 <ikke> ncopa: so a dedicated bootstrap package? 
2021-10-28 14:08:40 <ikke> I just built ghc with system libffi
2021-10-28 14:08:53 <ikke> Only t14999 fails still
2021-10-28 14:11:15 <ncopa> yes, a dedicated ghc-bootstrap package. Might make it easier when we have new releases
2021-10-28 14:11:23 <ncopa> and it might help us with other arches as well
2021-10-28 14:15:36 <mps> are anyone ready to help me with meson on xorg upgrade? I would create draft MR so other could help
2021-10-28 14:22:27 <mps> minimal: CONFIG_PTP_1588_CLOCK_OCP -> This driver adds support for an OpenCompute time card. ?
2021-10-28 14:24:04 <minimal> mps: sounds like it. OCP kit is used by various "private cloud" and medium/large cloud providers
2021-10-28 14:25:51 <mps> ok
2021-10-28 14:28:45 <minimal> mps: the CONFIG_PTP_1588_CLOCK_VMW (which you recently disabled) and CONFIG_PTP_1588_CLOCK_KVM (which you left unchanged) are important for keeping host and guest VM clocks in close sync (more precise than NTP can do)
2021-10-28 14:29:43 <adhawkins> andypost[m]: You made a comment on !26895 that I don't understand. Can you elaborate?
2021-10-28 14:31:21 <andypost[m]> adhawkins: sorry, duplicated link, there's dependent package and I checked that it supports newer releases
2021-10-28 14:32:26 <adhawkins> Ah ok. So it wasn't an issue in the end?
2021-10-28 14:33:52 <mps> minimal: ok, understand. week ago even looked to add ptp tools to alpine
2021-10-28 14:36:04 <minimal> mps: PTP in general relies on specific (high-end) ethernet cards have support for it. However the KVM/VMW drivers "abuse" the PTP hooks to get the high-resolution (nanosecond?) sync working. ptpd is already packaged for Alpine but don't know if many users have suitable network cards to use it
2021-10-28 14:46:50 <minimal> mps: actually you can use chrony with PTP as well as NTP, it supports PHC via /dev/ptp devices
2021-10-28 14:49:55 <mps> minimal: well, I'm of those who don't have PTP cards
2021-10-28 14:50:16 <mps> I can only use 'emulated ptp'
2021-10-28 15:27:13 <Ariadne> same
2021-10-28 15:54:53 <andypost[m]> ncopa: consider to switch in 3.15 please !26922
2021-10-28 17:27:57 <PureTryOut> Uh, anyone with ppc64le knowledge/understanding want to jump in here? https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/81#note_1122001
2021-10-28 17:28:05 <PureTryOut> Somebody claiming our ppc64le might not actually be ppc64le
2021-10-28 17:29:06 <ericonr> That's claiming something else
2021-10-28 17:29:20 <ericonr> fedora calls "ppc64le" by "ppc64"
2021-10-28 17:29:38 <ericonr> which every other distro uses for big endian 64bit powerpc
2021-10-28 17:36:51 <ikke> Anoying makefile which completely ignores the concept of a DESTDIR :/
2021-10-28 17:39:07 <mps> would someone with meson experience and some free time look !26923 
2021-10-28 17:39:32 <mps> why it fails despite I added -Ddtrace=false
2021-10-28 17:40:34 <Hello71> why do you think it is related to -Ddtrace?
2021-10-28 17:41:07 <Hello71> hm, wait, never mind
2021-10-28 17:41:20 <mps> well, when I remove part related to this in meson.build it worked
2021-10-28 17:47:51 <mps> uhm, https://gitlab.freedesktop.org/xorg/xserver/-/issues/1240
2021-10-28 17:48:07 <mps> comment 'Thanks for the report. A fix for this will land in 21.1.1 in the next few weeks'
2021-10-28 17:54:35 <ikke> heh
2021-10-28 17:57:18 <mps> ok, this is not because my undecated meson status but actual bug. good, I feel better :)
2021-10-28 18:02:22 <ikke> :)
2021-10-28 18:06:15 <ikke> In the meantime I'm fighting with Makefiles
2021-10-28 18:06:28 <ikke> Almost there, just one cryptic piece left
2021-10-28 19:13:58 <ikke> ncopa: seems that we cannot build our ghc with the one provided upstream: https://tpaste.us/6W4r (btw, it doesn't really seem to be a static build)
2021-10-28 19:18:10 <ikke> I can hardcode CBUILD / CHOST to x86_64-unknown-linux to get it passed that
2021-10-28 19:23:10 <ikke> Seems it cause issues with ar as well 
2021-10-28 19:24:18 <ikke> complains about missing indexes
2021-10-28 19:25:40 <ikke> hmm, perhaps also my fault
2021-10-29 04:56:10 <andypost[m]> I think opendlap upgrade will have more issues in community so probably does not fit into 3.13
2021-10-29 04:56:19 <andypost[m]> *3.15 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24084#note_188813
2021-10-29 04:57:42 <ikke> You mention only kamailio?
2021-10-29 05:08:05 <andypost[m]> yes, cos did not build community yet as it depends on main and contains ceph
2021-10-29 05:08:36 <andypost[m]> from main only kamailio failed)
2021-10-29 05:09:36 <ikke> ah ok
2021-10-29 05:10:28 <andypost[m]> ikke: btw !26885 brings secondary_storage as 4.4 so it could improve infa
2021-10-29 05:10:42 <andypost[m]> *infra
2021-10-29 05:15:52 <andypost[m]> icu 70.1 is out and looks php7 does not wanna fix it(
2021-10-29 05:16:15 <ikke> ?
2021-10-29 05:16:54 <andypost[m]> so for 3.16 it will a goal to finish transition to php8
2021-10-29 05:16:56 <andypost[m]> https://github.com/php/php-src/pull/7596
2021-10-29 05:18:32 <andypost[m]> basically s/bool/UBool
2021-10-29 05:20:37 <ikke> Need to verify if Zabbix supports php-8 already
2021-10-29 05:20:38 <ikke> haven't checked
2021-10-29 05:21:16 <ikke> Hmm, not yet :/
2021-10-29 05:21:44 <ikke> PHP 7.2.5 or later, PHP 8.0 is not supported. 
2021-10-29 05:35:03 <ikke> I hope 6.0 will support it, but not sure yet
2021-10-29 05:36:18 <ikke> ncopa: ghc builds succesfully against the pre-compiled ghc with the modified build triplets
2021-10-29 05:42:23 <ikke> (including tests)
2021-10-29 05:54:02 <ikke> The problem with --target=$CTARGET is that it failed to find 'ar'\
2021-10-29 06:36:59 <ncopa> good morning
2021-10-29 06:37:04 <ncopa> ikke: awesome!
2021-10-29 06:38:34 <ncopa> we might not need the --target=$CTARGET if we use precompiled binary
2021-10-29 06:42:04 <ncopa> andypost[m]: ccache with secondary storage looks interesting. means we can use redis as ccache, which may speed up CI rebuilds
2021-10-29 06:42:45 <ikke> Interesting 
2021-10-29 06:43:03 <ncopa> or maybe also minio
2021-10-29 06:50:08 <andypost[m]> ncopa: yes exactly, moreover with persistence - it will minimize IO on CI artefacts too
2021-10-29 06:50:14 <mps> good morning
2021-10-29 06:51:21 <mps> ncopa: andypost[m]: ikke: I think we should upgrade xorg server for 3.15, it is a lot better on ARM
2021-10-29 06:51:54 <mps> even if we revert to use ./configure && make from meson
2021-10-29 06:51:57 <andypost[m]> mps: how many rebuilds needed?
2021-10-29 06:52:10 <mps> andypost[m]: not much
2021-10-29 06:52:20 <ncopa> xorg-server normally only need to rebuild the xf86-* drivers
2021-10-29 06:52:46 <mps> actually I didn't rebuilt anything and all I need works fine
2021-10-29 06:53:21 <mps> ncopa: right, drivers and some other things but not big numbers
2021-10-29 06:53:57 <ncopa> 36 packages
2021-10-29 06:54:10 <ncopa> i think its doable
2021-10-29 06:54:28 <ncopa> iirc they also removed ddx or something like that
2021-10-29 06:54:36 <mps> yes
2021-10-29 06:54:44 <ncopa> which might mean that really really old video drivers may no longer build
2021-10-29 06:54:58 <ncopa> and they can probably be removed
2021-10-29 06:55:05 <mps> I agree
2021-10-29 06:55:26 <mps> modesetting is nowadays mostly used
2021-10-29 06:55:38 <ncopa> so i'd guess is an hour or two of work
2021-10-29 06:55:56 <ncopa> do we have an open MR for it?
2021-10-29 06:56:28 <mps> I made only for xorg-server as a draft
2021-10-29 06:56:51 <mps> !26923
2021-10-29 06:57:36 <mps> I asked for help someone who understand meson but upstream announces that they will fix it in a few weeks
2021-10-29 06:57:53 <mps> uhm, https://gitlab.freedesktop.org/xorg/xserver/-/issues/1240
2021-10-29 06:58:58 <mps> btw, I'm running upgraded xorg-server on this box
2021-10-29 06:59:15 <mps> nothing breaks (till now at least)
2021-10-29 06:59:37 <mps> edge on aarch64
2021-10-29 06:59:51 <ncopa> looks like they removed xwayland also?
2021-10-29 07:00:05 <mps> yes, there is separate pkg
2021-10-29 07:00:22 <ncopa> do we have that separate package or does it need to be created
2021-10-29 07:00:47 <mps> didn't looked (forgot)
2021-10-29 07:00:50 <ncopa> i dont think we should revert back to configure && make. lets keep meson and fix
2021-10-29 07:01:02 <mps> I wanted to test xorg first
2021-10-29 07:01:58 <mps> fix for meson will come in 3-4 weeks (as upstream told)
2021-10-29 07:02:18 <mps> is that to late for 3.15
2021-10-29 07:02:24 <mps> too*
2021-10-29 07:02:25 <ncopa> sure. im just saying that i dont think we should merge a commit with autoconf
2021-10-29 07:03:07 <ncopa> i'd rather backport  a patch
2021-10-29 07:03:34 <mps> hmmm, why not? we will revert back to meson when upstream fixes it?
2021-10-29 07:04:43 <ncopa> but im a bit in doubt now. there are a few unkowns, like removal of xwayland and other stuff. im not sure of all of the consequences.
2021-10-29 07:04:55 <ncopa> will it break something for postmarketOS?
2021-10-29 07:04:58 <andypost[m]> mps: as I got it means to add 5 files to patch
2021-10-29 07:05:14 <mps> nor I am. but it so good now on ARM
2021-10-29 07:06:09 <mps> however you decide, but on my boxes I will not go back to old one :)
2021-10-29 07:06:20 <psykose> xwayland is already a separate package
2021-10-29 07:06:22 <ncopa> PureTryOut: wdyt about xorg-server 21.1?
2021-10-29 07:06:25 <psykose> and 21.1.2
2021-10-29 07:06:47 <mps> psykose: in aports?
2021-10-29 07:06:52 <psykose> yes, i have it installed
2021-10-29 07:07:11 <mps> so, this one is fixed ;)
2021-10-29 07:07:28 <psykose> indeed, no need to worry about it apparently :)
2021-10-29 07:07:37 <ncopa> good
2021-10-29 07:08:46 <mps> andypost[m]: I'm not sure how many files need to be patched and added, because this I built with configure and it worked fine
2021-10-29 07:09:20 <mps> https://github.com/CarbsLinux/repository/blob/master/xorg/xorg-server/build
2021-10-29 07:09:36 <mps> this is also with ./configure
2021-10-29 07:14:23 <ncopa> i dont want revert it back because we are doing release soon, so i dont want end up with configure in 3.15-stable so we need maintain both
2021-10-29 07:14:34 <ncopa> makes it trickier to backport patches from edge
2021-10-29 07:14:55 <ncopa> and switching between meson and configure is big enough change that I want avoid in a stable branch
2021-10-29 07:15:52 <mps> my crystal ball says we have one full month to wait for 3.15 release
2021-10-29 07:17:44 <ncopa> not if we skip xorg update ;)
2021-10-29 07:18:00 <andypost[m]> and ghc)
2021-10-29 07:18:08 <ncopa> yup
2021-10-29 07:18:54 <mps> lets see ;)
2021-10-29 07:19:53 <ncopa> last minute changes like xorg updates will delay the release. no doubt. the question is how much and if its worth it
2021-10-29 07:20:40 <mps> I think it is worth
2021-10-29 07:21:55 <mps> dpi is a lot better, modesetting also, gamma and color temperatures are now fixed for ARM boxes, and a lot of small improvements and fixes
2021-10-29 07:22:07 <mps> input now have gestures
2021-10-29 07:22:35 <mps> I think pmOS people will be happy with these things
2021-10-29 07:23:37 <mps> (and I will be happy when I install alpine on apple M1, which I will in few next weeks)
2021-10-29 07:24:40 <ncopa> well someone needs to do the work of backporting the meons patches and reuilbd everythign that needs to be rebuilt. only updating xorg-server package is not enough
2021-10-29 07:25:01 <mps> (*bad* distributor delayed delivery for one week more)
2021-10-29 07:25:54 <mps> you mean meson
2021-10-29 07:29:52 <mps> ncopa: I don't have enough experience to make/backport meson fixes/patches, only if upstream make something then I could try
2021-10-29 07:31:23 <mps> don't like to make mes(s)(on) ;)
2021-10-29 07:31:53 <alexeymin> "I think pmOS people will be happy with these things" I hope so
2021-10-29 07:32:50 <ncopa> mps: do you have a reference to the upstream discussion? or upstream bug tracker?
2021-10-29 07:32:59 <ncopa> post that to the draft MR
2021-10-29 07:33:17 <alexeymin> mps: do you have a link to X release changelog?
2021-10-29 07:33:55 <ncopa> https://lwn.net/Articles/874152/
2021-10-29 07:33:59 <alexeymin> TBH in pmOS most "big" mobile UI packages use wayland, only a few rely on xorg
2021-10-29 07:34:19 <mps> ncopa: andypost[m] already added url in MR
2021-10-29 07:34:26 <ncopa> makes sense, so pmOS probably dont care
2021-10-29 07:34:40 <alexeymin> and rootless xorg seems to be broken currently
2021-10-29 07:35:07 <mps> alexeymin: I saw patch on net somewhere for rootless X
2021-10-29 07:36:09 <mps> https://github.com/CarbsLinux/repository/blob/master/xorg/xorg-server/patches/rootless_modesetting.patch
2021-10-29 07:36:24 <mps> didn't tested it
2021-10-29 07:39:38 <mps> ncopa: there is no mess I can add which you can't fix afterwards :)
2021-10-29 07:57:16 <ikke> "SIGSEGV on Alpine 2.13" 😶
2021-10-29 07:58:46 <ikke> It's 3.13, typo in the title
2021-10-29 08:29:04 <PureTryOut> ncopa: xorg-server? I don't care about it
2021-10-29 08:29:36 <PureTryOut> if you mean the removal of xwayland, that is already a separate package and we use that already
2021-10-29 08:30:19 <PureTryOut> rootless Xorg for the few Xorg environments that we do have would be nice though
2021-10-29 08:34:10 <ncopa> mps: :D that is what I was afraid of...
2021-10-29 08:41:23 <andypost[m]> mps: I've added missing files but now package() fails
2021-10-29 08:50:29 <andypost[m]> mps: fixed
2021-10-29 08:57:58 <mps> andypost[m]: very well. where did you found these patches, or you made them
2021-10-29 08:58:51 <andypost[m]> mps, I just cloned source repo and pick missings files pointed in issue, btw 23-bits fail in ci(
2021-10-29 08:59:20 <andypost[m]> I pointed it in commit message and updated MR)
2021-10-29 08:59:35 <ikke> Exotic architecture
2021-10-29 08:59:52 <mps> ah, I looked upstream only through web
2021-10-29 09:00:35 <andypost[m]> mps: web ui also provides "raw" downloads, it just needs toi select release tag
2021-10-29 09:00:46 <mps> xorg is good for old hardware which are not supported by 'new and shiny' wayland
2021-10-29 09:02:02 <andypost[m]> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/525016#L561 not clear how to fix
2021-10-29 09:03:19 <mps> that is upstream bug
2021-10-29 09:05:07 <mps> because of '-Werror=array-bounds' CC flag
2021-10-29 09:06:19 <mps> I mean, if remove this flag it will probably pass, but we will have buggy xorg (like we don't have a lot of buggy things :) )
2021-10-29 09:14:04 <andypost[m]> and I bet pmOS will like to upgrade mutter !26944 which fails cos needs catchsegv
2021-10-29 09:28:52 <Newbyte> andypost: just disable tests for mutter like I did in !26028
2021-10-29 09:28:59 <Newbyte> they're disabled anyway, just not on a Meson level
2021-10-29 09:29:43 <Newbyte> the problem is that GNOME is not in very good shape in Alpine at the moment 
2021-10-29 09:31:25 <andypost[m]> Newbyte: somehow it needs new dependencies, guess you MR should be accepted as a whole
2021-10-29 09:31:57 <Newbyte> andypost: the problem with my MR is that gnome-session currently doesn't work on Alpine, but that happens even without my changes
2021-10-29 09:32:32 <andypost[m]> Like graphene-gobject-1.0 gtk+3.0 and gsettings*
2021-10-29 09:32:34 <Newbyte> so if you want to merge that go ahead, but Cogitri didn't want to 
2021-10-29 09:32:48 <Newbyte> where do you see anything about Mutter needing new dependencies? 
2021-10-29 09:33:13 <andypost[m]> iirc Cogitri is busy
2021-10-29 09:33:24 <Newbyte> yes, but I've been in contact with him
2021-10-29 09:33:54 <Newbyte> andypost: why do you want to upgrade Mutter exactly?
2021-10-29 09:34:20 <andypost[m]> Newbyte: https://tpaste.us/VEXJ
2021-10-29 09:34:52 <Newbyte> I wonder why it doesn't do that in my MR?
2021-10-29 09:36:03 <andypost[m]> Newbyte: because of https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/77
2021-10-29 09:36:33 <Newbyte> Are you using Mutter on Alpine right now?
2021-10-29 09:37:29 <Newbyte> Or do you think this would fix it?
2021-10-29 09:41:35 <andypost[m]> no atm, but checked last ubuntu on gnome 41 and it looks nice
2021-10-29 09:42:02 <andypost[m]> btw https://repology.org/project/mutter/versions
2021-10-29 09:43:06 <Newbyte> Yeah, GNOME 41 is nice. But it needs to actually work to be nice.
2021-10-29 09:43:49 <Newbyte> Me and Pablo Correa Gomez are working on figuring it out
2021-10-29 09:51:54 <HRio> Ariadne: any reason the /etc/doas.d is not 750 like /etc/sudoers.d ? (commit 34395a3a328)
2021-10-29 10:08:50 <andypost[m]> ncopa: are you ok with upgrade !24894
2021-10-29 10:38:36 <ikke> ncopa: so having x86_64-unknown-linux as the triplet is not an issue?
2021-10-29 10:55:37 <sam_> andypost[m]: don't rush to do 1.1.9
2021-10-29 10:55:41 <sam_> andypost[m]: https://github.com/google/snappy/commit/c98344f6260d24d921e5e04006d4bedb528f404a has broken a bunch of stuff
2021-10-29 10:56:06 <sam_> https://bugs.archlinux.org/task/72058
2021-10-29 10:56:19 <sam_> might be fine but it's something to be aware of
2021-10-29 10:57:23 <ncopa> ikke: hum... i think we want x86_64-alpine-linux triplet
2021-10-29 10:57:32 <ikke> ncopa: Yeah, I assumed so
2021-10-29 10:58:07 <ikke> I guess --target depends the triplet that the compiled ghc will use?
2021-10-29 10:58:14 <ikke> defines*
2021-10-29 10:58:45 <ncopa> i would guess so
2021-10-29 11:00:48 <ncopa> ghc --info
2021-10-29 11:01:08 <ncopa>  ghc --info | tpaste
2021-10-29 11:01:08 <ncopa> https://tpaste.us/9P8l
2021-10-29 11:01:16 <ncopa> that is with alpine v3.14
2021-10-29 11:01:40 <ncopa>  ,("Build platform","x86_64-alpine-linux")
2021-10-29 11:01:40 <ncopa>  ,("Host platform","x86_64-alpine-linux")
2021-10-29 11:01:40 <ncopa>  ,("Target platform","x86_64-alpine-linux")
2021-10-29 11:10:15 <andypost[m]> sam_: thanks! I'm  using it last few weeks without issues
2021-10-29 11:12:33 <ncopa> ikke: do you have an ghc APKBUILD for the precompiled binaries?
2021-10-29 11:12:56 <ncopa> s/ghc/ghc-boostrap/
2021-10-29 11:24:23 <ikke> ncopa: https://gitlab.alpinelinux.org/kdaudt/aports/-/tree/ghc-bootstrap/community/ghc-bootstrap-binary
2021-10-29 11:27:04 <omni> bump https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/81
2021-10-29 11:28:40 <ncopa> ikke: thanks!
2021-10-29 11:28:55 <ncopa> i think we should use embedded libffi for the ghc-bootstrap-binary
2021-10-29 11:31:06 <ikke> It conflicted with libffi when compiling ghc
2021-10-29 11:33:36 <ikke> (libffi-dev)
2021-10-29 11:34:10 <ikke> And from what I understood, it's not a runtime dependency
2021-10-29 11:44:55 <andypost[m]> ncopa: lua-ldap needs your approval !26922
2021-10-29 11:45:40 <andypost[m]> I've no idea why it require any db
2021-10-29 12:21:50 <minimal> mps: the modified linux-edge-virt kernel works now, however I've spotted another related issue. I assume you've never tested linux-edge-virt with Grub? It doesn't work...
2021-10-29 12:36:31 <mps> minimal: I tested aarch64 and armv7 with grub, both worked
2021-10-29 12:37:46 <mps> minimal: there is iso image I built for armv7 https://dev.alpinelinux.org/~mps/alpine-virt-210730-armv7.iso
2021-10-29 12:38:36 <mps> minimal: and here is 'guide' to use it https://arvanta.net/alpine/install-armv7-qemu/
2021-10-29 12:39:53 <mps> when reporting bugs always tell on which arch is it (that is 'order' for all, not only minimal)
2021-10-29 12:43:22 <ncopa> ikke: so using precompiled ghc means we need to do crosscompile tricks
2021-10-29 12:43:40 <ncopa> maybe its easier to manually bootstrap it using the alpine v3.14 ghc
2021-10-29 12:43:40 <ikke> To get the triplet right? 
2021-10-29 12:43:44 <ncopa> yes
2021-10-29 12:43:45 <ikke> Ok
2021-10-29 12:44:10 <ncopa> this is a night mare
2021-10-29 12:45:30 <ikke> FYI, ghc edge package is still there
2021-10-29 12:45:34 <ncopa> i was able to get the build started with ghc-bootstrap-binary and setting build and host to x86_64-unkonwn-linux
2021-10-29 12:45:39 <ncopa> where is it?
2021-10-29 12:45:53 <ncopa> on the edge mirrors?
2021-10-29 12:46:13 <ikke> yes
2021-10-29 12:46:29 <ncopa> ok. that helps
2021-10-29 12:46:35 <ikke> http://dl-master.alpinelinux.org/alpine/edge/community/x86_64/ghc-8.8.4-r2.apk
2021-10-29 12:46:54 <minimal> mps: basically Grub doesn't handle the filename initramfs-edge-virt (Grub has a regex that doesn't handle the double "-" properly) so grub-mkconfig finds no initramfs and so creates grub.cfg that does not reference it. I'm testing with x86_64 but expect the same issue to occur with x86, armv7 and aarch64 when using linux-edge-virt - not an issue with linux-edge (as, like linux-lts and linux-virt, there's only a single "-" in the filename)
2021-10-29 12:47:10 <ncopa> i woner why it was not deleted yet
2021-10-29 12:47:19 <ncopa> but thats good
2021-10-29 12:47:22 <ncopa> we try use that then
2021-10-29 12:49:02 <ikke> I don't think the builders delete it when the package is disabled 
2021-10-29 12:49:17 <ncopa> ah, thats good
2021-10-29 12:49:18 <andypost[m]> ncopa: when arch="" existing files remains in repo
2021-10-29 12:49:24 <ncopa> that is good
2021-10-29 12:49:53 <minimal> mps: in your 'guide' you are manually editing grub.cfg to specify the initramfs so that's why you don't see the issue
2021-10-29 12:50:12 <ncopa> hum.. this libffi thing
2021-10-29 12:50:26 <ncopa> now i get   libffi3.3-compat-dev-3.3-r4:
2021-10-29 12:50:27 <ncopa>     conflicts: libffi-dev-3.4.2-r1[pc:libffi=3.3]
2021-10-29 12:50:42 <ncopa> because current ghc 8 depends on libffi-compat-dev
2021-10-29 12:50:56 <ncopa> and the upgrade will depend on libffi-dev
2021-10-29 12:51:37 <andypost[m]> ncopa: as I got you're need only -compat to install ghc, -dev is not needed if you're using bundled
2021-10-29 12:51:59 <ncopa> we are trying to not use bundled
2021-10-29 12:52:08 <ncopa> because it causes other problems
2021-10-29 12:52:30 <ncopa> but it means the upgrade process is:
2021-10-29 12:52:57 <ncopa> first rebuild with bundled libffi (to get rid of the libffi-compat-dev dep
2021-10-29 12:53:22 <ncopa> once ghc is updated to use bunlded libffi, we need to rebuild it again, but this time with system libffi
2021-10-29 12:53:40 <ncopa> this is truly a nightmare
2021-10-29 12:53:54 <andypost[m]> and how long it could take?
2021-10-29 12:54:13 <ncopa> each rebuild is 30 mins on a fast machine
2021-10-29 12:54:25 <ncopa> but the manual work is what takes time
2021-10-29 12:55:15 <ncopa> I mean, I have to test that it actually works before I start push
2021-10-29 12:55:32 <ikke> ncopa: previously I did `apk add -t libffi-dev` to build it against libffi3.3-compat0dev
2021-10-29 12:55:41 <ikke> the same trick can be done the other way around
2021-10-29 12:56:41 <andypost[m]> interesting trick!
2021-10-29 12:57:12 <minimal> mps: with your working image once any new version of linux-edge-virt package is installed the grub package's trigger will run grub-mkconfig and then you should see the problem (as the modified /boot/grub/grub.cfg will no longer have any "initrd" entries)
2021-10-29 12:58:15 <ncopa> ikke: i guess that is not something we can push to the builders?
2021-10-29 12:58:20 <ikke> nope
2021-10-29 12:58:29 <ikke> someone needs to do it manually
2021-10-29 13:40:06 <mps> minimal: ah yes, thanks for reminding me
2021-10-29 13:40:22 <mps> this is grub bug, not linux-edge
2021-10-29 13:41:42 <minimal> mps: basically grub-mkconfig looks for initramfs-virt rather than initramfs-edge-virt, doesn't find it and so puts no reference to "initrd" in the created/updated grub.cfg file and so booting fails
2021-10-29 13:42:52 <mps> minimal: yes, I remember. but this should be fixed in grub
2021-10-29 13:43:08 <mps> syslinux works fine iirc
2021-10-29 13:43:20 <minimal> mps: its an assumption in grub that expects the filename of an initramfs file ot only include a single "-" and it used a regex pattern to find the "version" which it thinks is "virt" rather than "edge-virt", as linux-edge-virt is the only Alpine kernel package to have a double hyphen in the filename then that's the old kernel package this problem shows up with :-(
2021-10-29 13:43:43 <minimal> s/old/only/
2021-10-29 13:44:03 <mps> right
2021-10-29 13:44:38 <mps> someone should fix grub
2021-10-29 13:45:00 <minimal> I make a hacky-"fix" locally to Grub, not yet sure what a "proper" fix would be. Also not sure if upstream would even take it (plus Grub releases seems to be once per year at best)
2021-10-29 13:45:43 <minimal> If I work out a "nice" fix I'll submit a MR for Alpine Grub.
2021-10-29 14:11:43 <ncopa> ikke: T14999 will pass if you uninstall
2021-10-29 14:13:39 <ncopa> ...uninstall gdb
2021-10-29 14:13:45 <markand> looks like there is no public domain license in SPDX, what should we put?
2021-10-29 14:15:48 <ikke> ncopa: aha, ok
2021-10-29 14:20:01 <ikke> ncopa: So I think libffi is our biggest struggle with ghc atm
2021-10-29 14:24:50 <Hello71> markand: did you read https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
2021-10-29 14:25:05 <minimal> mps: what do Chromebooks use to boot? Grub or u-boot? trying to work out if linux-gru would be affected by Grub issue
2021-10-29 14:27:17 <markand> Hello71, that's good but that does not explain what should we put in the APKBUILD
2021-10-29 14:27:48 <Hello71> what are you packaging
2021-10-29 14:27:53 <Hello71> you should start with that information
2021-10-29 14:28:40 <markand> looks like we use Public-Domain in that case 
2021-10-29 14:30:20 <mps> minimal: some chromebooks can use u-boot (I have one, armv7) but most use specially signed kernel with u-boot mkimage tool to boot, so without boot loader
2021-10-29 14:31:35 <mps> minimal: for some u-boot can be flashed in flash chip but this needs flash tools
2021-10-29 14:32:41 <minimal> mps: ok, so not affected then. So then the issue only affects the linux-edge-virt package and the solution is a simple regex pattern change to /etc/grub.d/10_linux. I'll raise an MR for that after I've done some more verification testing
2021-10-29 14:33:04 <mps> minimal: you can see in linux-gru and linux-elm how is vmlinux.kpart is created
2021-10-29 14:33:53 <minimal> an Alpine MR that is. I think its hard/impossible to get this changed upstream in Grub as various distros name their kernel/initramfs files differently
2021-10-29 14:34:01 <mps> minimal: some arm big servers use grub afaik
2021-10-29 14:34:57 <minimal> mps: yes, as there is no Syslinux package for Arm then things like AWS use/expect Grub for aarch64
2021-10-29 14:36:04 <mps> minimal: so, only fix for alpine grub is needed for this
2021-10-29 14:38:12 <minimal> mps: yes, it basically comes down to Grub assuming kernel and initramfs filenames always contain the kernel numeric version as part of the filename, the regex they use gets "confused" on alpine and extracts based only on the last "-" character
2021-10-29 14:40:24 <mps> minimal: I asked few months ago about this problem, and asked will someone fix grub, but no one raised hand
2021-10-29 14:40:59 <minimal> mps: well I only started testing linux-edge kernels myself yesterday :-)
2021-10-29 14:41:40 <mps> btw, I also asked for grub option to not overwrite grub.cfg at every kernel upgrade but again no one voluntered
2021-10-29 14:42:07 <minimal> mps: I still need to find some time to track down Grub's LUKS2 config problems (grub-mkconfig does not handle LUKS2 at all)
2021-10-29 14:42:44 <mps> 
ACTION thinks that grub is not good piece of software

2021-10-29 14:43:02 <minimal> btw: what should Grub do if it was to not overwrite grub.cfg? When you install a new kernel on Alpine the old kernel is removed, so if grub.cfg is not updated then you have an unbootable system...
2021-10-29 14:43:36 <minimal> well potentially unbootable
2021-10-29 14:43:56 <mps> minimal: newly installed (ok I mean upgraded) kernel and initramfs keep file names in /boot
2021-10-29 14:45:24 <minimal> I'm more concerned that the Grub MBR is never updated, its only done at initial install time - so if a Grub release ever fixes a bug in MBR (security or otherwise) you'll never get it unless you manually reinstall the MBR
2021-10-29 14:48:05 <minimal> mps: right, same filenames but not necessarily same contents for initramfs (it is rebuilt by mkinitfs whose config could have changed) and /etc/default/grub or /etc/grub.d/* files could have been changed since last kernel install so grub.cfg is regenerated to reflect the current contents of those files
2021-10-29 14:49:29 <minimal> I guess the grub trigger script could have added "smarts" to only run grub-mkconfig if /boot/grub/grub.cfg is older than /etc/default/grub or /etc/grub.d/* files
2021-10-29 14:51:01 <mps> well, I didn't used grub in last years so I forgot how to configure its behavior in /etc/*
2021-10-29 14:51:52 <mps> but grub in alpine is practically copied from debian, so maybe some debian guides could help
2021-10-29 15:03:12 <ncopa> >>> ghc*: Tracing dependencies...
2021-10-29 15:03:12 <ncopa> 	so:libffi.so.8
2021-10-29 15:03:12 <ncopa> ...
2021-10-29 15:03:22 <ncopa> i got ghc built with libffi.so.8
2021-10-29 15:07:20 <ikke> ok, good
2021-10-29 15:09:25 <ncopa> so i was thinking
2021-10-29 15:09:43 <ncopa> we can either remove ghc all together, at which point it will be difficult to get it back
2021-10-29 15:10:16 <ncopa> needs to be cross compiled, even if we use existing precompiled binaries. and i was not able to use it to crosscompile a new ghc
2021-10-29 15:10:34 <ncopa> so it may be good to keep the ghc if possible
2021-10-29 15:10:49 <ncopa> so, what if we keep ghc, but for now disable cabal and the rest?
2021-10-29 15:11:02 <ncopa> with ghc we can at least rebuild ghc
2021-10-29 15:11:15 <ncopa> and work on fixing cabal later if needed
2021-10-29 15:12:23 <ncopa> we can also postpone split ghc if needed
2021-10-29 15:12:23 <ikke> sounds good to me
2021-10-29 15:14:07 <ikke> building cabal is purely bootstrapping related?
2021-10-29 15:39:54 <ericonr> sam_: that's an ugly commit lol. "Let's add -fno-exception and -fno-rtti together with these static_casts"
2021-10-29 15:40:17 <ericonr> And *not* mention the former at all in the commit message 
2021-10-29 15:40:22 <sam_> yes!!
2021-10-29 15:40:24 <sam_> it's so sneaky
2021-10-29 16:08:45 <Hello71> markand: tbh that should be removed
2021-10-29 16:09:07 <Hello71> picking random example, jsoncpp, it should be MIT not Public-Domain
2021-10-29 16:09:23 <Hello71> Public-Domain is not a license
2021-10-29 16:15:10 <mps> Hello71: hmm, just working to add one pkg with PD license https://github.com/faf0/sct/blob/master/LICENSE
2021-10-29 16:15:39 <mps> what to put in license field?
2021-10-29 16:16:36 <mps> license="no license"
2021-10-29 16:16:52 <mps> or "PD"
2021-10-29 16:17:49 <ikke> https://creativecommons.org/publicdomain/mark/1.0/deed.en
2021-10-29 16:19:11 <mps> but it is not in SPDX, what to use for alpine
2021-10-29 16:19:42 <mps> CC?
2021-10-29 16:19:49 <ikke> It's not a cc license
2021-10-29 16:20:45 <mps> i see some pkgs with "Public Domain"
2021-10-29 16:21:37 <ikke> https://creativecommons.org/2010/10/11/improving-access-to-the-public-domain-the-public-domain-mark/
2021-10-29 16:22:53 <Hello71> technically this code should be considered "unclear license status". PDM is only valid for "old works that are beyond the reach of copyright in all jurisdictions" or otherwise uncopyrightable for reasons such as de minimis
2021-10-29 16:22:59 <ikke> https://github.com/spdx/license-list-XML/issues/988
2021-10-29 16:23:24 <Hello71> it is obviously not applicable for this non-trivial code
2021-10-29 16:23:47 <Hello71> the original code is marked as "/* public domain, do as you wish */"
2021-10-29 16:24:18 <Hello71> which falls under https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
2021-10-29 16:25:49 <Hello71> best option here is probably license="custom:Public-Domain"
2021-10-29 16:29:15 <Sheila> might be worth reaching out to them and suggesting they use CC0.
2021-10-29 16:39:35 <Hello71> well in this case you would need to ask tedu and also faf0
2021-10-29 16:39:55 <Hello71> and zvezdochiot
2021-10-29 16:42:12 <mps> why? in LICENCE text is written that anyone is free to use however want
2021-10-29 16:42:26 <mps> IANAL though
2021-10-29 16:43:02 <mps> (alpine needs volunteer lawyer)
2021-10-29 16:55:16 <Newbyte> did the community semi-freeze happen yet?
2021-10-29 17:03:22 <ikke> `
2021-10-29 17:03:31 <ikke> yes
2021-10-29 17:03:41 <ikke> Community has been built, so no large rebuilds atm
2021-10-29 17:03:47 <Newbyte> is there any chance we could get in !26915 into Alpine?
2021-10-29 17:03:52 <Newbyte> Alpine 3.15*
2021-10-29 17:04:06 <Newbyte> I don't think that's a large rebuild 
2021-10-29 18:19:58 <ncopa> should be fine
2021-10-29 18:29:08 <vkrishn> just noticed https://git.alpinelinux.org/aports/commit/?id=1cf57fae4fb22f616dcbfde8ec6a4a8bc2ef18db, not that I use is, but found that upstream has moved it to https://git.m455.casa/fa/
2021-10-29 18:33:08 <ikke> ncopa: did try a bit working on cabal-bootstrap, but running into some cabal dependency conflicts when trying to generate the dependency description file for ghc 9.0.1
2021-10-29 19:54:41 <Hello71> mps: legally that's not a very strong argument. of course as a practical matter it's highly unlikely that anybody here will try to sue for copyright infringement
2021-10-29 19:57:31 <durrendal> vkrishn: thanks for that, I had been meaning to reach out to the developer, just hadn't gotten around to it yet
2021-10-29 20:26:23 <mps> andypost[m]: about !26923 it fails only on 32bit arches. I fixed it on armv7 with adding '-Wno-error=array-bounds' to CFLAGS
2021-10-29 20:27:28 <mps> built it and installed on my armv7 chromebook and it works, about two hours without any noticeable problem
2021-10-29 20:28:17 <andypost[m]> I thought to notice upstream about it cos I found no existing reports
2021-10-29 20:28:51 <mps> but there are a lot of warning when building on armv7 related to size of types (%ld and similar) which I think is related to non posix definitions in source
2021-10-29 20:29:48 <mps> andypost[m]: yes, maybe post build log of one of 32bit arches
2021-10-29 20:31:19 <mps> I already thought to post these bugs upstream but not sure will I find time this weekend
2021-10-29 23:38:03 <Fenix7667> Hello!
2021-10-30 07:29:59 <mps> web interface to any application is really bad idea
2021-10-30 07:30:26 <mps> hello gitlab :)
2021-10-30 07:33:36 <mercenary> Relax. In a few more years webasm etc. will have progressed to the level where the 'web interface' is on par with mid-90s thick clients
2021-10-30 07:34:28 <mps> thick? :D
2021-10-30 07:34:58 <mercenary> Then the cycle will start again, with someone writing a 'small and simple browser' in webasm, that runs inside your OS^Wbrowser
2021-10-30 07:38:04 <mps> yes, things are not invented, just repeated
2021-10-30 07:52:16 <mercenary> So instead of calling the next rehash of some technology '-ng', it should be '-pt' for Proven Technology
2021-10-30 07:53:34 <mps> yes, but then it wouldn't be 'good selling' thing
2021-10-30 08:07:18 <nmeum> PureTryOut: is it intended that pipewire-jack takes precendence over jack (it doesn't have a $provider_priority)? recent upgrade on my system purges jack and installs pipewire-jack instead https://tpaste.us/ZjXl
2021-10-30 08:08:32 <mps> nmeum: enjoy pmOS devs at work ;)
2021-10-30 08:09:23 <nmeum> naah, mistakes happen to everyone (if it is indeed a mistake)
2021-10-30 08:09:52 <mps> a lot of such things are not mistakes
2021-10-30 08:10:29 <nmeum> pipewire is also hard to get right
2021-10-30 08:10:48 <mps> yes, that is why I'm against it in alpine
2021-10-30 08:10:59 <nmeum> anyway, I think pipewire-jack needs a provider priority to not take precedence over jack? I am not too familiar with apk provides though
2021-10-30 08:14:39 <nmeum> mps: we ship other software that is "hard to get right" right as well, if someone has a need for having pipewire in alpine (like pmOs does) I don't mind packaging it as long as it not forced upon me :p
2021-10-30 08:18:13 <mps> :)
2021-10-30 08:18:32 <mps> complexity is not good for security
2021-10-30 08:19:05 <PJ[m]> > web interface to any application is really bad idea
2021-10-30 08:19:10 <PJ[m]> fish shell has webinterface
2021-10-30 08:19:15 <PJ[m]> 😊
2021-10-30 08:19:38 <mps> and, I think pmOS is really good OS and pmOS devs work is awesome, but don't belongs to alpine
2021-10-30 08:21:23 <mps> if I can install any OS to replace android on my phone it will be pmOS
2021-10-30 10:08:26 <PureTryOut> not sure what you're talking about, jack and pipewire-jack are in no way needed for pmOS. I did not realize a non-virtual provides also required provider_priority, so that not being there is just a mistake
2021-10-30 10:09:27 <PureTryOut> Also pipewire is also needed by some stuff in Alpine itself, not just by stuff for pmOS. The package would've existed in Alpine without pmOS too, so no need to "blame" us for it yet again
2021-10-30 10:10:01 <PureTryOut> Note that although I'm the current maintainer, I'm not the one that packaged it for Alpine, and neither are the other pmOS devs
2021-10-30 10:10:21 <mps> I remember who introduced libpulse to firefox
2021-10-30 10:10:39 <PureTryOut> Again, not because of pmOS
2021-10-30 10:10:57 <mps> PureTryOut: I remember
2021-10-30 10:11:09 <PureTryOut> I know you have different opinions on these things than we do, but please stop blaming pmOS for everything
2021-10-30 10:12:04 <mps> it is easy to blame it because I like pmOS
2021-10-30 10:12:30 <mps> and to repeat, you (pmOS devs) are awesome
2021-10-30 10:12:51 <mps> but alpine shouldn't be same OS
2021-10-30 10:13:37 <PureTryOut> nmeum: reading the wiki on provider_priority it says "The primary use case is to specify the primary package that satisfies a virtual (provider)."
2021-10-30 10:13:54 <mps> and I think you remember that I helped for some things needed for pmOS
2021-10-30 10:14:06 <PureTryOut> since this isn't a virtual package that it provides, I don't think it's required?
2021-10-30 10:14:08 <ikke> If no priority is set at all, it will be a conflict (apk will not know how to resolve it)
2021-10-30 10:14:45 <PureTryOut> even when it provides a package called "jack=$pkgver-r$pkgrel" while there is also an actual package called jack?
2021-10-30 10:15:14 <ikke> No, then it's not a virtual package
2021-10-30 10:15:35 <ikke> It will prefer the package with the highest version
2021-10-30 10:15:56 <ikke> But I'm not sure what happens when one package provides it as a virtual and another as a concrete package
2021-10-30 10:16:25 <PureTryOut> yeah and pipewire-jack has a lower version than jack does, so I don't see why this would cause problems
2021-10-30 10:17:16 <ikke> PureTryOut: but would it make sense if pipewire-jack is upgraded to a higher version, it would replace jack?
2021-10-30 10:18:02 <PureTryOut> no it wouldn't, so for that I suppose it should still have provider_priority set
2021-10-30 10:18:44 <PureTryOut> if that variable isn't set, what does it default too? like do I need to add provider_priority to jack as well or can I just set it to 0 on pipewire-jack?
2021-10-30 10:19:40 <ikke> PureTryOut: I know that with the cmd: provides the default priority of 0 caused issues
2021-10-30 10:20:13 <PureTryOut> hmm ok, so safer to just set it to 2 on jack and to 1 on pipewire-jack then
2021-10-30 10:21:12 <ikke> But I'm not actual sure how provider_priority interacts with provides="$pkgname=$pkgver-$pkgrel"
2021-10-30 10:21:42 <PureTryOut> Do you know who does?
2021-10-30 10:21:54 <PureTryOut> *who has more knowledge about this we can ask?
2021-10-30 10:22:03 <ikke> Ariadne, fabled
2021-10-30 10:22:13 <ikke> ncopa probably as well
2021-10-30 10:23:34 <PureTryOut> I suppose you hereby pinged them 😛
2021-10-30 10:29:43 <ikke> Should also be possible to create a couple of test packages locally and see how it behaves
2021-10-30 10:34:41 <Ariadne> i see another apk internals blog post coming along
2021-10-30 10:34:56 <ikke> :)(
2021-10-30 10:35:11 <ikke> That's something that's not that well documented and has caused issues in the past
2021-10-30 10:35:57 <ikke> It should be part of apk-tools documentation
2021-10-30 10:51:35 <nmeum> yes, I think it should be documented in one of the abuild or apk-tools man pages
2021-10-30 10:52:00 <nmeum> anyway: would be nice if this jack/pipewire-jack priority thingy could be fixed before 3.15 is tagged
2021-10-30 11:25:07 <PureTryOut> We'll first have to figure out the proper solution, but once we do that I'll fix it
2021-10-30 12:21:51 <ikke> ncopa: I will bootstrap ghc on 3.15
2021-10-30 13:28:38 <ikke> ncopa: ghc is built
2021-10-30 13:28:41 <ikke> :)
2021-10-30 13:38:21 <AntoniAloyTorrens[m]> Why `gettext-tiny` package is on community and testing repos, both at the same time? https://pkgs.alpinelinux.org/packages?name=gettext-tiny&branch=edge
2021-10-30 13:44:09 <ikke> probably someone added it without verifying it already existed
2021-10-30 13:44:26 <Hello71> no
2021-10-30 13:44:37 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12853
2021-10-30 13:45:11 <AntoniAloyTorrens[m]> Hello71: I see, thanks!
2021-10-30 13:51:30 <andypost[m]> Ikke: as I got ghc landed! and 3.15 unlocked?
2021-10-30 13:52:10 <ikke> Yes
2021-10-30 13:52:18 <ikke> GHC is built for x86_64 3.15
2021-10-30 13:52:43 <andypost[m]> 3 weeks of hard work! congrats)
2021-10-30 13:54:37 <ikke> cabal is a different story
2021-10-30 13:54:48 <ikke> which is required to enable the other packages again
2021-10-30 13:55:07 <ikke> but at least we do not loose ghc, which would be anoying to get built again if it's gone
2021-10-30 13:56:46 <andypost[m]> yeah, cabal is bigger mess
2021-10-30 13:57:38 <andypost[m]> mps: why you're closed MR for xorg-server?
2021-10-30 14:20:23 <mps> andypost[m]: did I?
2021-10-30 14:21:20 <mps> this must be gitlab AI in action
2021-10-30 14:21:28 <mps> reopened it
2021-10-30 15:51:10 <kpcyrd> hm, do you run alpine edge on your computer to develop or alpine stable with edge in a vm/container?
2021-10-30 15:52:07 <jvoisin> I'm running alpine edge in a container
2021-10-30 15:52:17 <jvoisin> easier to trash when things go wrong
2021-10-30 15:52:49 <ikke> I develop in an edge container as well
2021-10-30 15:59:08 <kpcyrd> ok thanks. I've been running alpine stable on a laptop for a while to make sure my packages are well tested and wondered if I should upgrade it to edge
2021-10-30 16:26:53 <mps> kpcyrd: I run edge on my laptop (and my daughter also), and run stable on most servers but also edge on some of them
2021-10-30 16:27:45 <mps> and of course some lxc containers
2021-10-30 18:06:07 <dalias> uhg, e2fsck just deadlocked trying to lock an already-locked mutex in a single-threaded process
2021-10-30 18:06:55 <dalias> this is fscking a hosed sd card i dont really care about, so i just resumed it with gdb (manually unlocking the mutex) but it indicates some serious bug in e2fsck...
2021-10-30 18:08:16 <ikke> :/
2021-10-30 18:13:20 <kpcyrd> is it still possible to move packages from testing to community or is it too close to release?
2021-10-30 18:13:35 <Ariadne> if its not intrusive
2021-10-30 18:13:57 <kpcyrd> ok thanks :)
2021-10-30 18:14:03 <Ariadne> but generally we should try to have things "ready" before freeze :P
2021-10-30 18:14:35 <Ariadne> PureTryOut: i'll write up a deep dive on how the solver solves (including provider_priority) tonight
2021-10-30 18:14:52 <PureTryOut> awesome, thanks!
2021-10-30 18:19:53 <mps> how we can do something like debian diverting files when more pkgs have to install same file? pre/post install scripts?
2021-10-31 01:49:44 <bl4ckb0ne> is it possible to request a package being rebuild?
2021-10-31 02:14:20 <Hello71> why
2021-10-31 02:29:35 <bl4ckb0ne> im encountering a segfault with qbittorrent caused by libtorrent-rasterbar being build with boost1.76 and having boost1.77 instlled
2021-10-31 02:29:48 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24589
2021-10-31 02:30:17 <bl4ckb0ne> https://github.com/qbittorrent/qBittorrent/issues/15501#issuecomment-940149317
2021-10-31 02:31:39 <ericonr> What a surprise, header only libraries encoding ABI and leading to issues ;-;
2021-10-31 02:31:59 <bl4ckb0ne> ironic heh
2021-10-31 02:32:03 <dalias> :-p
2021-10-31 02:37:10 <bl4ckb0ne> is it easier if I bump the pkgrel in my patchset?
2021-10-31 02:53:52 <Hello71> arguably the problem is that c++ dynamic linking stinks
2021-10-31 03:21:31 <Hello71> actually if the abi changes shouldn't the mangled name change?
2021-10-31 06:46:36 <bratkart-> ikke: pipeline for !26354 failed as of a timeout, can you please retrigger the build and merge? Thanks
2021-10-31 08:12:11 <ikke> bratkart-: The MR has been merged, maybe you can write something on https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.15.0
2021-10-31 11:38:53 <bratkart-> ikke: thanks, sure, i'll add a sentence or two
2021-10-31 11:40:14 <bratkart-> looks like the ppc64le builder hangs on openjdk13, can someone please cancel und retrigger the build?
2021-10-31 11:41:51 <ikke> done
2021-10-31 11:42:04 <bratkartoffel> it reminds me of the numa problem we had in august
2021-10-31 11:42:19 <bratkartoffel> but lets wait if it finishes now
2021-10-31 11:42:27 <ikke> It seems to have finished on 3.15
2021-10-31 11:42:51 <ikke> And we do not have multiple numa domains on ppc64 afaik
2021-10-31 11:43:10 <ikke> They are vms atm
2021-10-31 12:02:44 <kaey> postgres broken on edge for some time now: Error relocating /usr/bin/psql: PQmblenBounded: symbol not found
2021-10-31 12:02:47 <kaey> known?
2021-10-31 12:04:46 <ikke> kaey: haven't heard about it yet
2021-10-31 12:07:52 <kaey> also clandmeter mentioned on alpine-infra that dl-4 should be okay now, but it's not
2021-10-31 12:07:56 <kaey> https://mirrors.alpinelinux.org/#mirror3
2021-10-31 12:08:15 <ikke> Yeah, we have some space issues atm
2021-10-31 12:08:19 <ikke> trying to figure out how to solve it
2021-10-31 12:37:29 <ikke> kaey: can you open an issue on gitlab.a.o regarding postgres?
2021-10-31 12:43:42 <kaey> might be openssl related, here's repro https://0x0.st/-nfi.txt
2021-10-31 12:48:10 <kaey> Filed 13151 with a few more details
2021-10-31 12:53:36 <ikke> !13151
2021-10-31 12:53:38 <ikke> ugh
2021-10-31 12:53:41 <ikke> #13151
2021-10-31 13:43:17 <Ariadne> :D
2021-10-31 13:44:04 <Ariadne> i will solve this tomorrow, by moving openssl to openssl3, and moving openssl1.1-compat to openssl
2021-10-31 13:44:06 <Ariadne> :)
2021-10-31 13:49:40 <Ariadne> PureTryOut: https://ariadne.space/2021/10/31/spelunking-through-the-apk-tools-dependency-solver/
2021-10-31 13:50:13 <Ariadne> PureTryOut: this is everything you probably never wanted to know about the apk solver, if you *still* have questions, then this should present a good enough overview to be able to piece together anything in solver.c
2021-10-31 14:04:32 <alexeymin> Ariadne: that's a good article, thanks
2021-10-31 16:51:12 <ikke> "Next time: what is the maximum number of entries allowed in /etc/apk/repositories and why is it so low?"
2021-10-31 16:52:00 <ikke> Another related curiosity of me: how does apk match a package to a repository?
2021-10-31 16:58:37 <PureTryOut> > This means that provider_priority is only checked for unversioned providers.
2021-10-31 16:59:02 <PureTryOut> nmeum so adding provider_priority doesn't seem to make sense in this case
2021-10-31 16:59:21 <PureTryOut> as pipewire-jack is a versioned provider, same as jack itself
2021-10-31 16:59:57 <PureTryOut> There is a problem if pipewire ever gets a higher version than jack itself though
2021-10-31 16:59:58 <nmeum> might be the case yes, as I said: I am not familiar with provide details in apk
2021-10-31 17:00:21 <ikke> PureTryOut: basically, this is not really a usecase that apk supports
2021-10-31 17:00:32 <nmeum> there is already a problem now, even if jack's version is higher than pipewire-jack's version
2021-10-31 17:01:07 <PureTryOut> yeah that I understand. are you sure your system doesn't have some other constraint that caused this?
2021-10-31 17:01:23 <PureTryOut> as I currently really don't see how this could be happening
2021-10-31 17:02:05 <nmeum> not sure, mpv pulls in jack on my system and that was replaced by pipewire-jack
2021-10-31 17:02:16 <nmeum> happend on every single system where I have jack installed though
2021-10-31 17:02:40 <ikke> apk add jack installs jack directly
2021-10-31 17:02:51 <ikke> (testing what is happening)
2021-10-31 17:03:14 <ikke> apk add mpv -> pipewire-jack
2021-10-31 17:03:54 <nmeum> so packages that depend on jack now pull in pipewire-jack instead of jack and you only get jack if you install it explicitly? because that would seem wrong to me
2021-10-31 17:03:58 <ikke> I suspect some other dependency causes pipewire-jack being pulled in
2021-10-31 17:04:33 <ikke> I see pipewire-libs and pipewire-media-session being pulled in
2021-10-31 17:05:41 <ikke> http://g.jk.gs/778db2bdaf2035abab2c2b4d44d72df50bb0bf89.png
2021-10-31 17:06:54 <nmeum> https://tpaste.us/EM76
2021-10-31 17:08:52 <nmeum> even if I run `apk add jack` I don't get jack. apk probably think I already have it since it's provided by pipewire-jack?
2021-10-31 17:09:47 <ikke> es
2021-10-31 17:09:50 <ikke> yes
2021-10-31 17:10:09 <ikke> There is something that causes pipewire-jack to be preferred
2021-10-31 17:10:18 <ikke> installing jack does not fix that
2021-10-31 17:10:20 <nmeum> pipewire-jack also does not only have provides=jack but also replaces=jack
2021-10-31 17:10:37 <ikke> replaces just means it's allowed to overwrite the same files (afaik)
2021-10-31 17:11:33 <ikke>   "mpv-0.33.1-r6" -> "jack-1.9.19-r0"[arrowhead=inv,label="so:libjack.so.0",];
2021-10-31 17:11:35 <ikke>   "mpv-0.33.1-r6" -> "pipewire-jack-0.3.39-r6"[arrowhead=inv,label="so:libjack.so.0",];
2021-10-31 17:12:59 <ikke> I don't see anything else pulling in pipewire-jack from that output
2021-10-31 17:31:57 <nmeum> how do I get rid of it then?
2021-10-31 17:36:01 <ikke> https://tpaste.us/0w7N 
2021-10-31 17:36:09 <ikke> That's debug output from the solver
2021-10-31 17:36:31 <ikke> disqualify_package: jack-1.9.19-r0 (conflicting provides)
2021-10-31 17:40:01 <ikke> nmeum: quick work-around: apk add '!pipewire-jack'
2021-10-31 17:40:33 <nmeum> oh, right that works. nice
2021-10-31 17:40:35 <nmeum> ty
2021-10-31 17:42:49 <ikke> I suspect it might have to do with that pipewire-jack has a provides, while jack has not, but not sure
2021-10-31 17:49:49 <ikke> https://tpaste.us/aZOM?hl=true
2021-10-31 17:56:52 <PureTryOut> jack shouldn't need to provide itself though, that's just weird
2021-10-31 17:57:07 <ikke> And it can't
2021-10-31 17:57:52 <PureTryOut> the goal was to have pipewire-jack be able to act as a replacement (which it is) but only when explicitly added to world
2021-10-31 18:12:08 <ikke> Yes, understood
2021-10-31 18:13:04 <ikke> But I think it's not really supported to have a provides for a non-virtual package
2021-10-31 18:13:13 <ikke> Not sure though if that's the case
2021-10-31 18:17:11 <nmeum> *if* that's the case we could make jack a virtual package though by renaming main/jack, I guess?
2021-10-31 18:17:14 <nmeum> but probably not for 3.15
2021-10-31 20:45:09 <Nulo> Hey, I'm having issues updating telegram-desktop. It fails to link to abseil pointer.enter
2021-10-31 20:45:22 <Nulo> That's... not what I wanted to paste. Here it is: https://paste.fyi/zBLYmjiz
2021-10-31 20:46:08 <Nulo> Void Linux just builds abseil along with Telegram..
2021-10-31 20:47:09 <Nulo> Arch Linux too https://github.com/archlinux/svntogit-community/blob/packages/telegram-desktop/trunk/PKGBUILD
2021-10-31 20:47:31 <Nulo> Should we do the same?
2021-10-31 20:49:26 <mps> hmm, I have telegram installed but no abseil
2021-10-31 20:50:15 <Nulo> Oh.. it's possible that's what was unintentionally happening before
2021-10-31 20:50:58 <Nulo> Yep, no abseil dependency at all in the current package
2021-10-31 20:51:07 <Nulo> So do I just let it compile it along with Telegram?
2021-10-31 20:51:43 <Nulo> It's actually depended by tg_owt
2021-10-31 20:59:11 <mps> newly added deps?
2021-10-31 21:04:03 <Nulo> No,
2021-10-31 21:04:09 <mps> good, linux 5.15 is released
2021-10-31 21:04:29 <Nulo> Basically, Telegram Desktop compiles itself with bundled (submodule) dependencies by default
2021-10-31 21:04:33 <mps> Nulo: so why do you want to add it?
2021-10-31 21:04:41 <Nulo> I'm trying to compile the most things with system libs instead
2021-10-31 21:05:05 <mps> aha, this is good idea (imo) when it works
2021-10-31 21:05:40 <Nulo> Yep
2021-10-31 21:06:29 <mps> I would ask maintainer what to do
2021-10-31 21:09:05 <Nulo> I probably should lol
2021-10-31 22:46:57 <Nulooo> I'm sending the patch for Telegram, what do I do if I have also upgraded tg_owt and created a new aport (rnnoise)?
2021-10-31 23:36:41 <Nulo> tdesktop was being compiled with bundled OpenH264 but now I'm compiling it with the packaged one. However, it is on testing, what should I do?