2023-10-02 06:38:09 <ncopa> good morning!
2023-10-02 06:38:38 <ncopa> craftyguy: re https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50427#note_340312 I don't really have any opinion there, but it woudl be nice to know how other distros does it
2023-10-02 06:55:00 <ncopa> ikke: how did I glab mr rebase and merge in one go?
2023-10-02 06:57:07 <ikke> ncopa: you need to use my fork of glab
2023-10-02 07:01:18 <ikke> https://gitlab.alpinelinux.org/-/snippets/1100
2023-10-02 07:44:41 <ajhalili2006> (it's annonying someone pinged me for that bloody spam)
2023-10-02 07:44:57 <ajhalili2006> (it's like using @everyone in Discord)
2023-10-02 07:47:56 <donoban> ncopa: 
2023-10-02 07:48:32 <donoban> !52514 comes from #musl, I posted the link error on qutebrowser and psyokse suggested that the problem was that patch
2023-10-02 07:50:00 <donoban> theorically calling lssp_nonshared before stdc++ invalidates some symbols that stdc++ needs so just delaying it should work
2023-10-02 08:13:33 <quinq> Shouldn't that all be explained in the commit message?
2023-10-02 08:19:26 <donoban> oh yes I can improve it :D
2023-10-02 08:48:32 <ncopa> donoban: Good job! I'll merge it if you just update the commit message. Thanks!
2023-10-02 08:58:06 <donoban> I changed it, thanks ncopa but it's psykose merit :P
2023-10-02 08:59:20 <donoban> how could I know when it's ready for retry the qutebrowser MR?
2023-10-02 09:11:47 <ncopa> i suppose when builders are idle: https://build.alpinelinux.org/ 
2023-10-02 09:13:15 <donoban> ok great
2023-10-02 09:46:22 <liske> ncopa: maybe you remember my issue booting alpine 3.18 on Atom C3558 resulting in weird kernel crashes... (was on 2023-08-30)
2023-10-02 09:46:35 <liske> it looks like this no longer occurs with the current 6.1.55-0-lts kernel :-)
2023-10-02 09:47:46 <ikke> Progress 
2023-10-02 10:18:51 <donoban> wops, does https://gitlab.alpinelinux.org/donoban/aports/-/jobs/1131021#L1287 means that upstream don't support x86?
2023-10-02 10:47:05 <ikke> depends on what `is_valid_x86_target` checks for
2023-10-02 10:50:26 <donoban> it seems that chromium dropped support for x86 on linux, but freebsd is building it with some patching
2023-10-02 10:51:11 <donoban> I ignored the check and tried to build,  probablyt it will need to patch something more
2023-10-02 10:52:49 <donoban> chromium x86 is disabled on alpine
2023-10-02 11:03:30 <donoban> oh, it failed
2023-10-02 11:04:23 <donoban> I suppose that if alpine doesn't support chromium for x86, it shouldn't do for qutebrowser which is indirectly chromium based
2023-10-02 11:44:52 <ncopa> liske: good to hear
2023-10-02 11:51:10 <ncopa> donoban: looks like void has a patch for x86: https://github.com/void-linux/void-packages/blob/master/srcpkgs/chromium/patches/reenable-linux-i686-builds.patch
2023-10-02 11:52:50 <donoban> well, I've ready tried "equivalent" to that, it failed during build so it needs more patches
2023-10-02 11:53:40 <donoban> let's see what thinks omni
2023-10-02 13:13:24 <ikke> Python 3.12 released 
2023-10-02 13:14:55 <Ermine> Ohhh
2023-10-02 13:31:36 <ikke> Probably will have to wait until after 3.19
2023-10-02 13:31:58 <ikke> Quite some removals which will probably break packages 
2023-10-02 15:14:56 <elly> chromium x86 is not supported upstream but it is probably not THAT broken yet
2023-10-02 15:24:54 <ikke> Newbyte: gnome-initial-setup does not build on rv64 due to cheese missing
2023-10-02 15:25:24 <ikke> Hmm, I think cheese might be able to be enabled again
2023-10-02 17:16:19 <Newbyte> <ikke> "Hmm, I think cheese might be..." <- Yeah, it looks like it. Did you try?
2023-10-02 17:16:57 <ikke> Newbyte: not yet. The reason it was disabled turned out to be the libudev-zero issue, which at the time was not fixed yet on rv64
2023-10-02 17:17:25 <Newbyte> Yeah, I saw the commit message
2023-10-02 17:17:41 <Newbyte> I'll put an MR up
2023-10-02 17:24:25 <Newbyte> !52678
2023-10-02 17:24:32 <Newbyte> passedc
2023-10-02 17:24:34 <Newbyte> * passed
2023-10-02 17:28:45 <bl4ckb0ne> ive asked before but got no answer, would it be possible to grab a build from the CI after a test failure? we have a couple of tests crashing for the mold update and when I reported it the maintainer asked for the build dir
2023-10-02 17:31:04 <ikke> bl4ckb0ne: You'd have to copy the source dir to for example $CI_PROJECT_DIR/packages
2023-10-02 17:31:10 <ikke> then it would be available as artifact
2023-10-02 17:32:04 <bl4ckb0ne> celie: do you have time to do it for !52279 or should I pick up the patch
2023-10-02 17:32:09 <bl4ckb0ne> ikke: thanks for the tip
2023-10-02 21:52:27 <donoban> thanks to the clang fix some packages can re-enable x86
2023-10-03 00:26:14 <celie> bl4ckb0ne: Sorry for the late reply, i think you should probably handle that, as i have my hands tied elsewhere. Thanks, i will close my MR, if you want me to.
2023-10-03 00:29:37 <bl4ckb0ne> sure, I can pick up your commit and start in a new MR
2023-10-03 00:33:22 <bl4ckb0ne> tadah https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/52697
2023-10-03 00:35:49 <celie> Thanks
2023-10-03 00:41:45 <bl4ckb0ne> amove build $CI_PROJECT_DIR/packages right?
2023-10-03 00:48:51 <celie> I think amove only works for moving things from $pkgdir to $subpkgdir
2023-10-03 00:51:11 <bl4ckb0ne> oh right it puts the prefix
2023-10-03 01:01:33 <bl4ckb0ne> dumbass me trying to run test on a build folder that has been previously moved
2023-10-03 01:12:36 <bl4ckb0ne> mh cant see the artifact
2023-10-03 01:20:35 <bl4ckb0ne> alright i got it
2023-10-03 05:37:18 <Forza> Good morning. I got a merge request assigned to me, though I am not authorised to actually merge it. What is expected of me to do, so it can be processed by someone that can merge it? 
2023-10-03 05:37:25 <Forza> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/52658
2023-10-03 05:38:21 <ikke> Forza: You can approve the MR
2023-10-03 05:39:15 <Forza> Ok done :) 
2023-10-03 05:40:42 <Forza> Thank you! 
2023-10-03 05:40:53 <ikke> np
2023-10-03 05:41:38 <ikke> I added you as guest to the project so that you can approve MRs assigned to you
2023-10-03 05:42:53 <Forza> Nice. I'm ok with the "approve" button workflow too. I still need to learn things so I don't mess up. 
2023-10-03 05:44:41 <Forza> Also nice to see that Anitya notifications for new versions worked good. 
2023-10-03 09:19:19 <donoban> could I add more time & retry only for s390x ? https://gitlab.alpinelinux.org/donoban/aports/-/pipelines/184234
2023-10-03 10:18:58 <ikke> donoban: extending timeout does not help, it's hung
2023-10-03 10:32:51 <donoban> ahh I see, well so it just needs opinion from omni and PureTryOut about x86
2023-10-03 10:33:19 <donoban> t
2023-10-03 10:53:31 <PureTryOut> What about x86 that you need an opinion for?
2023-10-03 10:55:38 <Newbyte> Say package B is installed on a system, and package A replaces package B. When package A gets installed, the conflicting files from B will be replaced in favour of the ones from A, right? But what happens if package B then gets upgraded? Does the conflicting files from package A then get replaced by the ones from package B?
2023-10-03 11:11:35 <ikke> Newbyte: I think package A will own those files, so either a conflict, or APK will silently ignore those files from package B
2023-10-03 14:28:10 <bl4ckb0ne> is it possible to run something after ctest failure?
2023-10-03 14:28:45 <bl4ckb0ne> the fail makes abuild stop there
2023-10-03 14:29:40 <ikke> append || true
2023-10-03 14:30:14 <ikke> It's set -e that causes it to stop
2023-10-03 14:30:29 <bl4ckb0ne> ahh thats why
2023-10-03 14:31:13 <bl4ckb0ne> thanks
2023-10-03 17:14:38 <craftyguy> is there a precedent in Alpine for packaging 32-bit libraries for a x86_64 target? other distros use /usr/lib32, but that doesn't exist on Alpine
2023-10-03 17:16:44 <Hello71> how will you run them
2023-10-03 17:17:05 <craftyguy> the reason I have for doing this is for being able to build 32-bit firmware for some x86_64 systems that need it. it requires 32-bit support in gnu-efi, it's relatively easy to build this for gnu-efi but I need some sane place to drop the 32-bit libs that doesn't conflict with the 64-bit libs this package already provides
2023-10-03 17:21:31 <Hello71> /usr/lib/gnu-efi/32?
2023-10-03 17:22:04 <craftyguy> ya I was experimenting with that. would that be acceptable?
2023-10-03 17:22:25 <Hello71> since they're not multilib ELFs, they shouldn't go in /usr/lib32 anyways
2023-10-03 17:23:08 <craftyguy> ok
2023-10-03 17:23:17 <craftyguy> I saw debian dumped them there. /shrug 
2023-10-03 17:23:21 <Hello71> seems like it
2023-10-03 17:24:37 <Hello71> but neither /usr/lib nor /usr/lib32 are right for debian, it should be /usr/lib/x86_64-linux-gnu
2023-10-03 21:38:58 <ptrc> ERROR: python3-pycache-pyc0-3.11.5-r0: BAD archive
2023-10-03 21:39:02 <ptrc> does anyone else also get that
2023-10-04 05:58:44 <bratkartoffel> New CVE (Local Privilege Escalation) in glibc detected, alpine with musl was mentioned ("one notable exception is Alpine Linux, which uses musl libc, not the glibc"). Interesting description on the issue: https://www.qualys.com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt
2023-10-04 05:59:07 <bratkartoffel> So once again a broken glibc and secure alpine, good to hear
2023-10-04 07:25:55 <vkrishn> which is preferred tool for getting letsencrpt certs, acme, certbot ?
2023-10-04 07:27:17 <vkrishn> new version of acme-client does not have -a opt, as in https://wiki.alpinelinux.org/wiki/Nginx_as_reverse_proxy_with_acme_(letsencrypt)#Automatic_generation_of_certificates
2023-10-04 08:11:59 <caskd[m]> I personally use acme.sh and it works pretty well
2023-10-04 08:12:48 <caskd[m]> however you have to override the certificate source to letsencrypt first time, else it would use zerossl by default which doesn't support as much for free
2023-10-04 08:20:43 <dne> 
ACTION currently prefers lego

2023-10-04 08:22:56 <vkrishn> thanks
2023-10-04 08:33:39 <vkrishn> apk info lego -> installed size 70 MiB
2023-10-04 09:00:12 <dne> too many dns validation plugins :)
2023-10-04 09:06:25 <vkrishn> :-) noticed
2023-10-04 12:51:41 <jiinin> How do i learn in-depth of alpine linux?
2023-10-04 12:51:51 <jiinin> i am new to linux but i know profgramming
2023-10-04 13:57:33 <bl4ckb0ne> getting a lot of 413 when uploading artifacts for the mold MR, have I reached a threshold? 
2023-10-04 14:55:11 <j_v> my mr is stuck on s390x pipeline, but this aport only supports x86_64, x86, armv7, and aarch64... is it ok to skip/cancel the pipeline for s390x?
2023-10-04 14:56:22 <j_v> hmmm, need to look into enabling armhf
2023-10-04 15:01:33 <ikke> j_v: yes, there is an issue atm with ci for that arch
2023-10-04 15:02:52 <j_v> ikke: thanks
2023-10-04 15:21:39 <ikke> bl4ckb0ne: not sure if it helps, but did you try to tar the directory?
2023-10-04 16:10:11 <bl4ckb0ne> havent thought about that, I already put a case to only store the artifacts if a certain condition is met, maybe I pressed on "keep" too many time. Can I do a manual cleanup?
2023-10-04 16:41:47 <j_v> would building in a qemu-user chroot be close enough for initially testing builds on different architectures? or would full vm be more appropriate?
2023-10-04 16:42:06 <ikke> for most cases it should suffice
2023-10-04 16:42:11 <ikke> our rv64 port is built that way
2023-10-04 16:42:43 <j_v> ok, thanks.
2023-10-04 16:49:51 <j_v> that reminds me that i need to build my nsjail port for riscv64... i've noticed other aports being updated, notes saying textrels no longer an issue. that has been the sticking point, but haven't checked on it in a while.
2023-10-05 04:34:37 <_see-ed> https://www.youtube.com/watch?v=sqSA-SY5Hro
2023-10-05 04:34:37 <_see-ed> I wish politicians would look out for miners
2023-10-05 04:34:38 <_see-ed> And not just minors on an island somewhere
2023-10-05 04:34:38 <_see-ed> Lord, we got folks in the street, ain’t got nothin’ to eat
2023-10-05 04:34:39 <_see-ed> And the obese milkin’ welfare
2023-10-05 04:34:39 <_see-ed> irc.supernets.org #superbowl
2023-10-05 04:34:40 <_see-ed> _see-ed Adahehim[m] cuiltb^ enzo_2945[m] kaey[m] tiddlypom[m] smcavoy minecrell scottmax[m] Guest2203 JohannesJ[m] ichernev[m] Daanct12 PureTryOut vyivel knuxify[m] blakes somercet1 donoban Danct12 Metroid vkrishn adhawkins GNUmoon2 Piraty dari miostreams iXNyNe661440 graywolf bdju linuxgemini0 maria afofu invoked mid markand an3223_ dionisis orbea khem veecue skarnet Arnavion tobikoch rvalue 
2023-10-05 04:34:40 <_see-ed> artok okeuday QDX45 Misthios RootWyrm cultpony timlegge zcrayfish Job797 xordspar0 veremitz asriel sto Forza tru_tru paddymahoney nepeat Hello71 Xe indy corysanin teiresias pabloyoyoista eleksir linear_cannon terrorjack5483 eschwartz bunny midasi itaipu gabrielgio earboxer exprez135 ajhalili2006 sm2n c7s micahrl WhyNotHugo dekedro humm gjabell ashpool aparcar shinobi57474858 staceee jay 
2023-10-05 04:34:41 <_see-ed> funspectre psnszsn raiaq tobtobxx consus srhm Guest1249 jopes tomleb cat eddsalkield fmac anjan swapgs handlerug elibrokeit dwu02 no-ra lattis renato0307 craftyguy lmarz apangona dne wener GreyDev mercenary Reinhilde Ttech fossy dalias tmlind eletrotupi riverdc_ tbodt d0nk` mokou lel bandali zv fluix copy dove dannyAAM mla that_guy duncaen ayakael ahills Ariadne ajaso codingkoopa32 croc_ noptys_ 
2023-10-05 04:34:43 <_see-ed> drakonis alhassanaraouf tarxvf mcf kylie lucidiot bleb abby iskm elly Ekho daikojun deflated8837 utsweetyfish moat sam_ colona alexeymin lotheac eloy_ algitbot danieli ncopa guddaff clandmeter ikke quintasan Arsen mallory bl4ckb0ne emersion Johnnynator cedric ptrc tomalok DLange kpcyrd omni crazymax fossdd proycon quinq paper_ Shiz fcolista ofage mio EvTheFuture knolle kunkku jstoker 
2023-10-05 04:34:51 <Daanct12> noice
2023-10-05 04:35:32 <Daanct12> (talking about the gline
2023-10-05 06:40:57 <ikke> bl4ckb0ne: in your fork, under the build section, there should be an artifacts item 
2023-10-05 09:12:37 <donoban> ohh, i was mentioned, ouch :\
2023-10-05 09:30:14 <ikke> High severity curl vulnerability anounced
2023-10-05 09:30:53 <ikke> https://github.com/curl/curl/discussions/12026
2023-10-05 09:31:21 <ikke> Release on Oct 11
2023-10-05 13:08:17 <bl4ckb0ne> ikke: oh no there the build artifacts from all my pipelines and I can only delete 20 at the time
2023-10-05 13:08:35 <bl4ckb0ne> anyway the mold dev labeled the bug as "broken in musl" so the artifact pipeline adventure stops there
2023-10-05 13:08:42 <ikke> lesigh
2023-10-05 13:09:21 <bl4ckb0ne> im a tad happy, it took a good chunk of time getting those things
2023-10-05 14:17:48 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1134513 weird pipeline issue, builds fine on my end
2023-10-05 14:21:12 <ikke> robin-hood-hashing is in testing
2023-10-05 14:21:19 <ikke> so not available for packages in community
2023-10-05 14:21:45 <bl4ckb0ne> ohhh right
2023-10-05 14:21:49 <bl4ckb0ne> shall I move it as well?
2023-10-05 14:22:28 <ikke> It doesn't have a maintainer atm, do you want to adopt it?
2023-10-05 14:22:38 <bl4ckb0ne> sure
2023-10-05 14:24:00 <bl4ckb0ne> should've read more throughouly the error, sorry
2023-10-05 14:24:05 <ikke> No problem
2023-10-05 14:24:08 <ikke> they can be confusing some times
2023-10-05 14:24:43 <bl4ckb0ne> doing 4 things at the same time is not good for noticing error causes
2023-10-05 14:24:51 <ikke> hehe
2023-10-05 14:25:39 <bl4ckb0ne> gah and the mold update still is still ICE'ing llvm
2023-10-05 20:59:54 <pj> hi ncopa, how is llvm17 going?
2023-10-05 21:10:26 <andypost[m]> pj: one test failed  !51171
2023-10-06 05:37:19 <ncopa> good morning!
2023-10-06 05:37:53 <ncopa> pj: I was thinking of revert one upstream llvm commit to get that test pass
2023-10-06 05:38:21 <ncopa> but waiting for comment on https://github.com/llvm/llvm-project/issues/66776
2023-10-06 05:43:22 <indy> hi all, secdb jsons are generated from other source or how it is updated?
2023-10-06 05:48:28 <ikke> They are extracted from aports
2023-10-06 05:50:55 <pj> ncopa: ah great, it seems that the issue is being handled then, just wanted to ask if youre going to use 17.0.2 since its released on 3 Oct
2023-10-06 05:52:03 <pj> I will need llvm17 for rust 1.73
2023-10-06 07:30:28 <staceee> hey there o/ dumb_runtime_dir require for /run/user to be created first for it to works. I'd like to make it to works ootb. What would be the best way? I tried a fstab entry, it works but I'd like a less intrusive change
2023-10-06 07:30:59 <staceee> something I could apply upstream
2023-10-06 07:31:26 <staceee> I also think about a dedicated service, but maybe someone already could do this?
2023-10-06 07:36:52 <ncopa> i updated my desktop machine hardware. Now chromium shows artifacts in lounge IRC client
2023-10-06 07:37:38 <ikke> ncopa: shader cache?
2023-10-06 07:38:15 <ncopa> i tried to delete ~/.config/chromium/Default/GPUcache, but it does not help
2023-10-06 07:39:15 <ncopa> only observed it in lounge so far
2023-10-06 07:39:38 <ncopa> also, i dont know if it related the recent libx11 updates
2023-10-06 07:56:30 <pj> andypost: sorry, didn't noticed your message and that you made the PR
2023-10-06 07:58:06 <pj> maybe we could coordinate effort since there are 2 PRs !52371 !51171
2023-10-06 08:47:20 <ptrc> staceee: i'd say they should just create the directory if it doesn't exist
2023-10-06 08:59:08 <staceee> ptrc: you mean the pam library itself? dumb_runtime_dir explain in its readme that this is up to the user to ensure this exists
2023-10-06 08:59:27 <staceee> I could open a ticket in their repo to see if they would agree with that 
2023-10-06 09:05:17 <staceee> I openned this ticket
2023-10-06 09:09:02 <ikke> /run is more often than not a volatile directory. I don't think anything should assume files/directories exist 
2023-10-06 09:09:46 <ncopa> pj: I opened that draft mainly to run the tests on all architctures.
2023-10-06 09:47:38 <omni> oh-no
2023-10-06 09:51:31 <omni> !52868
2023-10-06 10:21:47 <ikke> omni: sounds like py3-typing-extensions needs to be added
2023-10-06 10:30:33 <omni> thanks
2023-10-06 10:37:25 <donoban> ey omni , what do you think about disabling x86 for qutebrowser? !52466
2023-10-06 10:38:45 <donoban> if you prefer I can try to build it, other distros do it, but it could be hard to maintain and backport sec fixes
2023-10-06 10:45:11 <omni> donoban: I don't use it on 32b x86 myself but my gut feeling doesn't like the idea of disabling it..
2023-10-06 10:45:42 <omni> so I'm a bit undecided, why I haven't replied yet, sorry
2023-10-06 10:46:34 <donoban> well, it seems disabled on chromium
2023-10-06 10:54:54 <omni> I think qutebrowser has a nerdier tartget audience
2023-10-06 10:55:29 <omni> and we package many aports for more architectures than upstreams say they support
2023-10-06 10:55:47 <ikke> if feasible
2023-10-06 10:56:29 <donoban> ok, let's try it :D
2023-10-06 10:56:31 <omni> sure
2023-10-06 10:57:48 <omni> I had another comment that is more important to me, the ability to "easily" do chromium security upgrades of the qtwebengine aport
2023-10-06 11:00:57 <donoban> yeah, hopefully is not too much different from x64
2023-10-06 13:19:16 <omni> I just tried selecting a process in btop and sending a signal to the selected pid, but then that signal seem to be sent to the btop pid instead
2023-10-06 14:15:54 <nmeum> what's our stance on merging non-obvious busybox patches which have not been integrated upstream yet?
2023-10-06 14:16:24 <nmeum> !52406 changes/fixes the behavior of `find -xdev` but I am not sure if it will get accepted upstream
2023-10-06 14:25:54 <donoban> wow, I didn't know it, looks great this btop
2023-10-06 14:30:41 <donoban> omni: it seems working fine for me 
2023-10-06 15:01:04 <ikke> nmeum: ideally we try to avoid it if possible
2023-10-06 15:01:04 <ncopa> nmeum: that patch looks ok. Its also surprising that upstream does not respond to it, give it reduces size
2023-10-06 15:01:13 <ikke> lol
2023-10-06 15:01:17 <ncopa> it fixes a bug
2023-10-06 15:01:44 <ncopa> i think it qualifies a exception from "ideally we try to avoid it if possible"
2023-10-06 15:02:06 <ncopa> and its a pretty nasty bug
2023-10-06 15:02:15 <ncopa> so i thikn we should take it
2023-10-06 15:02:20 <ncopa> and maybe ping upstream
2023-10-06 15:02:27 <ikke> right
2023-10-06 16:12:57 <omni> donoban: I'm not sure what happens, but it seems like it's sending the signal to another process than the one I thought I selected
2023-10-06 16:13:34 <omni> it works if I first filter processes so that I only show the one I want to, for example, kill
2023-10-06 16:14:08 <omni> then pop open the signals dialog
2023-10-06 16:14:22 <omni> but it is bery nice, btop
2023-10-06 16:14:36 <donoban> uhm, I tested with a filter 
2023-10-06 16:14:49 <donoban> was comparing htop/btop with 'top' filter and killed htop 
2023-10-06 16:39:27 <omni> maybe I'm doing something wrong, but I (actually) reported it upstream anyways
2023-10-06 16:39:38 <omni> 
ACTION pats self on back

2023-10-06 16:46:18 <donoban> hehe, just tested without fitlter and also worked fine
2023-10-06 16:59:25 <nmeum> ncopa: alright, thanks for taking a closer look!
2023-10-06 17:36:37 <elly> chromium gpu behavior has gotten really bad recently and I am unsure how to diagnose or fix it
2023-10-06 17:36:43 <elly> lots of blank tiles in pages and blank areas
2023-10-06 17:36:49 <elly> --disable-gpu fixes it fully
2023-10-06 18:19:44 <orbea> elly: is it specific to certain drivers or types of gpu?
2023-10-06 18:20:21 <orbea> might be worth making sure its not fixed in newer kernels or the mesa git already
2023-10-06 18:34:15 <elly> orbea: I don't know... I wish I did
2023-10-06 18:34:20 <elly> it is, at least, common on my own laptop :P
2023-10-06 18:58:04 <elly> hum, trying to package something that has no actual release tarballs and makes heavy use of submodules
2023-10-06 18:58:38 <elly> I can't really have the APKBUILD do a bunch of git clones to get the submodules, and I'd really rather not bake the hashes of all the submodules (and URLs to get them from) into the APKBUILD
2023-10-06 18:58:46 <elly> maybe I'll ask upstream to make release tarballs >:)
2023-10-06 19:42:03 <orbea> elly: good luck, very few projects came through for me when I asked similar
2023-10-06 19:53:08 <elly> yeah... well, we'll see
2023-10-06 19:53:20 <elly> currently trying to get chromium to build with enable_rust=true, but I don't think it's happening... it appears to *require* rust nightly
2023-10-06 19:54:40 <elly> it simply won't work with a stable rust, which is irritating
2023-10-06 19:55:13 <orbea> sounds more painful than its worth it
2023-10-06 19:55:34 <elly> unfortunately it will probably become mandatory at some point
2023-10-06 19:55:38 <elly> to build chromium
2023-10-06 19:55:42 <elly> so I'm trying to get ahead of that
2023-10-06 19:56:39 <orbea> yea, but if it requires rust nightly then probably not ready for distros
2023-10-06 19:57:48 <elly> yeah, maybe not
2023-10-06 19:57:49 <elly> ah well
2023-10-06 19:58:16 <elly> it looks like it might work, at least :)
2023-10-07 11:17:42 <donoban> I'm trying to fix some tests on tiledb-x86 https://tpaste.us/8MzW
2023-10-07 11:18:45 <donoban> it builds fine if I add a cast to uint64_t but would be better to define buffer_sizes as size_t ? , maybe adding a cast to size_t too
2023-10-07 17:06:15 <elly> hm, mesa update seems to have unscrewed chromium graphics for me
2023-10-07 18:21:45 <JellyWasCoding> Hello guys!
2023-10-07 19:36:17 <fluix> o/
2023-10-08 06:27:46 <ikke> c-ares 1.20.0 released https://c-ares.org/changelog.html
2023-10-08 08:38:19 <PureTryOut> any reason why armv7 builders fail to start xvfb-run? 🤔
2023-10-08 16:20:30 <ikke> PureTryOut: sometimes an instance keeps hanging and the port is occupied
2023-10-08 16:21:45 <PureTryOut> seems to only happen on armv7, and happened quite constantly today...
2023-10-08 16:21:59 <ikke> yes, it will keep failing until the process has been killed
2023-10-08 16:22:09 <ikke> I don't know why it happens, I just see that it does
2023-10-08 16:22:38 <ikke> It passed right after I killed the process
2023-10-08 16:28:46 <PureTryOut> Strange
2023-10-08 16:28:52 <ikke> I've seen it once before
2023-10-08 20:46:26 <Ermine> Is it correct that udev sets mode 620 mode on tty devices?
2023-10-08 20:47:29 <Ermine> i.e. group can only write to it, but not read
2023-10-08 20:51:34 <elly> yep!
2023-10-08 20:51:45 <elly> that's how write(1) can work without letting other users read your terminal
2023-10-08 20:57:29 <Ermine> But then X cannot open it with eacces
2023-10-08 20:59:21 <elly> why not? Xorg should be running as you, and you should own your tty
2023-10-08 21:01:52 <Ermine> it does, and it fails. In Xorg logs in my .local/share/xorg, it reports that it cannot open /dev/tty7, with "permission denied"
2023-10-08 21:02:12 <Ermine> it is launched through gdm btw
2023-10-08 21:02:50 <Ermine> if I chmod g+r, Xorg launches
2023-10-08 21:05:33 <elly> do you own /dev/tty7?
2023-10-08 21:05:54 <elly> on my system, my user only owns /dev/tty1 (which is the one I logged in on)
2023-10-08 21:06:50 <elly> it seems like if /dev/tty7 is your session, you should own it, and if you own it the perms for the tty group won't matter
2023-10-08 21:09:14 <Ermine> I don't think so
2023-10-08 21:09:41 <Ermine> I didn't log in anywhere, since gdm was started by openrc
2023-10-08 21:10:07 <elly> hum
2023-10-08 21:10:19 <elly> normally seatd or policykit or something are supposed to change the ownership for you I think?
2023-10-08 21:11:14 <Ermine> I should check then if polkit is running
2023-10-08 21:14:58 <elly> polkitd I think but I am pretty out of my depth here
2023-10-08 21:15:25 <elly> for my system, I log in on tty1, login (I think?) or getty changes ownership of it to me, then I `exec startx` from there
2023-10-09 06:36:11 <PureTryOut> does replaces require to also specify the pkgrel? It doesn't seem to work for any kde frameworks package (karchive5 as an example)
2023-10-09 08:36:34 <PureTryOut> also abuild (rootbld) seems to completely ignore my JOBS setting in ~/.abuild/abuild.conf
2023-10-09 08:46:01 <PureTryOut> (I've set it to 4 parallel jobs but it just takes up the full CPU anyway)
2023-10-09 08:51:13 <donoban> it seems that it only passes /etc/abuild.conf
2023-10-09 08:52:11 <PureTryOut> I also have export JOBS=4 in there but it still seems to be ignored. I added a line without the export as well, I'm not sure when that is or isn't needed...
2023-10-09 08:52:51 <donoban> probably it needs a explicit --setenv on bwrap call
2023-10-09 08:53:17 <donoban> or you can try removing --clearenv
2023-10-09 09:05:24 <donoban> building qtwebengine on x86 fails due data aligns to 4 bytes and protobuf forces at least 8 bytes, is there some way for configure it?
2023-10-09 09:08:51 <donoban> I'm looking at protobuf/APKBUILD, but it seems that it uses gcc while qtwebengine/chromium uses clang
2023-10-09 09:17:07 <donoban> probably it's similar to 94bd1b9446f8e59d3e69a9844b65b27023207c02
2023-10-09 09:22:02 <donoban> all the issues remain opened :\
2023-10-09 10:02:46 <donoban> any clue here https://tpaste.us/z5Lw ? does it miss -latomic?
2023-10-09 21:11:22 <z3ntu> Can somebody unflag vkmark package? https://pkgs.alpinelinux.org/packages?name=vkmark&branch=edge&repo=&arch=&maintainer= The only tag in this project is from 2017 so it's not really worth trying to include this in pkgver I think, some newer commit is packaged here
2023-10-10 00:32:42 <fluix> z3ntu: you can just ignore the flag, it's not something to easily undo (requires direct database queries for now). however, isn't the flag because there have been 6 more commits since?
2023-10-10 01:37:01 <celie> z3ntu: I see you closed !53085. Actually, i wouldn't mind closing my MR instead if you could get the tests to pass (or if you determine that it's ok they fail and disable them).
2023-10-10 01:44:06 <celie> a16bitsysop: I think chereskata got the patches wrong for apache-arrow, as from what i see (and i may be wrong, or missed something), those patches do not fix the problem, but merely pins the version of setuptools_scm to <8.0.0, and that does not really work, because we already have 8.0.4 in the repo
2023-10-10 01:51:21 <celie> I was following that write_to error (and i think i mentioned it to you here). My impression is that !52573 fixed it. I had https://github.com/pypa/setuptools_scm/pull/935 applied in !52573, but 8.0.4 came out with those changes included before !52573 was merged, and so i just changed it to an upgrade.
2023-10-10 01:52:46 <celie> Oops, sorry for making algitbot repeat itself
2023-10-10 07:36:47 <aparcar1> Hey all. Can i find somewhere more information on the buildbot setup? Specifically if I want to build packages for a new architecture
2023-10-10 08:52:43 <ncopa> aparcar1: I dont think we have that documented anywhere
2023-10-10 08:53:36 <ncopa> but in short: use ./scripts/bootstrap.sh to crosscompile the toolchain for new arch
2023-10-10 08:55:20 <ncopa> then you will have to manually bootstrap aports. I usually do that by running something like: for i in $(ap recursdeps buildbase); do (cd $i && abuild -rk)|| break; done
2023-10-10 08:56:21 <ncopa> once aports is bootstrapped i start mqtt-exec.aports-build service to connect it for auto-building
2023-10-10 08:56:36 <ncopa> aparcar1: what architecture are you thinking of?
2023-10-10 09:06:48 <aparcar1> ncopa all of these https://downloads.openwrt.org/snapshots/packages/
2023-10-10 09:06:54 <aparcar1> Thanks I’ll have a look! 
2023-10-10 09:09:31 <ncopa> we dont have that many architectures, so the process is not as streamlined as openwrt
2023-10-10 09:10:00 <ncopa> and we dont really support corsscompiling of the entire repo, just the toolchain
2023-10-10 09:10:13 <ncopa> we build all the packages natively, so we can run the unit tests
2023-10-10 09:24:55 <aparcar1> ncopa: there is no way to really cross compile a package locally for testing? say on my local machine to then push it to some other device?
2023-10-10 09:33:59 <ncopa> well, you can, but it is not really supported so packages may need patches
2023-10-10 09:34:19 <ncopa> the only packages we actually do crosspiling for is the toolchain only
2023-10-10 09:35:07 <ncopa> i would expect many of the packages will work, but we dont test it
2023-10-10 09:37:17 <aparcar1> native compiling isn't feasible on many archs, so openwrt sticks to cross
2023-10-10 09:37:41 <aparcar1> I'm mostly interested in lowering the burden on maintaining so many packages and since alpine already uses musl and busybox, it's a close match
2023-10-10 11:11:37 <aparcar1> ncopa: can you help me out here? i don't understand why this would fail
2023-10-10 11:11:37 <aparcar1> https://paste.debian.net/1294598/
2023-10-10 11:13:06 <ncopa> it looks for a package gcc-pass2-aarch64-unknown-linux-musl which is not found
2023-10-10 11:13:47 <ncopa> it appears to build the package gcc-pass2-aarch64
2023-10-10 11:14:25 <ikke> aws-c-io segfaults during some tests 
2023-10-10 11:14:34 <ikke> on x86_64 on the builders
2023-10-10 12:41:19 <ncopa> im starting to bootstrap aports for 3.19 builders
2023-10-10 12:44:46 <Ermine> how do I ship custom udev rules with package?
2023-10-10 12:52:01 <aparcar1> ncopa: is cross building tested for x86 hosts only?
2023-10-10 13:07:37 <minimal> Ermin: you put the files in /usr/lib/udev/rules.d/ directory like many other packages do? (i.e. mdadm-udev, bladerf, modemmanager, etc)
2023-10-10 13:08:18 <minimal> or /lib/udev/rules.d/, I don't remember the distinction between the 2 directories
2023-10-10 14:18:47 <Ermine> minimal: I made a subpackage and added install_if="udev". I guess that should do
2023-10-10 14:22:58 <minimal> Ermine: I'd guess that should be install_if="udev $pkgname=$pkgname-r$pkgrel"
2023-10-10 14:24:24 <Ermine> you mean = $pkgver-r$pkgrel?
2023-10-10 14:25:01 <minimal> oops, yeah ;-)
2023-10-10 14:43:35 <lucidone> Requesting feedback on 'Unlock encrypted root partition via smart card' https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/134
2023-10-10 16:34:31 <dhruvin> Does `apk add` reset ownership of the package contents after running its post-install script?
2023-10-10 17:15:28 <dhruvin> Yes, it updates directory ownership in `apk_db_update_directory_permissions`.
2023-10-10 18:33:10 <hjaekel> My new package builds on all platforms except armhf. On armhf I get the error message "Assembler messages: /tmp/cciIBNlE.s:273: Error: bad immediate value for offset (4096)". Any idea how I can fix this?
2023-10-10 18:59:03 <Newbyte> <hjaekel> "My new package builds on all..." <- you could just disable armhf and leave a comment explaining why it's disabled ´
2023-10-10 18:59:07 <Newbyte> unless you need it on armhf
2023-10-10 19:02:56 <hjaekel> That is always the last resort. I wanted to ask before i'm missing something obvious
2023-10-10 19:04:30 <elly> well, it sounds like chromium is going to depend on nightly-or-later rust for the foreseeable future
2023-10-10 19:04:46 <elly> I think I may need to start building that rustc as part of the chromium build :|
2023-10-10 19:05:08 <elly> it's apparently already there in //third_party/rust-src
2023-10-10 19:08:26 <ikke> Ugh
2023-10-10 19:08:41 <ikke> That's so annoying 
2023-10-10 19:09:19 <elly> indeed... I'll try hacking it up and seeing how bad the damage is
2023-10-10 19:09:34 <elly> they aren't going to start depending on stable rustc any time soon, and it's not like we can use prebuilt binaries
2023-10-10 19:19:03 <elly> what is offensive is that we will still need the dep on stable rustc so it can be used to compile the unstable rustc in the tree :(
2023-10-10 19:22:32 <skarnet> but but self-hosting languages are the BEST
2023-10-10 19:23:22 <elly> it's self-hosting languages all the way down, in some sense
2023-10-10 19:23:32 <elly> I wonder if the firefox package is simpler...
2023-10-10 19:29:47 <khem> heh, chromium, dont you build its own version of clang already ?
2023-10-10 19:30:11 <khem> it vendors everything it needs 
2023-10-10 19:32:57 <ptrc> no
2023-10-10 19:33:08 <elly> we do not do that
2023-10-10 19:33:13 <elly> although we *could*, apparently it is vendored
2023-10-10 19:33:30 <elly> when I asked the build team about this they expressed mild surprise that it works when not built with head clang
2023-10-10 19:34:06 <khem> in yocto we have long term releases and the version of clang locked to the LTS is now old for modern chromium, we can barely get it compiling with clang 14 
2023-10-10 19:34:16 <elly> indeed
2023-10-10 19:34:34 <elly> chromium is built upstream against specific clang/rustc revisions and anything that isn't those revisions is like, good luck
2023-10-10 19:35:19 <khem> right, so its quite a bit for distros to maintain system dependencies unless its a rolling release 
2023-10-10 19:35:47 <elly> borderline impossible, in fact
2023-10-10 19:36:05 <elly> so maybe the right answer *is* to build the vendored clang/rustc and surrender to the monolith
2023-10-10 19:53:15 <ikke> suddenly it takes half a day to build chromium
2023-10-10 19:57:18 <elly> what do you mean "suddenly"
2023-10-10 19:57:39 <elly> when you start a clean chromium build, you have plenty of time to do some other activity, like make a sandwich, or learn a foreign language
2023-10-10 19:57:45 <ikke> heh
2023-10-10 20:10:14 <khem> I remember androids build command is called 'lunch' maybe for this reason :)
2023-10-10 21:04:32 <RootWyrm_> hjaekel: which package? I can take a quick look probably
2023-10-10 21:09:18 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/53080
2023-10-10 21:27:05 <hjaekel> RootWyrm_ the error is in !53080
2023-10-10 21:40:21 <khem> Ikke: this looks compiler issue to me constant pool is placed too far in assembly file may be try using O2 instead of Os
2023-10-10 21:45:18 <RootWyrm_> ah-ha, gcc... can it be tried with clang 8.0.1?
2023-10-10 21:46:16 <sam_> ... clang 8? lol
2023-10-10 22:28:36 <minimal> isn't Rust like Klingon Software Development...."we don't release our software, it escapes leaving a trail of bodies in its wake" ;-)
2023-10-10 22:37:00 <RootWyrm_> sam_, yeah, i know.
2023-10-10 22:37:30 <sam_> i don't get why you're suggesting it
2023-10-10 22:40:47 <RootWyrm_> because https://reviews.llvm.org/D56571
2023-10-10 23:04:38 <invoked> cement truck overturned off chiles road
2023-10-10 23:06:21 <invoked> (wrong window)
2023-10-10 23:08:15 <bl4ckb0ne> nice password 
2023-10-10 23:13:48 <invoked> live long doorknob
2023-10-10 23:14:33 <invoked> i've got a fever going. (true story.)
2023-10-10 23:20:36 <bl4ckb0ne> all hail doorknob
2023-10-11 07:27:33 <Piraty> APKBUILD doesn't have a concept of revert= but instead apk will figure out if package was downgraded on the repo index?
2023-10-11 07:27:59 <Piraty> so downgrading pkgver in APKBUILD is sufficient? not even bumping pkgrel ?
2023-10-11 07:28:55 <Piraty> some commits in aports increase pkgrel, some don't ...
2023-10-11 07:29:04 <Piraty> (when downgrading )
2023-10-11 07:31:22 <ikke> Piraty: that's for the cdn 
2023-10-11 07:35:59 <ikke> Piraty: normally apk only upgrades packages. To get downgrades, users must provide --available
2023-10-11 07:36:54 <Piraty> so how to go about reverting a broken version on user systems with the usual upgrade workflow?
2023-10-11 08:58:40 <quinq> Piraty, I guess install the not-broken version explicitely
2023-10-11 08:59:31 <quinq> (something like: apk add $package=$version)
2023-10-11 09:02:16 <ikke> That would always pin it to that version 
2023-10-11 09:02:29 <ikke> So later upgrades will never upgrade that package 
2023-10-11 09:03:09 <quinq> Yes, when this is fixed you can unpin it
2023-10-11 09:05:41 <quinq> Is it possible to pin to a ≠ version?
2023-10-11 09:05:58 <quinq> like $package~=$version
2023-10-11 10:49:51 <Habbie> ERROR: 'h2o-dev>=2.2.6-10' is not a valid child dependency, format is name([<>~=]version)
2023-10-11 10:50:03 <Habbie> ERROR: 'h2o-dev(>=2.2.6-10)' is not a valid child dependency, format is name([<>~=]version)
2023-10-11 10:50:05 <ikke> Habbie: r10
2023-10-11 10:50:08 <Habbie> ah
2023-10-11 10:50:13 <ncopa> what is -10?
2023-10-11 10:50:25 <ncopa> is it build revision?
2023-10-11 10:50:31 <ncopa> eg build config changed
2023-10-11 10:50:42 <Habbie> r10 is right, thanks
2023-10-11 10:50:59 <ncopa> or is it an upstream patch version? (eg the -10 is change in upstream sources)
2023-10-11 10:51:17 <Habbie> r10 is a single patch import on the same upstream version
2023-10-11 10:51:22 <Habbie> h2o hasn't had upstream releases in years
2023-10-11 10:51:34 <ncopa> ok. then -r10 sounds correct
2023-10-11 10:51:40 <Habbie> sadly it breaks ABI
2023-10-11 10:51:49 <Habbie> but i maintain the only package that needs it (dnsdist) as well
2023-10-11 15:24:07 <ncopa> seems like sqlite upstream source changed
2023-10-11 15:24:11 <ncopa> checkum change
2023-10-11 15:24:19 <ncopa> does anyone have a copy of the old source?
2023-10-11 15:24:27 <ncopa> I'd like to diff it
2023-10-11 15:24:53 <Habbie> 3.43.2?
2023-10-11 15:25:30 <elly> I believe I do, ncopa
2023-10-11 15:25:37 <ikke> http://distfiles.alpinelinux.org/distfiles/edge/sqlite-autoconf-3430100.tar.gz
2023-10-11 15:25:49 <elly> oh, I have the old apks rather
2023-10-11 15:26:53 <ncopa> ikke: thanks!
2023-10-11 15:26:56 <ikke> sqlite-autoconf-3430100/tea/configure changed
2023-10-11 15:27:04 <Habbie> looks like they accidentally put 3.43.0 in tea/configure
2023-10-11 15:27:09 <ikke> yeah
2023-10-11 15:27:14 <Habbie> so, harmless
2023-10-11 15:27:17 <Habbie> but bad policy
2023-10-11 15:27:23 <ikke> it happens all the time
2023-10-11 15:27:27 <Habbie> i know :(
2023-10-11 15:28:19 <elly> people update their release tarballs without changing the version number? gross
2023-10-11 15:28:25 <ikke> yup
2023-10-11 15:28:39 <ncopa> yup.. thast why we keep the checksum
2023-10-11 15:29:01 <ikke> and mirroring on distfiles helps with that as well
2023-10-11 15:29:37 <ncopa> it does indeed
2023-10-11 15:29:55 <ncopa> oh. they forgot to bump the version string
2023-10-11 15:29:59 <ikke> yes
2023-10-11 15:30:57 <skarnet> true story: I once ninja updated a release tarball, very shortly after the first release, before the announce, thinking, this isn't widely known software, and it was fast enough, nobody will notice
2023-10-11 15:31:08 <skarnet> spoiler: somebody noticed
2023-10-11 15:31:12 <ncopa> lol
2023-10-11 15:31:27 <ncopa> i've been there as well
2023-10-11 15:31:38 <ncopa> but in my case i think nobodya actually noticed :)
2023-10-11 15:32:04 <skarnet> lucky you, you didn't have to do a full new release :D
2023-10-11 15:32:17 <elly> "I'll just git push -f to get rid of that, surely nobody pulled in that short interval"
2023-10-11 15:32:31 <ncopa> ha
2023-10-11 15:34:27 <ikke> ncopa: I suppos I now need to move the original source on distfiles :p
2023-10-11 15:34:55 <ncopa> i thought abuild will rename it on first try
2023-10-11 15:35:05 <ncopa> and fetch a new on second
2023-10-11 15:35:10 <ikke> yes, but it will keep downloading it from distfiles
2023-10-11 15:35:19 <ncopa> oh, right
2023-10-11 15:35:20 <minimal> ncopa: when you get a chance can you have a look at !53133? I'd like to get this sorted in time for the 3.19 release
2023-10-11 15:35:32 <elly> when's 3.19?
2023-10-11 15:35:46 <ikke> somehwere november
2023-10-11 15:35:46 <ncopa> November
2023-10-11 15:36:02 <ncopa> minimal: I had a look at it, but I'm not sure its a good idea to be honest
2023-10-11 15:36:06 <elly> is there a schedule for releases or is it more vibes based?
2023-10-11 15:36:07 <ncopa> i also looked what fedora does
2023-10-11 15:36:19 <minimal> ncopa: have you any alternative suggestions then?
2023-10-11 15:36:19 <ncopa> and they dont re-install grub
2023-10-11 15:37:03 <ncopa> i think we should maybe just document it, if you use grub on aarch64 and upgrade from alpine 3.18 -> 3.19, you need to regenerate grub
2023-10-11 15:37:11 <minimal> ncopa: so how does Fedora update the boottime Grub code upon Grub package update then?
2023-10-11 15:37:24 <ncopa> minimal: from what I could see, they don't
2023-10-11 15:37:31 <ncopa> only regenerate the grub config
2023-10-11 15:37:45 <ncopa> i dont think anybody update grub code
2023-10-11 15:38:25 <minimal> ncopa: aarch64? It's not an issue specific to that arcbut if the grub config is regenerating after installing a new version then the system may not boot afterwards (if the generated config relies on new functionality)...
2023-10-11 15:38:39 <minimal> ncopa: so then how are Grub bugfixes/security fixes applied?
2023-10-11 15:38:51 <ncopa> they are not
2023-10-11 15:39:13 <ncopa> i think the long-term answer is: dont use grub :)
2023-10-11 15:39:32 <ikke> What is not a good idea about updating grub?
2023-10-11 15:39:37 <ncopa> minimal: do you know if an other distro update grub code?
2023-10-11 15:39:40 <ikke> Or are you talking about the way to do it?
2023-10-11 15:39:42 <minimal> I don't remember if Alpine's Syslinux has the same issue
2023-10-11 15:40:22 <ncopa> the thing is that it is fragile, and I would prefer not to fix bugs in the logic in this
2023-10-11 15:40:38 <ncopa> yes syslinux has same issue, and we dont update syslinux code
2023-10-11 15:40:41 <minimal> which bugs?
2023-10-11 15:40:51 <ncopa> if there are any
2023-10-11 15:41:07 <ncopa> i want avoid maintain even more code
2023-10-11 15:41:11 <ncopa> thats the real thing
2023-10-11 15:41:19 <minimal> so in other words people's machines stay on the same version of Grub from when they first installed?
2023-10-11 15:41:35 <ncopa> unless you manually update it
2023-10-11 15:41:37 <ncopa> yes
2023-10-11 15:41:45 <ncopa> thats what we did with syslinux
2023-10-11 15:42:12 <ncopa> if we add code to automatically update grub code, people will use it
2023-10-11 15:42:29 <ncopa> and we will get the blame if/when someting breaks
2023-10-11 15:43:09 <ncopa> but i can take another look at it later
2023-10-11 15:43:17 <minimal> doesn't that argument apply to any packages in Alpine?
2023-10-11 15:43:25 <ncopa> it does
2023-10-11 15:43:41 <ncopa> would be good to know if there are any other distros that actually update the grub code
2023-10-11 15:43:44 <ncopa> maybe debian does?
2023-10-11 15:43:49 <ncopa> or arch?
2023-10-11 15:44:24 <ncopa> and how does upstream grub devs envision this to work?
2023-10-11 15:44:28 <minimal> so when Grub 2.12 is finally released and packages for Alpine and it is installed then the grub trigger will update the grub config, which may potentially generate a config that does not work with someone's existing Grub 2.06 boottime code
2023-10-11 15:44:42 <ncopa> yup
2023-10-11 15:44:49 <Hello71> looks like ubuntu update-grub is literally set -e; exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
2023-10-11 15:45:04 <ncopa> that only generates config
2023-10-11 15:45:15 <ncopa> does not re-installs grub code
2023-10-11 15:45:39 <ncopa> heh
2023-10-11 15:46:08 <ncopa> i even remember the selling point for grub in the first place, when people still used lilo
2023-10-11 15:46:26 <ncopa> with lilo you would need re-install lilo with every kernel update
2023-10-11 15:46:28 <Hello71> minimal: has this ever happened? like, does grub-mkconfig actually use any new features?
2023-10-11 15:46:34 <minimal> part of the issue is even if people decide to run grub-install themselves manually they don't necessarily know what options to give it as they didn't run it in the 1st place (setup-disk did)
2023-10-11 15:47:13 <Hello71> for security issues, there was the password vulnerability, but grub-mkconfig doesn't (directly) support password anyways
2023-10-11 15:47:35 <Hello71> for new features, I think it's mainly new filesystems/partition types/devices, which shouldn't apply to existing installations
2023-10-11 15:47:45 <minimal> Hello71: I don't know specifically, it uses the template files in /etc/grub.d/ (plus grub-mkconfig and other files logic) to create grub.cfg
2023-10-11 15:48:01 <ncopa> i have set the 3.19.0 target for the MR i will look at it again
2023-10-11 15:48:18 <ncopa> right now its more important to get the 3.19 builders up and running so people can help fix build issues
2023-10-11 15:48:36 <ncopa> i also need to prioritize abuild fixes at this point
2023-10-11 15:48:37 <minimal> re: that security vulnerability, anyone with a Grub install prior to Alpine shipping a Grub package with the fix will still have the security vulnerability in place unless they ran grub-install themselves to install updated code
2023-10-11 15:48:52 <ncopa> and llvm17
2023-10-11 15:48:59 <dne> I'm believe debian does grub-install in "postinst"
2023-10-11 15:49:03 <ncopa> grub can wait. it does not block anything for anyone else
2023-10-11 15:49:48 <ncopa> dne: would be good if you could find the sources of what they actually do in postinst and document it on https://gitlab.alpinelinux.org/alpine/aports/merge_requests/53133
2023-10-11 15:50:12 <Hello71> dne: hm, I think you're right. it's not clear in what cases exactly though
2023-10-11 15:50:21 <dne> https://salsa.debian.org/grub-team/grub/-/blob/master/debian/postinst.in
2023-10-11 15:52:09 <ncopa> https://salsa.debian.org/grub-team/grub/-/blob/master/debian/postinst.in#L602
2023-10-11 15:52:15 <ncopa> they do run grub-install
2023-10-11 15:52:53 <Hello71> I think everyone agrees that it doesn't really make sense that upgrading the grub package doesn't upgrade the grub installation. but the question is whether automatically updating the boot sector is actually a good idea. in my opinion it goes against "simple"
2023-10-11 15:53:39 <ncopa> the draft MR has it disabled by default
2023-10-11 15:53:50 <minimal> the MR doesn't automatically update the boot sector (for BIOS), it provides a configurable option to permit an automatically update it but this is disabled by default
2023-10-11 15:54:11 <Hello71> it's the same for diskless install, it would be better to update the kernel/initramfs, but it's hard to do it reliably
2023-10-11 15:54:31 <minimal> one reason for it not being enabled is the user has to define in the config file WHICH device the BIOS boot sector is on
2023-10-11 15:54:32 <ncopa> i am skeptic because it is a complicated problem to solve
2023-10-11 15:54:51 <ncopa> cannot that be detected?
2023-10-11 15:55:20 <ncopa> drats
2023-10-11 15:55:33 <ncopa> my time is up and i have not yet got the arm 3.19 servers forward
2023-10-11 15:55:45 <minimal> ncopa: I agree it is complicated, I disagree that it being complicated means nothing should be done.....not even for the Grub package to display a text message reminded a user that the may want/need to run grub-install...
2023-10-11 15:56:14 <ncopa> ikek can you please delete sqlite from distfiles?
2023-10-11 15:56:36 <ncopa> imho, grub auto-update is not worth delay the 3.19 release
2023-10-11 15:56:53 <ncopa> there are more important thigns to fix before i look at grub problem
2023-10-11 15:57:09 <minimal> ncopa: grub-install needs to be told the device name for BIOS, not for UEFI. Code would look at /dev/root and try and figure out the actually device name (in the case of LUKS/LVM there a bit of hunting as that indicates the DM device)
2023-10-11 15:57:22 <minimal> s/would/could/
2023-10-11 15:58:00 <minimal> and I'm not sure about softraid installs as I guess grub-install would need to be run against multiple devices
2023-10-11 21:03:02 <Habbie> crap, forgot to put secfixes in !53235
2023-10-11 21:03:06 <Habbie> i'll correct that tomorrow
2023-10-11 21:05:56 <Habbie> also, the netdata port pulls in h2o all by itself, and doesn't have a fix yet
2023-10-11 22:06:27 <john3d> hey. today we solved the problem with keyboard layout in gdm. now i'm looking for a dev to find a solution to add it to the distro maybe.
2023-10-11 22:32:04 <aparcar1> ncopa: is it possible to define extra dependencies for subpackages?
2023-10-11 22:34:51 <andypost[m]> aparcar: just add `depends="$depends extra-deps"` to subpackage split 
2023-10-11 22:52:36 <aparcar1> Oh sweet, thanks
2023-10-11 23:40:18 <craftyguy> hmm, this gitlab CI job failed because the runner ran out of disk space: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/1141123#L10834
2023-10-12 11:01:20 <markand> o/ 
2023-10-12 11:02:01 <markand> is it publicly available the alpine runner that automate builds on commit? I'd like to provide this at $JOB too (we're deploying our own apk too)
2023-10-12 11:07:39 <quinq> markand, wouldn't that be gitlab?
2023-10-12 11:08:37 <ikke> It's a docker image and gitlab-runner
2023-10-12 11:08:46 <ikke> the docker image is publically available
2023-10-12 11:16:00 <markand> https://gitlab.alpinelinux.org/alpine/infra/docker/aports-build
2023-10-12 11:16:01 <markand> this one?
2023-10-12 11:17:18 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci
2023-10-12 11:17:30 <markand> thanks
2023-10-12 11:17:56 <ikke> the latter is available as alpinelinux/alpine-gitlab-ci
2023-10-12 14:12:18 <PureTryOut> apk package conflict reporting is annoyingly hard to understand. Been stuck for a few days now on a package that can be build, but not installed afterwards. apk complains about 2 packages conflicting with other versions of themselves and I just do not understand why they are pulling in those older versions
2023-10-12 14:12:19 <PureTryOut> 
ACTION sent a code block: https://matrix.org/_matrix/media/v3/download/matrix.org/iQDSuRgysPcnftiYcplXSmLN

2023-10-12 14:13:18 <PureTryOut> (kguiaddons5 is an older version of kguiaddons, but built against Qt5 rather than Qt6)
2023-10-12 14:14:11 <ikke> 
ACTION sighs, matrix still did not fix the codeblock links

2023-10-12 14:14:41 <PureTryOut> Ugh. I'll get you a paste give me a sec
2023-10-12 14:14:43 <PureTryOut> https://paste.sr.ht/~puretryout/4a759422ebc39c39233a302c5ddcb3d704499290
2023-10-12 14:16:19 <PureTryOut> I've been looking through the .PKGINFO file of this package as well to see if it linked against an older version of something that I missed but I can't find anything
2023-10-12 14:17:00 <ikke> What is the command that returns this error?
2023-10-12 14:17:24 <PureTryOut> apk add plasma-workspace. Note that it requires a plasma-workspace that is not currently in aports (it's a git nightly build)
2023-10-12 14:17:47 <ikke> There are the dependencies of plasma-workspace?
2023-10-12 14:18:08 <PureTryOut> not the right versions no. All it's deps are nightly builds as well
2023-10-12 14:18:30 <PureTryOut> I realize this makes it hard to debug sorry 🙈
2023-10-12 14:19:04 <ikke> sorry, s/There/What/
2023-10-12 14:19:34 <PureTryOut> Ah. Well same as they are currently in aports but the 5 suffix omitted of all KDE Framework packages
2023-10-12 14:19:45 <PureTryOut> It's quite a list, easier to look it up then for me to post it here I think
2023-10-12 14:19:58 <ikke> right
2023-10-12 14:20:32 <ikke> So the key is I think finding why some of the satisfies for kguiaddons5 are being pulled in
2023-10-12 14:21:02 <PureTryOut> Agreed, and I've been trying to do so and failing 😅
2023-10-12 14:21:21 <ikke> apk dot may help
2023-10-12 14:21:51 <PureTryOut> does that list installed stuff only? Since I can't actually install this version of plasma-workspace 🤔
2023-10-12 14:22:14 <ikke> No, it looks at the index
2023-10-12 14:22:24 <PureTryOut> ah cool!
2023-10-12 14:22:51 <ikke> It gives the output in dot  format, so you may need to feed it into graphviz
2023-10-12 14:24:14 <PureTryOut> how would I do that? just apk dot | graphviz?
2023-10-12 14:24:31 <PureTryOut> well apk dot | dot I suppose
2023-10-12 14:33:40 <ikke> quite heavy to render
2023-10-12 14:48:11 <ikke> PureTryOut: plasma-desktop-5.27.8-r2" -> "kio5-5.110.0-r1"[arrowhead=inv,label="so:libKF5KIOCore.so.5",];
2023-10-12 15:43:38 <ptrc> is there a way to single out armhf using C defines?
2023-10-12 15:51:07 <ikke> #define __ARM_ARCH 6
2023-10-12 15:51:14 <ikke> I guess
2023-10-12 15:51:24 <ikke> echo | gcc -dM -E - | grep ARM | sort
2023-10-12 15:52:07 <ptrc> oh, right
2023-10-12 15:52:22 <ptrc> because the other 32-bit ARM we have is v7
2023-10-12 15:52:29 <ptrc> thanks!
2023-10-12 15:53:05 <ikke> https://tpaste.us/vNqY 
2023-10-12 15:53:40 <ikke> ptrc: this is armv7: https://tpaste.us/QRQb 
2023-10-12 15:54:07 <ptrc> i guess #ifdef __ARM_ARCH_6ZK__ also would work
2023-10-12 15:54:19 <ikke> yes
2023-10-12 16:08:29 <PureTryOut> ikke: but plasma-desktop-5.27.8 is supposed to depend on kio5. And plasma-desktop is not a dependency of plasma-workspace, it's the other way around. I don't think that part is the problem
2023-10-12 16:09:06 <PureTryOut> I'll try and get the apk dot output out of the chroot this is all done in and share it
2023-10-12 16:11:12 <ikke> yeah, that would be helpful
2023-10-12 17:28:49 <ikke> Going to upgrade gitlab in a bit, it will be briefly unavailable
2023-10-12 17:36:14 <ikke> gitlab is available again
2023-10-12 17:41:47 <quinq> nice :)
2023-10-13 13:31:47 <Ermine> when 3.19-stable branch will be created?
2023-10-13 13:32:31 <ikke> At the point if release 
2023-10-13 13:32:36 <ikke> of*
2023-10-13 13:32:46 <ikke> ncopa is setting up the new builders now 
2023-10-13 14:47:04 <chereskata> could someone look over !52880
2023-10-13 14:47:30 <chereskata> and !52683
2023-10-13 14:47:43 <chereskata> as well as !51761
2023-10-13 14:48:13 <chereskata> ty all :)
2023-10-13 16:26:27 <a16bitsysop> is anything stopping https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49224 being merged?
2023-10-13 16:28:48 <quinq> Besides “Merge blocked: the source branch must be rebased onto the target branch.”?
2023-10-13 16:29:19 <ikke> That will be done when it's merged
2023-10-13 16:33:29 <a16bitsysop> I could do with testing a new commit without delaying it any more
2023-10-13 16:38:37 <ikke> a16bitsysop: merged
2023-10-13 16:39:04 <a16bitsysop> great thanks
2023-10-13 16:59:18 <chereskata> Could someone check !53127 please :)?
2023-10-13 17:03:17 <PureTryOut> ikke: I fail to figure out how to make a nice graph out of the `apk dot` result. Just piping it into dot makes it hang forever
2023-10-13 17:06:13 <ikke> Yeah, it appears to be too large. But just the text output would be helpful 
2023-10-13 17:10:47 <PureTryOut> 
ACTION posted a file: apk-dot (9865KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/OBKMznJBkCzbdFNiQOuZaJYS >

2023-10-13 17:11:07 <PureTryOut> that'd explain it
2023-10-13 17:12:46 <ikke> I guess this is the complete repo (`apk dot`), not limited to plasma-desktop (`apk dot plasma-desktop`)?
2023-10-13 17:13:35 <ikke> I don't even see plasma-desktop in the list
2023-10-13 17:13:50 <ikke> oh, n/m, bad filter
2023-10-13 17:18:47 <ikke> PureTryOut: just so that I'm looking for the correct thing: You install plasma-desktop, which is current v5, and it should pull in all the *5 versions of the packages?
2023-10-13 17:19:50 <PureTryOut> I haven't gotten to the point of building plasma-desktop yet. plasma-workspace is where it goes wrong
2023-10-13 17:20:05 <PureTryOut> plasma-workspace-9999_git<whatever> should pull in the non-*5 versions of the packages
2023-10-13 17:20:23 <ikke> ah ok
2023-10-13 17:20:24 <PureTryOut> (not sure where you got plasma-desktop from?)
2023-10-13 17:20:43 <PureTryOut> and sorry I didn't realize `apk dot <package>` was what's needed
2023-10-13 17:20:43 <ikke> maybe misread / misremembered from earlier
2023-10-13 17:20:49 <PureTryOut> I'll get you that output
2023-10-13 17:21:19 <ikke> PureTryOut: Limits the file size a lot :)
2023-10-13 17:22:25 <ikke> yeah, definitely me somewhow swapping workspace with desktop
2023-10-13 17:22:48 <PureTryOut> 
ACTION posted a file: apk-dot (397KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/VxOzwniQjnvztMgkvyjqAzzV >

2023-10-13 17:23:03 <PureTryOut> Eventually I'd like to build plasma-desktop 😛
2023-10-13 17:24:05 <ikke> hehe
2023-10-13 17:25:41 <andypost[m]> PureTryOut (matrix.org): give a try `-Tsvg` it's fastest converter and I checked it - it produce very huge file
2023-10-13 17:33:57 <PureTryOut> I did that, still hang forever 😉 I'll try again with this smaller file though
2023-10-13 17:53:27 <ptrc> i don't think there's a point in trying to render this to svg
2023-10-13 17:53:37 <ptrc> or well, to anything
2023-10-13 17:53:49 <ptrc> even with way smaller graphs it just collapses into meaningless clusters of lines
2023-10-13 17:54:32 <ptrc> also, it's interesting how it shows multiple versions there..
2023-10-13 17:56:25 <ikke> ptrc: for context, https://paste.sr.ht/~puretryout/4a759422ebc39c39233a302c5ddcb3d704499290 is what PureTryOut is trying to solve
2023-10-13 17:56:36 <ptrc> mhm, i've seen that one before in here
2023-10-13 18:00:46 <PureTryOut> lol I did render the smaller graph now but that's still entirely unreadable
2023-10-13 18:06:00 <ptrc> i really wish apk could add some indication that either of the nodes could be picked and not all of them
2023-10-13 18:06:12 <ptrc> but i guess that's what the dependency labels are for
2023-10-13 18:11:47 <andypost[m]> PureTryOut (matrix.org): the best kind of viz for such cases probably https://twitter.com/eojthebrave/status/1415797827880595461
2023-10-13 18:36:30 <ikke> PureTryOut: Would it also possible to share the APKINDEX? Trying to automate something
2023-10-13 18:44:07 <PureTryOut> 
ACTION posted a file: (31KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/aTTCrvPRXDtTzeGAXNMxwNky/APKINDEX.tar.gz >

2023-10-13 18:44:11 <PureTryOut> ikke: of course ^
2023-10-13 18:45:02 <ikke> thanks
2023-10-13 18:45:14 <ikke> Right now I'm parsing the dot output directly, but in the future, using the index is more robust
2023-10-13 18:45:25 <ikke> And I already have code to parse the index
2023-10-13 18:56:42 <PureTryOut> Fancy! Hopefully apk can be improved to show the dependency chain more directly in the future, it's always hard to find out what's causing the problem
2023-10-13 18:57:13 <ikke> yeah
2023-10-13 19:20:04 <elly> I like that it emits dot actually, it's a pretty good format to visualize or compute stuff on
2023-10-13 19:20:09 <elly> maybe better than apk having that info itself
2023-10-13 19:24:04 <ikke> Good for visualizing, but difficult for finding a specific path
2023-10-13 19:24:16 <ikke> (multiple levels)
2023-10-13 19:27:06 <ikke> PureTryOut: it appears plasma-workspace depends on kinit5
2023-10-13 19:27:50 <PureTryOut> directly somehow or indirectly through something else? It's not listed in the APKBUILD as a dep at least
2023-10-13 19:28:33 <ikke> let me verify to be sure, maybe some issue in my code :P
2023-10-13 19:28:42 <ikke> cannot find it in the dot file
2023-10-13 20:44:53 <ikke> PureTryOut: relevant: https://xkcd.com/356/
2023-10-13 22:03:06 <ikke> PureTryOut: it turns out to be slightly more complex than I assumed
2023-10-13 22:11:54 <ikke> I found 121 different ways that kio5 could be installed :D
2023-10-13 22:12:22 <ikke> But most of them should not be taken because it should prefer newer versions of the packages
2023-10-13 22:22:33 <ikke> ftr: This is what I got: https://tpaste.us/j4jq 
2023-10-14 06:42:59 <donoban> PureTryOut: please take a look to !53041 , x86 was ok it just failed due network errors on sources fetching
2023-10-14 06:43:35 <donoban> qt6.6 is out, better try to do it directly there or open a new mr?
2023-10-14 07:07:18 <PureTryOut> Nope this should go in first. I have a MR open to upgrade to 6.6 but it requires updating of a patch in QtWebengine which I need to take the time for
2023-10-14 07:13:40 <ikke> 4801 segmentation fault  abuild-apk fix
2023-10-14 07:13:42 <ikke> interesting
2023-10-14 07:43:34 <donoban> apk fix abuild-apk :P
2023-10-14 11:15:10 <donoban> any idea handling this https://tpaste.us/D7zq
2023-10-14 11:15:34 <donoban> building qtwebengine on x86 ld.lld: error: undefined symbol: __atomic_load
2023-10-14 13:35:15 <elly> my guess: missing some libclangrt or whatnot
2023-10-14 14:34:37 <donoban> maybe something like this helps +unix:LIBS += -latomic
2023-10-14 15:17:01 <donoban> hmm... ninja: entering directory '/home/donoban/aports/community/qt6-qtwebengine/src/qtwebengine-6.5.3/build/src/core/Release/x86_64'
2023-10-14 15:17:25 <donoban> theorically it's a x86 container
2023-10-14 15:17:37 <ikke> what does apk --print-arch return?
2023-10-14 15:18:08 <donoban> x86
2023-10-14 15:18:12 <ikke> and uname -m?
2023-10-14 15:18:31 <donoban> x86_64
2023-10-14 15:18:35 <donoban> it's the kernel? the host is x86_64
2023-10-14 15:18:46 <ikke> yes, you need to run the container with linux32 as entrypoint
2023-10-14 15:19:25 <donoban> docker run --entrypoint xxx/linux32 ?
2023-10-14 15:19:38 <ikke> yeah, or just linux32 works as well
2023-10-14 15:20:05 <donoban> could I just stop and restar it? maybe commit to a image
2023-10-14 15:20:30 <ikke> donoban: if you have an interactive terminal, just execute linux32 in there
2023-10-14 15:20:54 <donoban> ~ $ uname -m
2023-10-14 15:20:56 <donoban> i686
2023-10-14 15:20:58 <donoban> o great
2023-10-14 15:21:33 <donoban> what does this busybox magic?
2023-10-14 15:23:07 <ikke> it calls arch_prctl and executes a new shell
2023-10-14 15:23:21 <ikke> https://www.man7.org/linux/man-pages/man2/arch_prctl.2.html
2023-10-14 15:24:35 <donoban> nice
2023-10-14 15:24:39 <donoban> maybe it builds fine now
2023-10-14 15:48:38 <donoban> oh, same error
2023-10-14 17:16:20 <android2> Can you help our opensource project. We want the unreal map file types.
2023-10-14 17:16:23 <android2> http://sf.net/p/chaosesqueanthology/tickets/2/
2023-10-14 17:16:28 <android2> .t3d and .unr file formats (C project, GPL licensed)
2023-10-14 18:16:02 <donoban>   if (v8_current_cpu == "riscv64" || v8_current_cpu == "riscv32") {
2023-10-14 18:16:04 <donoban>     libs = [ "atomic" ]
2023-10-14 18:16:26 <donoban> I feel that the problem is here :)
2023-10-14 18:46:32 <donoban> strange problem on CI
2023-10-14 18:46:49 <donoban>   so:libdav1d.so.6 (no such package):
2023-10-14 18:47:04 <ikke> There were some rebuilds for that today
2023-10-14 18:47:11 <ikke> problem is some builders are blocked
2023-10-14 18:47:41 <donoban> ah ok
2023-10-14 18:48:01 <donoban> I will retry later
2023-10-14 18:48:23 <donoban> it's building locally, 6555/16478...
2023-10-14 18:48:32 <donoban> probably more than 1h left
2023-10-14 18:49:31 <donoban> time for do someting outside home
2023-10-14 18:49:34 <donoban> see you!
2023-10-14 18:54:29 <ikke> PureTryOut: any clue what's up with ark? it somehow fails to identify the type of an iso
2023-10-14 18:54:53 <PureTryOut> I do not no, it didn't happen in CI
2023-10-14 18:55:14 <PureTryOut> it succeeded on x86_64 though it seems?
2023-10-14 18:56:49 <ikke> apparently yes
2023-10-14 19:30:17 <andypost[m]> PureTryOut (matrix.org): looks this hardcoded https://github.com/KDE/ark/blob/master/kerfuffle/mimetypes.cpp#L75-L94
2023-10-14 19:32:10 <andypost[m]> and there's comment bellow about source
2023-10-14 19:32:58 <ikke> TODO: drop application/x-cd-image once all distributions ship shared-mime-info >= 2.3
2023-10-14 19:33:10 <ikke> We happen to have shared-mime-info 2.3
2023-10-14 19:37:47 <PureTryOut> Oh that reminds me, I got a mail about that
2023-10-14 19:38:00 <PureTryOut> https://invent.kde.org/utilities/ark/-/commit/9bcbcb056c43abef88540c54f25bc6c1a78c7c0e
2023-10-14 19:38:12 <PureTryOut> That commit should fix that, I'll apply it
2023-10-14 19:38:47 <ikke> 👍
2023-10-14 20:37:51 <chereskata> Hello, libdav1d needs rebuild of pkgdeps 
2023-10-14 20:37:58 <chereskata> https://paste.gnome.org/2glKjZ5v0
2023-10-14 20:38:07 <ikke> chereskata: yes, builders are stuck
2023-10-14 20:38:21 <chereskata> thanks!
2023-10-14 21:38:23 <donoban> ouch: clang-16: error: unable to execute command: Segmentation fault (core dumped)
2023-10-14 21:38:35 <ikke> oof
2023-10-14 21:42:06 <donoban> its on libLLVM-16.so
2023-10-14 21:42:45 <donoban> maybe it was not running on linux32
2023-10-14 21:43:12 <donoban> beh, it is
2023-10-15 06:41:11 <j_v> nawk came out with new tagged release named '2ndEdition', but version string '20230911'. is this change to the APKBUILD acceptable?: https://tpaste.us/5X1E
2023-10-15 06:48:29 <fluix> yes. but why... (to the authors)
2023-10-15 06:50:36 <j_v> i dread asking
2023-10-15 09:56:16 <donoban> was this canceled? https://gitlab.alpinelinux.org/donoban/aports/-/jobs/1145115
2023-10-15 09:56:33 <donoban> could I retry or there is some problem?
2023-10-15 09:57:22 <ikke> It was canceled (says it on the right), but not sure why or by who
2023-10-15 09:57:54 <donoban> so could I retry?
2023-10-15 09:58:00 <ikke> sure
2023-10-15 09:58:03 <donoban> ok
2023-10-15 10:08:45 <ikke> PureTryOut: 
2023-10-15 10:08:57 <ikke> You'll never guess what the issue was with ark on x86_64
2023-10-15 10:24:40 <ikke> ~/.local/share/mime
2023-10-15 10:32:38 <quinq> marceau
2023-10-15 10:33:05 <ikke> que?
2023-10-15 10:33:30 <quinq> Le mime Marceau
2023-10-15 10:36:10 <quinq> By the way, webkitgtk is starting to drag a bit :/
2023-10-15 10:43:58 <PureTryOut> ikke: I'll never guess indeed, what was it? 😛
2023-10-15 10:44:12 <PureTryOut> What about ~/.local/share/mime?
2023-10-15 10:44:43 <ikke> after moving it, the tests passed
2023-10-15 10:45:52 <ikke> https://tpaste.us/vN9Z
2023-10-15 10:48:39 <quinq> Erf, once those bit me too, like having wine openinng notepad for text/plain files xD
2023-10-15 10:59:13 <PureTryOut> Oh wtf lol. So that's why it only happened on the builders...
2023-10-15 10:59:28 <PureTryOut> Can we start running build jobs in chroots/containers/rootbld at some point? 😅
2023-10-15 11:02:23 <ikke> PureTryOut: I was waiting for that question to come up :P
2023-10-15 11:05:15 <ikke> Right now, it still seems to use dl-cdn to download the packages. If we want to use it on the builders, we need to make sure it uses the repositories configured in /etc/apk/repositories
2023-10-15 11:05:30 <ikke> https://tpaste.us/QRPr 
2023-10-15 11:05:40 <PureTryOut> Well yeah it was too be expected of course haha, but I really want it. It's not the first time something like this happened, or packages pulling in deps from internet rather than from the Alpine repositories due to options="net" not being respected.
2023-10-15 11:06:14 <PureTryOut> ikke: that'd be a good change anyway imo
2023-10-15 11:38:07 <PureTryOut> btw ikke did you manage to figure out the plasma-workspace dependency problem?
2023-10-15 11:38:23 <ikke> PureTryOut: nope, sadly not
2023-10-15 11:38:41 <PureTryOut> darn
2023-10-15 12:07:27 <donoban> ouch,  took longer than 2h0m0s seconds
2023-10-15 12:28:23 <PureTryOut> ugh even manually installing all the deps as listed in PKGINFO (so all the so:'s individually) installs just fine, but not plasma-workspace itself 😒
2023-10-15 12:30:19 <PureTryOut> this feels like a bug in apk?
2023-10-15 12:42:25 <ikke> not sure if it helps, but perhaps building apk-tools with DEBUG enabled sheds more light?
2023-10-15 13:50:15 <donoban> ikke: could you refresh me how add more CI time limit?
2023-10-15 13:50:47 <ikke> settings -> CI/CD -> General Pipelines section
2023-10-15 13:50:56 <donoban> ty
2023-10-15 20:44:49 <donoban> ERROR: Job failed: execution took longer than 4h0m0s seconds
2023-10-15 20:44:59 <donoban> meh, it seems that it gets stucked
2023-10-15 20:45:52 <donoban> it was at same action two hours before
2023-10-15 22:02:46 <omni> ikke: don't we sometimes catch some bugs on the builders that we don't in the CI builds
2023-10-15 22:58:18 <pj> Yes
2023-10-16 03:26:48 <Allak> To be a ghost with a pulse, get in a situation where the mind gives the perceived death signal, by watching a scary movie alone in the dark, and when it does just ignore it or pay no attention to it.- Daniel Alan Gabriel- ghostpeople@gmx.com
2023-10-16 03:37:02 <orbea> not sure if this is intentional, but the libreoffice apkbuild have both --with-system-zxing and --without-system-zxing https://git.alpinelinux.org/aports/tree/community/libreoffice/APKBUILD#n437
2023-10-16 04:08:50 <quinq> Yeah, strange, was added in 088792d13eeee104a12b3bab3f31e69df135ba1e
2023-10-16 04:08:53 <quinq> looks like a bug
2023-10-16 07:31:00 <caskd[m]> ncopa: any updates on https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/8 ?
2023-10-16 07:32:36 <caskd[m]> i'll gladly test any of the older kernel versions if the behaviour is different if it is desired but from my testing on 5.11 the current virtio rule is noop because it's never matched
2023-10-16 07:34:52 <caskd[m]> well, not "never matched" but it can't find the serial where it looks for it so it does nothing
2023-10-16 08:14:46 <PureTryOut> ikke: I got plasma-workspace to a very minimal dependency list and it still fails to install, wtf. The `.PKGINFO` contents https://paste.sr.ht/~puretryout/c3cd94fa9a82a2bfc3a2e6a1c2e64b42ae40a9a3
2023-10-16 08:19:45 <PureTryOut> even removed the runtime dep on kded and it still doesn't install...
2023-10-16 08:21:57 <PureTryOut> literally a zero dependency package now, wtf. Maybe there is a cache somewhere...
2023-10-16 08:23:20 <PureTryOut> Nope... https://paste.sr.ht/~puretryout/edce48eb8a96f9e203cc450be31b71c45e1c58a4. It literally depends on nothing and still fails
2023-10-16 08:27:28 <ikke> What's in world?
2023-10-16 08:29:21 <PureTryOut> Just abuild, alpine-base, build-base, ccache and git
2023-10-16 08:30:18 <PureTryOut> (it's a clean chroot)
2023-10-16 08:30:52 <PureTryOut> so a bug in apk I'm guessing? not sure what could cause this
2023-10-16 08:38:26 <PureTryOut> I've made an issue for it with some info and the .apk attached https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10949
2023-10-16 08:46:40 <PureTryOut> Hmm I renamed the package and after building that it does install...
2023-10-16 08:50:51 <ikke> Is there a provides for plasma-workspace?
2023-10-16 08:52:44 <PureTryOut> not that I can find
2023-10-16 09:03:57 <PureTryOut> So what might be happening is that kde-cli-tools is forcing itself to be installed, but the old version and not the new one. The old one has a install_if="plasma-workspace" which was a workaround for a circular dependency. That circular dependency still exists in the old version so I can't "just" remove it, but that's probably pulling itself in when plasma-workspace (any version) gets installed...
2023-10-16 09:04:20 <PureTryOut> so I guess I need to fix that circular dep differently. I suppose I can add the dep to plasma-desktop instead 🤔
2023-10-16 09:51:21 <PureTryOut> Yup, fixed. Lol
2023-10-16 09:53:41 <ikke> That was a journey 
2023-10-16 10:37:18 <ncopa> caskd[m]: i suppose my point is that the code that looks for .../device/serial is still there, but the test for that was removed. I think we either remove the code or we keep the test for it
2023-10-16 10:37:49 <ncopa> I'm working on the 3.19 builders. apparently 116eb260016a40bf517dbfdc9e2f1d0c8334682a introduces a circular dep
2023-10-16 10:38:11 <ncopa> curl -> brotli -> cmake -> curl
2023-10-16 10:38:51 <ikke> hmm
2023-10-16 10:40:09 <ncopa> we can solve that by either use --no-system-curl in cmake
2023-10-16 10:40:33 <ncopa> or have a separate bootstrap curl build (without brotli)
2023-10-16 10:42:46 <ikke> We do already do things differently for curl on bootstrapping
2023-10-16 10:43:51 <ncopa> that's for cross compile I think
2023-10-16 10:44:15 <ncopa> using --no-system-curl is tempting, as it is the simplest thing to do
2023-10-16 10:44:29 <ncopa> but it increases cmake size 
2023-10-16 10:44:44 <ncopa> and embedded curl may be vulnerable
2023-10-16 10:44:45 <ikke> and requires us to update cmake when curl vulnerabilities are found
2023-10-16 10:44:47 <ikke> yes
2023-10-16 10:45:13 <ncopa> build curl in two stages is cumbersome
2023-10-16 10:45:34 <ncopa> as it involves manual work on bootstrapping aports
2023-10-16 10:46:17 <ncopa> but other question is: why does make need curl?
2023-10-16 10:46:28 <ikke> cmake?
2023-10-16 10:47:10 <ikke> ncopa: afaik curl already requires bootstrap, since python3 is not part of the bootstrap chain
2023-10-16 10:47:24 <ncopa> cmake. I'm on Mac OS with autocorrect...
2023-10-16 10:49:06 <ncopa> so you prefer a two phase build of curl?
2023-10-16 10:49:44 <ikke> Well, I do get it's anoying to do, so avoiding it if possible is desireable
2023-10-16 10:50:38 <ncopa> the alternative is use cmake with bundled curl
2023-10-16 10:50:47 <ncopa> which avoids it
2023-10-16 10:51:13 <ncopa> and we already use bundled jsoncpp and cppdap
2023-10-16 10:51:35 <ncopa> im ok to both options
2023-10-16 10:53:22 <ikke> testing building cmake without curl
2023-10-16 10:53:36 <ikke> seems to work if using nghttp2-dev
2023-10-16 10:54:35 <ikke> Not sure if it's an improvement, but it's an option
2023-10-16 10:54:48 <ikke> I guess that would add nghttp2 to the bootstrap chain
2023-10-16 10:55:44 <ncopa> so its possible to build cmake with nghttp2 instead of curl_
2023-10-16 10:55:49 <ikke> yes
2023-10-16 10:56:02 <ikke> https://tpaste.us/j4z1 
2023-10-16 10:56:02 <ncopa> I think nghttp2 also is a dependency for curl
2023-10-16 10:56:45 <ikke> indeed
2023-10-16 10:57:31 <ikke> Does nghttp2 support anything else then http2?
2023-10-16 10:57:37 <ncopa> i dont know
2023-10-16 10:57:59 <ikke> I suppose not
2023-10-16 10:59:25 <ncopa> but does it mean that it is possible to build cmake without embedded curl?
2023-10-16 10:59:29 <ncopa> without curl at all?
2023-10-16 11:00:37 <ikke> Maybe it's statically built 
2023-10-16 11:01:12 <ikke> So I guess it would use the embedded curl then
2023-10-16 11:01:27 <ncopa> google is practically useless for this finds everything except building cmake itself
2023-10-16 11:01:42 <ncopa> ok
2023-10-16 11:02:05 <ncopa> i suppose the real question here is if cmake with embedded curl is acceptable?
2023-10-16 11:06:45 <ncopa> im pushing embedded curl to cmake for now
2023-10-16 11:09:32 <ikke> How would we track security issues?
2023-10-16 11:13:30 <ncopa> i dont know
2023-10-16 11:39:28 <donoban> considering it's the default behaviour, maybe upstream takes care?
2023-10-16 11:42:26 <donoban> https://gitlab.kitware.com/cmake/cmake/-/commit/10d1224b6010eb6be866b7f24759de14ed52440d
2023-10-16 12:39:20 <caskd[m]> <ncopa> "caskd: i suppose my point is..." <- i removed the code for /device/serial and replaced it with /serial
2023-10-16 12:39:44 <caskd[m]> so the old case is removed and new one added
2023-10-16 14:14:29 <ncopa> caskd[m]: where is it removed?
2023-10-16 14:15:13 <ncopa> you added this: https://gitlab.alpinelinux.org/alpine/mdev-conf/-/blob/65b589e545c7264e201cd3cbfefed92ee87f7cdb/persistent-storage#L65
2023-10-16 14:15:19 <ncopa> and added a test for that line
2023-10-16 14:15:38 <ncopa> and removed the testcase for this line: https://gitlab.alpinelinux.org/alpine/mdev-conf/-/blob/65b589e545c7264e201cd3cbfefed92ee87f7cdb/persistent-storage#L63
2023-10-16 14:16:00 <ncopa> so the code for line 63 no longer has a test
2023-10-16 14:16:13 <ncopa> or am I missing something?
2023-10-16 14:20:20 <ncopa> for some reason is icu test failing now
2023-10-16 14:22:35 <chereskata> Hi, could someone check !53279, !53127 and !52880 thanks :)
2023-10-16 14:34:44 <caskd[m]> <ncopa> "or am I missing something?" <- oh no, you're correct, i've kept that because i didn't know if there's any other case where they are used, i should remove it
2023-10-16 14:34:55 <caskd[m]> my fault
2023-10-16 14:39:10 <minimal> ncopa: confused, there is still serial test for nvme also
2023-10-16 14:41:22 <caskd[m]> minimal: oh yeah you're correct
2023-10-16 14:41:28 <caskd[m]> nevermind, reverting
2023-10-16 14:44:52 <caskd[m]> welp...
2023-10-16 17:39:12 <kpcyrd> fyi https://github.com/alexcrichton/openssl-src-rs/pull/213 has been merged. this is unlikely to affect any official APKBUILDs since it only applies to projects with vendored openssl, but might be relevant to your interests anyway :)
2023-10-16 20:04:31 <donoban> qtwebengine also segfaults with qt6.6.0 https://tpaste.us/BJ4W
2023-10-16 20:05:10 <ikke> std::bad_alloc
2023-10-16 20:06:23 <donoban> uhm, not enough memory?
2023-10-16 20:07:05 <ikke> perhaps, no idea
2023-10-16 20:07:18 <ikke> the compiler treats it as a bug
2023-10-16 20:07:26 <ikke> "PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace"
2023-10-16 20:07:26 <donoban> it has 64gb, is it worh to try it on CI?
2023-10-16 20:07:42 <ikke> CI does not have more memory
2023-10-16 20:09:32 <donoban> let's try reporting to upstream...
2023-10-16 20:58:46 <omni> wouldn't the same arm*|x86) check case for terraform work for opentofu?
2023-10-16 22:40:29 <ikke> omni: I tried, didn't help 
2023-10-16 22:40:54 <ikke> And would be surprised if it did
2023-10-17 06:24:50 <ncopa> icu tests fails nowadays
2023-10-17 06:25:00 <ncopa> it is a blocker for 3.19 builders currently
2023-10-17 06:25:06 <ncopa> i have fixed one of the issues
2023-10-17 06:25:39 <ncopa> but I have not yet figured out why tests still fail. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/53534
2023-10-17 06:30:05 <ncopa> huh... it appears to pass...
2023-10-17 06:34:23 <ncopa> locally those fails:
2023-10-17 06:34:26 <ncopa>    format
2023-10-17 06:34:26 <ncopa>       TimeZoneTest
2023-10-17 06:34:26 <ncopa>          TestGenericAPI
2023-10-17 06:34:26 <ncopa>       testLocale
2023-10-17 06:34:26 <ncopa>    icuserv
2023-10-17 08:30:13 <omni> ikke: ok, too bad
2023-10-17 08:42:24 <donoban> is there some memory limit for a process running x86 on linux-lts x86_64?
2023-10-17 08:47:14 <abby> 4GB?
2023-10-17 08:49:36 <Habbie> on _64? shouldn't be 4GB
2023-10-17 08:49:42 <Habbie> but ulimit might be set
2023-10-17 08:50:27 <ncopa> donoban: i think there was an issue in the kernel config that made a limit of 800-900MB something. It should be fixed with the latest kernels
2023-10-17 08:50:29 <abby> "running x86" i assume means 32bit
2023-10-17 08:51:01 <Habbie> oh
2023-10-17 08:51:03 <Habbie> sorry
2023-10-17 08:51:14 <Habbie> might even be 3GB then
2023-10-17 08:51:24 <donoban> it works some time at 3,2gb before crash
2023-10-17 08:51:33 <Habbie> yes, that makes sense
2023-10-17 08:51:43 <donoban> host is running an old kernel, pretty pain reboot it now
2023-10-17 08:51:55 <donoban> I'm gonna try to push to gitlab and see if CI works
2023-10-17 09:07:59 <ncopa> i think we need move lua-busted to main
2023-10-17 09:08:16 <ncopa> i need to step out for a while, any volunteers to work on moving lua-busted to main?
2023-10-17 09:08:21 <ncopa> its a blocker for 3.19
2023-10-17 09:11:38 <omni> the name py3-pyqt6-webengine looks odd to me, it's the qt6 variant of py3-qtwebengine, but I'm struggling to come up with a better name
2023-10-17 09:14:00 <Habbie> debian calls it python3-pyqt6.qtwebengine
2023-10-17 09:14:03 <Habbie> not sure that's better
2023-10-17 09:15:26 <ikke> What about py3-webengine-qt6?
2023-10-17 09:16:45 <dari> py3-qt6webengine :>
2023-10-17 09:16:51 <omni> py3-qt6-pyqt-qtwebengine.webengine.python3
2023-10-17 09:17:08 <omni> dari: I kinda like that actually...
2023-10-17 09:19:04 <dari> it just looks little better :P
2023-10-17 09:23:05 <omni> the upstream names are PyQtWebEngine and PyQt6-WebWebEngine
2023-10-17 09:27:41 <omni> there is py3-pyqt5-sip and py3-pyqt6-sip, also riverbankcomputing upstream
2023-10-17 09:27:45 <omni> *sigh*
2023-10-17 09:27:57 <omni> maybe py3-pyqt6-webengine is fine
2023-10-17 10:23:19 <omni> if two aports provides= the same thing, how can one be preferred over the other?
2023-10-17 10:25:29 <ikke> provider_priority, highest wins
2023-10-17 10:25:34 <ikke> (and it should be provided)
2023-10-17 10:34:20 <omni> nice
2023-10-17 10:34:28 <omni> ncopa: I'll have a look
2023-10-17 11:39:43 <omni> ncopa: !53541
2023-10-17 11:58:07 <Ermine> Busted!
2023-10-17 11:59:12 <fancsali[m]> Hey peeps; it's more than likely, I've missed something, but cannot put my finger on it: https://gitlab.alpinelinux.org/fancsali/aports/-/jobs/1147243; can someone perhaps nudge me in the right direction?
2023-10-17 12:04:48 <omni> ikke: but, hmm, would you be able to have two packages installed that have the same provides=?
2023-10-17 12:05:14 <ncopa> fancsali[m]: target branch is your own repo?
2023-10-17 12:06:11 <ncopa> I think target branch should be aports/master?
2023-10-17 12:06:29 <omni> I'm currently thinking qt5 vs qt6.. like qt5-base and qt6-base, could they both have provides=qtbase and yet both be installed?
2023-10-17 12:06:50 <ncopa> omni: thanks! Will merge it as soon I get home. I’m on the train now
2023-10-17 12:15:18 <fancsali[m]> ncopa: Indeed, the only thing, you think, you cannot possibly have messed up, so you're too lazy to check.
2023-10-17 12:15:18 <fancsali[m]> I am truly sorry; and thanks!
2023-10-17 12:15:18 <fancsali[m]> Typical of me... facepalm!
2023-10-17 12:16:34 <ikke> omni: yes, that's where the priority is for 
2023-10-17 12:17:28 <fancsali[m]> s/ncopa://
2023-10-17 12:17:45 <fancsali[m]>  * ncopa: Indeed, the only thing, you think, you cannot possibly have messed up, so you're too lazy to check.
2023-10-17 12:17:45 <fancsali[m]> Typical of me... facepalm!
2023-10-17 12:17:45 <fancsali[m]> I am truly sorry; and thanks!
2023-10-17 12:37:14 <omni> ikke: just to be clear, adding qtbase would in that case default to installing qt6-base (if that had higher priority) but adding qt5-base would not remove qt6-base?
2023-10-17 12:39:13 <ikke> omni: if nothing else depends on qt6-base, it would be removed 
2023-10-17 13:19:37 <ncopa> fancsali[m]: no worries.
2023-10-17 13:37:38 <fancsali[m]> <ncopa> "I think target branch should..." <- Yapp. Re-created with that as the target.
2023-10-17 17:51:52 <Ermine> Please take a look at !53056
2023-10-17 19:23:27 <ptrc> Ermine: just to double-check, is that ready to merge?
2023-10-17 19:54:46 <Ermine> Yes, I think so
2023-10-17 23:03:19 <aparcar> is there a way to use chroot as non root?
2023-10-17 23:03:30 <aparcar> I want to use APK and install packages to a folder
2023-10-17 23:28:01 <ptrc> aparcar: there's stuff like bwrap, unshare or proot
2023-10-18 03:04:27 <elly> what does this error from abuild mean?
2023-10-18 03:04:28 <elly> ERROR: unable to select packages: so:libdav1d.so.6 (no such package):
2023-10-18 03:04:34 <elly>     required by: ffmpeg-libavcodec-6.0-r25[so:libdav1d.so.6]
2023-10-18 03:05:43 <elly> I do have libdav1d, but: usr/lib/libdav1d.so.7
2023-10-18 03:07:00 <elly> oh, that is the result of failing to `apk upgrade`
2023-10-18 08:45:40 <qaqland> should I create new user for each service run background?
2023-10-18 08:46:23 <qaqland> some aport have done this while some not
2023-10-18 08:54:12 <donoban> >>> qt6-qtwebengine: Build complete at Wed, 18 Oct 2023 00:00:38 +0000 elapsed time 2h 48m 2s
2023-10-18 08:55:26 <donoban> PureTryOut: omni, do you see wrong use use_lld_linker=OFF  for x86?
2023-10-18 08:59:01 <PureTryOut> idk
2023-10-18 09:05:38 <donoban> I feel that this build chain ignores exported CFLAGS and CXXFLAGS
2023-10-18 09:14:02 <donoban> do you like something like this? https://tpaste.us/O8MX
2023-10-18 09:14:17 <donoban> I will try other 32bit archs 
2023-10-18 09:15:35 <PureTryOut> yeah that's fine
2023-10-18 09:16:29 <donoban> in #llvm someone said that -gsplit-dwarf could help reducing memory needed on linkage
2023-10-18 09:16:57 <donoban> but since C(XX)FLAGS seem ignored... it's a little pain to try
2023-10-18 09:17:16 <donoban> and I don't know what drawbacks could it have
2023-10-18 09:42:55 <donoban> ouch, armhf and armv7 fail for different reasons
2023-10-18 09:43:35 <donoban> missing #include <array>
2023-10-18 10:44:03 <ikke> Things using moc on rv64 are constantly hanging
2023-10-18 10:52:25 <PabloCorreaGomez[m]> Can somebody have a look and merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/53601? I realized I have to clean the mips thing from that package, but I'll do that later today, and that missing update is a blocker in downstream
2023-10-18 10:53:19 <PabloCorreaGomez[m]> And thanks a lot in advance :)
2023-10-18 14:18:35 <WhyNotHugo> I'm seeing a recurring pattern of telegram-desktop breaking when one of its dependencies is updated (especially the qt-* stuff).
2023-10-18 14:19:13 <WhyNotHugo> Bumping the pkgrel fixes this, but it's quite annoying that this has to be manually detected and acted upon by someone manually.
2023-10-18 14:21:14 <ncopa> pango testsuite have started to fail for some reason
2023-10-18 14:55:28 <elly> upstreams stop adding weird glibc dependencies challenge
2023-10-18 14:55:55 <elly> today's winner is sys/ifunc.h, which is some arm64 thing
2023-10-18 15:19:16 <skarnet> nobody can beat sys/param.h
2023-10-18 15:19:31 <skarnet> it's not dangerous, but it's *everywhere*
2023-10-18 17:07:09 <donoban> PureTryOut: could you take a look to !53417 ? x86 passed pipeline
2023-10-18 17:57:41 <dhruvin> part ""
2023-10-18 17:57:50 <dhruvin> oops
2023-10-18 17:58:25 <fluix> :(
2023-10-18 18:43:24 <abby> WhyNotHugo: it uses private qt apis
2023-10-18 18:50:10 <abby> "private"
2023-10-18 18:50:28 <abby> and also some other libraries that are not very stable api-wise
2023-10-18 18:50:31 <abby> iirc
2023-10-18 19:25:55 <aparcar> Are alpine images created with superuser privileges or how is the chroot handled? 
2023-10-18 19:28:29 <donoban> what do you mean? docker images? what chroot?
2023-10-18 21:37:54 <ovf> aparcar: ftr apk doesn't necessarily need (ch)root to work, e.g. this works for me (modulo file ownership/permission/installscripts/etc.): apk -p /tmp/apk -X https://dl-cdn.alpinelinux.org/alpine/edge/main --no-cache --allow-untrusted --initdb add apk-tools
2023-10-18 21:38:57 <ovf> this will install apk-tools (together with its dependencies and a base filesystem) into /tmp/apk
2023-10-18 21:39:01 <aparcar> ovf: works for me unless there are post installs cripts
2023-10-18 21:39:11 <aparcar> and in case of busybox, it fails
2023-10-18 21:41:01 <ovf> specifically with busybox, you can do busybox --install -s later on.
2023-10-18 21:43:26 <ovf> otherwise, bwrap is probably your simplest one-stop solution. or use any of the multitude of 'chroot' scripts, e.g. i seem to have arch-chroot from arch-install-scripts installed, or write your own 
2023-10-18 21:45:09 <aparcar> some time ago i added a no-chroot option to apk-tools but it's not backported to any alpine release
2023-10-18 21:45:39 <aparcar> So from my understanding it wouldn't work even with bwrap or am i missing something?
2023-10-18 21:52:37 <ovf> apk certainly works in a chroot, e.g. in https://github.com/alpinelinux/alpine-chroot-install/blob/master/alpine-chroot-install
2023-10-18 21:57:53 <aparcar> so inside a chroot it won't try to run chroot again? 
2023-10-18 22:00:38 <ovf> what's the problem if it does?
2023-10-18 22:01:33 <ovf> a bit unwieldy, but after you run my previous line to install apk-tools, you can use this to install busybox: unshare -rm sh -c 'touch /tmp/apk/etc/resolv.conf && mount --bind /etc/resolv.conf /tmp/apk/etc/resolv.conf && chroot /tmp/apk apk add -X https://dl-cdn.alpinelinux.org/alpine/edge/main --allow-untrusted busybox'
2023-10-18 22:01:49 <ovf> at this point it can probably be written nicer with bwrap
2023-10-18 22:02:27 <aparcar> okay interesting I'll check it out
2023-10-18 22:03:04 <ovf> the bit that's most interesting to you is probably unshare -rm -- this allows mounts and chroots all inside a process that is (from the outside) started from your user
2023-10-18 22:08:48 <aparcar> nice that looks like a good point to start, thank you
2023-10-18 22:09:10 <ovf> this seems to work too: bwrap --bind /tmp/apk / --bind /etc/resolv.conf /etc/resolv.conf apk add -X https://dl-cdn.alpinelinux.org/alpine/edge/main --allow-untrusted busybox
2023-10-18 22:24:08 <aparcar> On my system it doesn’t find apk then but I’ll figure it out 
2023-10-18 22:27:32 <ovf> have you installed apk-tools into /tmp/apk in step 1 (outside of the chroot)? you need to have apk inside the chroot, either by doing that, or pulling the static build like alpine-chroot-install does
2023-10-19 10:45:47 <chereskata> Could someone merge !53127, !52880, !53274, !53277, !53279 ? thanks :)
2023-10-19 13:37:26 <ikke> nmeum: checkapk says: '*** 2 packages linked against libvirglrenderer.so.1 need to be rebuild!' Does it say this regardless of whether the soname has changed? Because the soname version remained the same in this case
2023-10-19 13:56:24 <chereskata> ikke: i have a MR for virglrenderer at !53678
2023-10-19 13:59:18 <ikke> chereskata: yes, I was exactly looking at that
2023-10-19 14:09:01 <nmeum> ikke: oh that's a bug then because it should use the existing logic to determine whether the SONAME changed
2023-10-19 14:10:15 <nmeum> how do I reproduce this?
2023-10-19 14:10:29 <nmeum> also: we should really add unit tests for checkapk to the existing abuild test
2023-10-19 14:12:16 <ikke> There are tests for checkapk 
2023-10-19 14:12:26 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/tests/checkapk_test?ref_type=heads
2023-10-19 14:14:23 <nmeum> oh, quite minimal though :D
2023-10-19 14:16:51 <nmeum> also they were added one day ago
2023-10-19 14:20:45 <nmeum> ikke: ah, the problem for libvirglrenderer.so is that the file name changed but the SONAME didn't and the existing logic doesn't account for that
2023-10-19 14:39:50 <ikke> Tests are easier to add when there is already a framework 
2023-10-19 14:48:09 <nmeum> ikke: should be fixed by https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/229
2023-10-19 14:48:54 <nmeum> should probably also add a test case but checkapk requires an older version of the package to already exist in the repo, not sure how to best do that in the test setup. any ideas?
2023-10-19 15:03:52 <ncopa> we coudl write a fake apk script, that dumps precompiled binary packages
2023-10-19 15:05:14 <ncopa> binaries and package could also be built from source
2023-10-19 15:05:46 <ncopa> could be usefule to have that for testing so depends/provides and rpath and things
2023-10-19 15:06:43 <PabloCorreaGomez[m]> Could someone have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/53355? The corresponding MR in edge is already merged, and fixes a real issue
2023-10-19 15:07:51 <ncopa> done
2023-10-19 15:07:55 <ncopa> thanks!
2023-10-19 15:09:37 <PabloCorreaGomez[m]> Oh, that was fast, thanks a lot ncopa \o/
2023-10-19 22:24:54 <john3d> Hello. I have written a shell script for Alpine Linux to get xkeyboard and also the locale for the correct language in window managers and display managers. Is there already a collection of scripts in Alpine Linux to which this tool would fit?
2023-10-19 22:25:14 <john3d> https://github.com/john3dc/setlocale1
2023-10-20 06:01:40 <ncopa> good morning!
2023-10-20 06:02:01 <ncopa> maybe it could be included in alpine-conf somehow?
2023-10-20 06:02:29 <ncopa> I intend to start up the 3.19 builders today
2023-10-20 06:11:19 <liske> \o/
2023-10-20 06:26:39 <Ermine> Please take a look at mdev-conf!9
2023-10-20 06:30:46 <ncopa> done
2023-10-20 06:35:35 <Ermine> Thank you!
2023-10-20 09:23:37 <ncopa> build-3-19-x86* are up
2023-10-20 09:23:44 <ncopa> and build-3-19-s390x
2023-10-20 09:28:09 <ncopa> build-3-19-ppc64le is up
2023-10-20 09:30:12 <ncopa> build-3-19-armhf too
2023-10-20 09:31:36 <donoban> \o/
2023-10-20 09:33:10 <ncopa> and so is build-3-19-{armv7,aarch64} too now
2023-10-20 09:33:15 <ncopa> all builders are up!
2023-10-20 09:33:57 <donoban> nice
2023-10-20 09:35:27 <ikke> 🎉
2023-10-20 09:41:51 <ncopa> alright! fixing the 3.19 build issues is a priority now
2023-10-20 09:41:53 <ncopa> https://build.alpinelinux.org/
2023-10-20 09:45:33 <clandmeter> would be nice if we would have some repo where we could init the builders and which holds the scripts.
2023-10-20 10:01:14 <ncopa> yes, maybe
2023-10-20 10:05:22 <donoban> omni: PureTryOut , I just opened qutebrowser and read the v3.0.2 chanelog
2023-10-20 10:06:11 <donoban> "Security fixes up to Chromium 116.0.5845.187, including CVE-2023-4863...." the CVE is aleady fixed in qt6-qtwebengine, but I was thinking if is it worth to try to build it with 116-based tag instead 112
2023-10-20 10:09:35 <PureTryOut> I don't think it's a good idea to use a different branch than upstream Qt does tbh. That's just asking for problems
2023-10-20 10:10:35 <donoban> oh yes, let me check
2023-10-20 10:12:20 <donoban> https://github.com/qt/qtwebengine/commit/482839a0d315722f006cdd90a3e2eff97a991b2c uhM
2023-10-20 10:13:23 <donoban> Based on Chromium version:                                      112.0.5615.213 
2023-10-20 10:13:27 <donoban> ok!! 
2023-10-20 11:27:12 <ncopa> seems like there pretty many failures for 3.19 :-/
2023-10-20 12:07:24 <chereskata> (1/19) Purging linux-lts-doc (6.1.58-r0) - are the builders stuck again?
2023-10-20 12:22:40 <ncopa> i think they are just busy building
2023-10-20 12:22:51 <ikke> https://build.alpinelinux.org/
2023-10-20 12:25:22 <ncopa> jp: you need llvm17 for rust 1.73?
2023-10-20 12:25:36 <ncopa> pj: you need llvm17 for rust 1.73?
2023-10-20 12:26:12 <omni> donoban: we spent some time patching various for CVE-2023-4863 early, 87-based chromium used in qt5-qtwebengine by 5c5bcf7ddad7f38e63d551b8a5f3a5e43ed70496
2023-10-20 12:26:40 <ncopa> i wonder if I should just push llvm17, and make it the default llvm
2023-10-20 12:26:49 <ncopa> and do clang17 later
2023-10-20 12:26:58 <ncopa> not sure if they need to happen at the same time
2023-10-20 12:27:30 <pj> ncopa: yes
2023-10-20 12:27:39 <omni> donoban: I'm tracking rss feeds for 87-based, and now also 112-based, qtwebengine-chromium branches and try to do security upgrades as soon as I see them
2023-10-20 12:27:44 <ncopa> and llvm16 cannot be used at all?
2023-10-20 12:28:04 <omni> donoban: but I too saw that message in the release notes
2023-10-20 12:28:24 <pj> well, minimum support llvm is 15
2023-10-20 12:28:33 <ncopa> oh ok
2023-10-20 12:28:37 <pj> I'd like to just keep in sync with what rust uses
2023-10-20 12:28:42 <ncopa> yeah that makes sense
2023-10-20 12:28:48 <ncopa> im just thinking for the stable branches
2023-10-20 12:29:27 <pj> I'm upgrading only on edge
2023-10-20 12:29:53 <ncopa> right. but we have rust in main now, so we need to support it for two years
2023-10-20 12:30:01 <pj> I should probably upgrade on 3.18 as well since it was done before, I just forgot but it could stay on 1.72
2023-10-20 12:30:05 <pj> true
2023-10-20 12:30:16 <pj> but that would be for 3.19
2023-10-20 12:30:23 <ncopa> right
2023-10-20 12:30:37 <ncopa> so, I think that I maybe shoudl just push llvm17 for now
2023-10-20 12:30:48 <ncopa> and work on clang17 separately
2023-10-20 12:30:54 <ncopa> or do you need clang17 too?
2023-10-20 12:31:39 <pj> only llvm/gcc
2023-10-20 12:31:43 <ncopa> ok
2023-10-20 12:32:15 <ncopa> andypost[m]: what do you think about push llvm17 alone?
2023-10-20 12:37:43 <ncopa> so pj could work on rust while we work on clang17
2023-10-20 12:39:44 <pj> I can work on it without llvm17, I just would like to try with llvm17 since only armhf/armv7 fail :>
2023-10-20 12:51:16 <chereskata> Could someone merge !53260, !53127, !53277, !53279
2023-10-20 12:56:04 <ncopa> pj: i have a workaround for armv7/armhf llvm17. it passes now
2023-10-20 12:56:58 <pj> i wonder if it will be applicable to rust too
2023-10-20 12:57:05 <pj> since it fails on llvm16
2023-10-20 12:57:12 <pj> https://gitlab.alpinelinux.org/pj/aports/-/jobs/1150363
2023-10-20 12:58:21 <ncopa> possibly
2023-10-20 12:58:30 <ncopa> ok i'm gonna push llvm17
2023-10-20 12:59:12 <ncopa> chereskata: !53260 appears to need a rebase
2023-10-20 13:02:06 <chereskata> ncopa: thanks 
2023-10-20 13:06:28 <pj> oh, 3.19 builders are already created
2023-10-20 13:12:37 <ncopa> yup!
2023-10-20 13:12:43 <ncopa> i pushed llvm17
2023-10-20 13:13:32 <donoban> omni: yeah I know that the sec fixes were alredy applied, just asking for try 116 chromium but I agree with PureTryOut , better use the same version than qt
2023-10-20 13:16:22 <pj> Shouldn't abuild try to build the dependency if it's missing or am I misremembering something
2023-10-20 13:17:41 <pj> llvm17-dev (no such package):
2023-10-20 13:43:21 <ikke> No, abuild itself is not recursive 
2023-10-20 13:44:44 <pj> I remember it building packages that I had locally modified
2023-10-20 13:46:43 <celie> chereskata: I am unwell and so won't be able to rebase !53260, sorry. You may find a way to take over, and i will close my MR.
2023-10-20 13:47:11 <chereskata> Get well soon!
2023-10-20 13:52:18 <celie> Thanks
2023-10-20 14:02:36 <chereskata> ModemManager MR open here !53742
2023-10-20 14:08:24 <pj> rustc exited with signal: 11 (SIGSEGV) (core dumped)
2023-10-20 14:08:24 <pj> hm
2023-10-20 14:09:56 <ncopa> celie: get well soon!
2023-10-20 14:13:08 <pj> could it be OOM
2023-10-20 14:15:33 <ikke> 1 
2023-10-20 14:21:23 <pj> 🤔
2023-10-20 14:50:50 <andypost[m]> ncopa: thank for note, afk this days but it's great to see llvm17 merged
2023-10-20 14:58:49 <Ermine> get better soon celie !
2023-10-20 15:17:23 <ncopa> libusb-compat changed the release tarball
2023-10-20 15:17:27 <ncopa> https://github.com/libusb/libusb-compat-0.1/releases/tag/v0.1.8
2023-10-20 15:17:46 <ncopa> release and tag was done 2022, but the download artifact is from last week
2023-10-20 17:12:11 <lnl> lmfao https://github.com/zlib-ng/minizip-ng/issues/735
2023-10-20 17:13:12 <ikke> lol
2023-10-20 17:15:00 <quinq> :D
2023-10-20 17:15:36 <chereskata> haha
2023-10-20 17:16:45 <donoban> well, he seems a busy dude
2023-10-20 17:16:55 <elly> oh no
2023-10-20 17:17:57 <quinq> That's how one keeps issues low
2023-10-20 17:19:56 <minimal> hear no evil, see no evil? lol
2023-10-20 17:23:01 <quinq> ^^
2023-10-20 18:41:26 <ikke> acpica source redirects to some intel page
2023-10-21 08:00:58 <omni> donoban: yes, that was the better answer to your question =)
2023-10-21 08:04:45 <omni> personally, I don't mind an older version of a browser as long as security patches are backported
2023-10-21 10:29:58 <omni> I'm confused about rpi and armhf vs armv7...
2023-10-21 10:31:45 <omni> the armhf build is said to be usable for all rpis and armv7 for rpi2 model B https://wiki.alpinelinux.org/wiki/Raspberry_Pi#Preparation
2023-10-21 10:35:10 <omni> now I'm guessing that the armhf build should only be used for rpi1 & rpiZ (BCM2835)
2023-10-21 10:36:10 <omni> and armv7 for rpi2 (BCM2836/7) and later
2023-10-21 10:37:37 <omni> and generally you'd want to use the aarch64 build
2023-10-21 10:37:41 <abby> yes
2023-10-21 10:38:44 <abby> this is the distribution of rpi archs https://docs.voidlinux.org/installation/guides/arm-devices/platforms.html#supported-models (on void we call armhf armv6l)
2023-10-21 10:38:56 <abby> doesn't include 5B but that's aarch64
2023-10-21 10:39:34 <omni> the reason why I'm bringing this up is because I'm thinking of suggesting to enable CONFIG_NEON for armv7 linux-rpi
2023-10-21 10:40:43 <omni> rpi1 & rpiZ (BCM2835) does not have NEON support but later rpis do
2023-10-21 10:40:55 <ikke> armhf is armv6
2023-10-21 10:41:21 <abby> it's set in the rpi armv7 defconfig so it should be safe to do so https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/configs/bcm2709_defconfig#L56
2023-10-21 10:42:48 <omni> then I wonder why we don't have it already
2023-10-21 10:43:59 <omni> the zfs 2.2.0 upgrade brought me here
2023-10-21 10:44:12 <abby> oh
2023-10-21 10:44:27 <abby> that's because linux did their dumb "gpl symbols" thing probably
2023-10-21 10:44:34 <abby> not because the config was disabled
2023-10-21 10:46:09 <omni> I don't think that's it, because zfs-lts will build for aarch64 & armv7 and zfs-rpi will build for aarch64, but not armv7 nor armhf
2023-10-21 10:46:33 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1145076#L917
2023-10-21 10:46:45 <omni> !53430
2023-10-21 10:47:01 <abby> hm, yeah that's not the same message as https://github.com/openzfs/zfs/issues/14555 https://github.com/openzfs/zfs/issues/15401
2023-10-21 11:26:08 <omni> so config-rpi2 does have CONFIG_NEON=y
2023-10-21 11:26:09 <omni> hmm...
2023-10-21 11:26:24 <vkrishn> ncopa: https://tpaste.us/d1zJ, i have removed - rm /etc/runlevels/*/tiny-cloud*, and wondering if this usage for normal qemu vm would be ok ?
2023-10-21 11:27:43 <vkrishn> kinda cool way to prep a VM disk
2023-10-21 11:36:13 <vkrishn> ah, i thought it disables all runlevels, then it should be ok to keep
2023-10-21 11:37:12 <vkrishn> 2. how to not add swap in fstab ?
2023-10-21 12:13:44 <vkrishn> think i found it, setup-disk -s 0
2023-10-21 13:53:13 <ikke> bootstrapping rust on x86_64
2023-10-21 14:35:18 <vkrishn> just booted vm img created using tiny-cloud scripts on a bare metal, i that went well :-)
2023-10-21 14:35:35 <vkrishn> going to write about it soonish
2023-10-21 14:35:41 <ikke> cool
2023-10-21 14:37:31 <vkrishn> i think this method can help in fast testing isos's and images created from it on bare metal, without having to write to dvd or cumbersome usb-write/rewrite
2023-10-21 18:47:53 <elly> whoever wrote abump, it's pretty useful
2023-10-21 19:07:36 <skarnet> ikr
2023-10-21 19:47:46 <ikke> elly: do you also know apkgrel?
2023-10-21 20:33:10 <Habbie> much love for abump
2023-10-21 20:33:18 <Habbie> these days i even remember to git branch before i run it
2023-10-21 20:44:36 <Kladky> I coincidentally just used abump for the first time, now I wonder how I ever lived without it.
2023-10-21 20:45:32 <Kladky> Just cd into aports repo, switch branches, and run.
2023-10-21 20:45:49 <Kladky> Now if only it could make the pr for you aswell.
2023-10-21 20:46:47 <ikke> glab mr create --fill -y
2023-10-21 20:48:44 <Kladky> If one were to add the mr feature to abump, would it be more appropriate to use glab or to just curl the gitlab api?
2023-10-21 20:51:32 <ikke> curl API
2023-10-21 20:54:33 <a16bitsysop> you can just use git push as well
2023-10-21 20:54:45 <ikke> yes
2023-10-21 20:55:20 <a16bitsysop> git push --set-upstream origin $(git rev-parse --abbrev-ref HEAD) -o merge_request.remove_source_branch -o merge_request.create
2023-10-21 20:57:39 <Kladky> TIL
2023-10-21 20:58:59 <Kladky> It seems you can just add this to your gitconfig, so I will probably just do that instead.
2023-10-21 20:59:23 <a16bitsysop> yes you can create an alias for it
2023-10-21 21:00:13 <Kladky> Not an alias, just add those into push.pushOption in your git config
2023-10-21 21:00:16 <ikke> https://docs.gitlab.com/ee/user/project/push_options.html
2023-10-21 21:02:18 <Kladky> git config --local push.pushOptions merge_request.create
2023-10-21 21:02:54 <a16bitsysop> yes setting push.pushOptions would be handy
2023-10-21 21:03:40 <Kladky> Btw, is the remove source branch option not enabled by default?
2023-10-21 21:04:06 <a16bitsysop> I found if I didn’t use it the source branch wasn’t deleted when merged
2023-10-21 21:04:47 <Kladky> Ah, maybe that is just the case on the web interface then
2023-10-21 21:05:08 <ikke> yes
2023-10-22 07:33:52 <ikke> bootstrapping rust on ppc64le
2023-10-22 07:47:00 <ikke> bootstrapping rust on x86
2023-10-22 07:50:36 <ikke> bootstrapping rust on armv7
2023-10-22 08:15:41 <quinq> Good luck
2023-10-22 08:17:25 <ikke> It's actually less involved than it sounds :P
2023-10-22 11:17:29 <ikke> Seeing lots of "connection reset by peer" to github
2023-10-22 11:19:06 <omni> right?
2023-10-22 11:19:34 <quinq> The AI bot is using all the energy
2023-10-22 11:19:51 <omni> are we being throttled by MSGH?
2023-10-22 12:49:34 <vkrishn> ikke: https://wiki.insteps.net/AlpineLinux/Create-bootable-images - now with RAM method too
2023-10-22 13:28:52 <andypost[m]> ikke: is build-edge-armhf accessible? Hanging on rakudo for a day
2023-10-22 13:30:31 <ikke> Some kind of busy loop I suppose
2023-10-22 13:32:42 <andypost[m]> Thanks)
2023-10-22 13:33:23 <celie> There's also build-3-19-s390x that seems to be stuck on perl-server-starter
2023-10-22 13:39:07 <celie> omni: Since you've opened an MR on main/charybdis, i think there's another IRC-related aport that's no longer developed upstream: community/ircservices
2023-10-22 19:16:57 <omni> celie: I was mostly looking at aports to move from main before 3.19 release so that they don't need to have support for too long
2023-10-22 19:17:15 <omni> and then also noticed that charybdis was archived
2023-10-22 20:23:22 <ikke> ayakael: dotnet6 fails to build on 3.19 due to a conflict with llvm16/17 / clang16/17
2023-10-22 21:02:49 <omni> it's probably just me but I currently cannot reach build.a.o
2023-10-22 21:03:06 <ikke> reachable here
2023-10-22 21:17:46 <ikke> omni: what does it resolve to for you?
2023-10-22 21:21:51 <omni> deu5-dev1
2023-10-22 21:22:57 <omni> it's not just that site, it seems, so something over here...
2023-10-22 21:23:41 <ikke> ipv4 or ipv6?
2023-10-22 21:26:21 <omni> legacy ip works
2023-10-22 21:29:22 <quinq> IPv3?
2023-10-22 21:33:18 <omni> IPX
2023-10-23 05:06:12 <ikke> PureTryOut: can you take a look at qt*-base not building for 3.19?
2023-10-23 05:29:54 <ikke> bootstrapping rust on s390x
2023-10-23 07:37:00 <ptrc> i got curious after running into the same issue for the nth time and... apparently there's 81 packages in community that do `import pkg_resources` or `from pkg_resources import ...` that don't actually depend on setuptools
2023-10-23 07:37:39 <ptrc> annoyingly, a lot of those don't actually specify a runtime dependency on setuptools, because everyone assumes it exists, since users usually have pip ( and thus setuptools )
2023-10-23 07:40:59 <ptrc> and even more annoyingly, not all of them are breaking - some of them are used only as a fallback if proper data is not available, as is the case with ansible-lint: https://github.com/ansible/ansible-lint/blob/v6.21.1/src/ansiblelint/version.py
2023-10-23 07:49:34 <celie> Did you download all Python packages, or did you use some code search engine?
2023-10-23 07:59:33 <ptrc> celie: i've got a local mirror of edge x86_64
2023-10-23 08:06:30 <celie> Ok :)
2023-10-23 08:53:46 <PureTryOut> ikke: not currently. Tonight I can
2023-10-23 08:57:19 <ikke> I've created an issue for it
2023-10-23 09:01:39 <celie> ptrc: I just remembered something regarding pkg_resources
2023-10-23 09:03:15 <celie> Compare /usr/bin/txt2tags from txt2tags 3.8-r1 (in 3.18-stable) and 3.9-r0 (in edge)
2023-10-23 09:04:45 <celie> The one in 3.18-stable refers to pkg_resources but not the one in edge, and i think it's due to the gpep517 migration
2023-10-23 09:21:23 <ptrc> well, it's the setuptools entrypoint script template
2023-10-23 09:21:48 <ptrc> but it doesn't use pkg_resources unless it *really* has to
2023-10-23 09:22:33 <celie> Ok
2023-10-23 10:23:33 <ikke> hmm, opencv on rv64 fails with: `The C++ compiler "/usr/bin/clang++" is not able to compile a simple test program.`
2023-10-23 10:23:44 <ikke> End then a lot of: "d.lld: error: /usr/lib/Scrt1.o:(.debug_loclists+0x16): unknown relocation (60) against symbol .LVL0"
2023-10-23 13:17:50 <ncopa> i think we need update clang to 17
2023-10-23 13:18:00 <ncopa> clang 16 with llvm17 will likely not work
2023-10-23 13:52:19 <chereskata> Hi, could someone merge !53278
2023-10-23 14:07:47 <ikke> chereskata: did you check revdeps that need to be rebuilt?
2023-10-23 14:08:33 <chereskata> i am waiting for CI/CD to pass to check the SODIFF
2023-10-23 14:08:53 <chereskata> I merged the liborcus upgrade into the MR above
2023-10-23 14:11:59 <chereskata> I will notify once it is ready again
2023-10-23 14:24:48 <bl4ckb0ne> celie: i reported the armv7 to mold, its strange that armhf skips the tlsdesc tests as expected, but not armv7
2023-10-23 14:27:03 <ikke> chereskata: i already saw it changed 
2023-10-23 14:29:58 <chereskata> thanks: i bump it atm
2023-10-23 14:40:11 <celie> bl4ckb0ne: Ok, thanks
2023-10-23 14:40:15 <chereskata> Done, as the only depending package is libreoffice, the builders will take some time
2023-10-23 14:42:16 <chereskata> Could someone check !53127
2023-10-23 14:42:33 <bl4ckb0ne> is the clang17 update in progress?
2023-10-23 14:44:11 <quinq> Is the webkitgtk update in progress? :]
2023-10-23 14:58:59 <bl4ckb0ne> weee fixed
2023-10-23 15:01:19 <celie> :)
2023-10-23 16:40:52 <andypost[m]> as I see !53744 is green, so ncopa to decide
2023-10-23 16:52:59 <zv> is there a good reason why 'apk upgrade -a' is not the default?
2023-10-23 17:00:44 <elly> (don't know but curious)
2023-10-23 17:17:50 <khem> ncopa: -fno-semantic-interposition is interesting I see your clang17 patch defaultitng to it
2023-10-23 17:26:52 <ovf> looks like nheko is broken, and interestingly enough https://pkgs.alpinelinux.org/package/edge/community/x86_64/nheko doesn't show the fact there's a missing dependency (so:libgstqmlgl.so which used to be in gst-plugins-good-qt, now called libgstqml6.so)
2023-10-23 19:04:01 <WhyNotHugo> I accidentally use `git checkout main`, intending to check out the main branch, and this checks out the 'main' repository, discarding my local changes.
2023-10-23 19:05:24 <ikke> oof
2023-10-23 19:05:55 <ikke> one more victim of the master -> main rename :P
2023-10-23 19:06:13 <WhyNotHugo> Maybe rename main to core?
2023-10-23 19:07:16 <WhyNotHugo> ikke: I usually use ma<tab> usually, but it's a problem in the case of aports.
2023-10-23 19:07:59 <ikke> I do gco m<tab>, and it always completes to master for me
2023-10-23 19:08:15 <ikke> (gco == git checkout
2023-10-23 19:08:17 <ikke> )
2023-10-23 19:08:46 <ikke> WhyNotHugo: maybe you should start using git switch ;-)
2023-10-23 19:15:27 <quinq> And quit hitting tab
2023-10-23 19:18:27 <Ermine> The problem is when you start hitting tab in IRC and except it to figure out what do you want to say
2023-10-23 19:19:49 <Ermine> s/except/expect/
2023-10-23 19:21:31 <ikke> Ermine: :D
2023-10-23 19:28:56 <quinq> haha Ermine, indeed
2023-10-23 19:31:29 <omni> wait, have we switched to main? I've totally missed that
2023-10-23 19:32:07 <omni> but more urgently, where did I put my alpine milk chocolate?
2023-10-23 19:32:20 <quinq> In your nose?
2023-10-23 19:32:46 <ikke> omni: we have not
2023-10-23 19:34:14 <omni> ok
2023-10-23 19:35:08 <omni> I also found my alpine milk chocolate, it was in the bathroom ??
2023-10-23 19:35:32 <quinq> We can't confirm nor deny that
2023-10-23 19:38:22 <omni> alpine milk chocolate & alpine linux, such waist
2023-10-24 04:30:27 <celie> It seems py3-bleach vendors an old version of urlparse and tests for that behavior, it seems we deselected one such test due to changes in Python 3.9, and we'll have to deselect another one for Python 3.11: !53945 (the new failing test was caught by the 3.19 builders)
2023-10-24 04:33:16 <celie> I mean, py3-bleach upstream vendors urlparse, and we devendor it, which causes the tests to fail
2023-10-24 04:38:01 <celie> The Github issue i linked to in the MR mentions that the test fails on OpenSUSE and Fedora too, i checked Debian, but it seems Debian leaves the urlparse vendored: https://packages.debian.org/bookworm/all/python3-bleach/filelist
2023-10-24 06:21:27 <ncopa> khem: i dont remember why we added that, will have to dig up the git log
2023-10-24 06:24:09 <ncopa> 7fe048afcdc1df16f37ab235c0ab879348a36713
2023-10-24 06:24:51 <ncopa> looks like it was added for performance reasons
2023-10-24 09:07:44 <indy> hi all, i have problem with pycache subpackage "-pyc" and jfrog. seems abuild automaticaly creates noarch package which is problematic for jfrog
2023-10-24 09:08:10 <indy> can i override pyc package from noarch to all? somehow?
2023-10-24 09:11:54 <WhyNotHugo> omni: Switching to main right now would be a nightmare because 'git checkout main' becomes ambigous in a very nasty way.
2023-10-24 09:26:56 <omni> I haven't thought about it
2023-10-24 09:29:18 <ncopa> im trying to boot my rpi4, but i get nothing on the screen. I have tried alpine 3.16, 3.17 and 3.18. i wonder if it broke somehow
2023-10-24 09:53:38 <ncopa> ok i got it booting now. needed to set proper partition type on the boot media
2023-10-24 13:11:24 <andypost[m]> ncopa: this comment still valid? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51171#note_346536
2023-10-24 13:13:55 <ncopa> andypost[m]: yes sort of. I have another MR with clang work i have done, but I have been busy
2023-10-24 13:14:04 <ncopa> it still needs get the tests running
2023-10-24 13:14:30 <ncopa> and i think that we need to fix llvm17 package to also build an llvm-googletest subpackage
2023-10-24 13:14:35 <ncopa> thats what fedora does
2023-10-24 14:09:49 <chereskata> Could someone merge !52683, !53127, !53677, !53728
2023-10-24 14:38:58 <nmeum> any thoughts on !53418 ?
2023-10-24 14:39:10 <nmeum> do we generally want OpenRC service (which do not log to syslog by default) to log to syslog via logger(1)?
2023-10-24 14:39:20 <nmeum> *services
2023-10-24 14:41:30 <nmeum> acpid seems to just log acpi events ala. "acpid: PWRF/00000080" so might clutter the daemon syslog a bit? but idk, don't really have a strong opinion on this
2023-10-24 14:47:11 <skarnet> nmeum: if a service has its dedicated logging stream, it's a waste to funnel it into syslog
2023-10-24 14:49:12 <skarnet> the main problem is that OpenRC doesn't have good support for a full logging infrastructure, and syslog is a workaround for that (that's historically why syslog exists: daemons didn't want to write to stderr because everyone redirected it to /dev/null)
2023-10-24 14:50:39 <skarnet> the real fix is to have better logging support (yes, s6 does that); the quick fix, if you want acpid's logs, is to redirect acpid's logs to some file and logrotate it
2023-10-24 14:51:41 <minimal> which is what the existing package does
2023-10-24 14:53:24 <skarnet> perfect then
2023-10-24 14:53:45 <skarnet> leave syslog out of it :)
2023-10-24 14:54:30 <minimal> whereas as "full" acpid uses syslog
2023-10-24 14:55:13 <skarnet> lol
2023-10-24 14:56:08 <minimal> actually, no it doesn't as its init.d specified ~"--foreground" which makes it write to stderr instead lol
2023-10-24 14:58:45 <minimal> it would make sense for Busybox's acpid and the "full" acpid to be configured to work in the same fashion
2023-10-24 14:58:55 <skarnet> yeah
2023-10-24 15:04:46 <raspbeguy> hello, could you give an eye to !53681 and to !53868 please?
2023-10-25 00:47:30 <omni> algitbot: retry 3.18-stable
2023-10-25 01:07:35 <andypost[m]> omni: fixed via 447c3edc1fac
2023-10-25 02:30:50 <celie> omni: Could you have a look at !54027 when you have time? I think it solves #15257, so you'll probably have to backport it, at least the first commit removing typing-extensions from setup.cfg
2023-10-25 02:33:22 <celie> Solving #15257 is complicated a little bit by migrating to gpep517 which uses a different template for generating /usr/bin/pgcli, which does not check for requirements (i mentioned this difference here a few days ago, using the txt2tags aport as an example)
2023-10-25 02:36:11 <celie> In other words, to solve that issue on 3.18, from what i see, you'll either have to backport the gpep517 migration of pgcli (so it uses the /usr/bin template that does not check for requirements), or you'll have to backport the removal of typing-extensions from setup.cfg of py3-psycopg (so typing-extensions is removed from the requirements)
2023-10-25 02:37:34 <celie> I'm leaning more towards the latter as it prevents the problem from occurring should any other aport use the non-gpep517 /usr/bin template
2023-10-25 02:44:25 <celie> You may double check my findings: in edge, i tried /usr/bin/pgcli of pgcli-3.5.0-r2 from before the gpep517 migration, and i get the error in #15257, after removing typing-extensions from setup.cfg, i no longer get the error (of course, pgcli-3.5.0-r3 doesn't have the error in either case as it doesn't check for requirements)
2023-10-25 02:55:45 <celie> To further summarize what i just said, while it looks like #15257 was solved by !54017, it was actually solved (sort of) by migrating to gpep517 in !53999
2023-10-25 02:57:56 <celie> So, for backporting to 3.18, we could consider either migrating pgcli to gpep517, or removing typing-extensions from setup.cfg of py3-psycopg
2023-10-25 07:51:35 <omni> for the first time I felt that algitbot wasn't really helpful ;)
2023-10-25 07:51:38 <omni> andypost[m]: thanks
2023-10-25 07:53:51 <omni> celie: so backport to 3.18 removal of typing-extensions from setup.cfg or switch to gpep517 for pgcli?
2023-10-25 08:10:07 <celie> omni: Yes, i'm learning more towards removal of typing-extensions, just in case there's something else that uses py3-psycopg and hasn't been migrated to gpep517 yet
2023-10-25 08:13:06 <celie> and the typing-extensions patch was already updated in 3.18 yeaterday, so this removal from setup.cfg is just a follow-up on that, and should finally solve #15257 for good
2023-10-25 08:14:20 <omni> but it's still an issue even though the typing-ext.patch update?
2023-10-25 08:15:37 <celie> omni: My comments from the MR are already in the commit message, or did i leave something out?
2023-10-25 08:16:30 <celie> It is still an issue for 3.18, in edge, this is sort of solved by the migration to gpep517, which generates a /usr/bin/pgcli that does not check for requirements on startup
2023-10-25 08:17:43 <omni> sorry, didn't see that there were two commits
2023-10-25 08:17:58 <omni> the comments are in the first one
2023-10-25 08:18:58 <omni> and I didn't see that under the changes view until I went to commits, clicked on the first commit and got to the changes view with that full commit message *sigh*
2023-10-25 10:35:34 <singham> The size of alpine-uboot tarball is constantly increasing
2023-10-25 10:35:51 <singham> The current one is just off the charts 3.18n
2023-10-25 10:35:59 <singham> 3.18
2023-10-25 10:36:34 <singham> Is it possible to do something like Genode does, take the parts of linux which are used in alpine?
2023-10-25 10:40:12 <singham> 3.16 -> 3.18
2023-10-25 10:40:29 <singham> 70 -> 85 MB!!
2023-10-25 10:40:51 <singham> 20% increase within a year!
2023-10-25 10:45:44 <ikke> singham: probably best to open an issue for that
2023-10-25 10:46:54 <singham> Where do I open?
2023-10-25 10:47:10 <singham> I saw, miniroot systems! alpine is so awesome!
2023-10-25 10:47:18 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/
2023-10-25 10:47:21 <singham> miniroot just lacks a kernel right?
2023-10-25 10:47:26 <ikke> and init system
2023-10-25 10:47:35 <ikke> The target is docker containers
2023-10-25 10:48:22 <singham> So with miniroot, can one use runit say?
2023-10-25 10:48:29 <ikke> sure
2023-10-25 10:48:34 <singham> miniroot, linux and runit
2023-10-25 10:48:51 <singham> Or miniroot, linux-libre and runit?
2023-10-25 10:49:26 <singham> fantastic!
2023-10-25 10:50:06 <singham> I will surely open an issue
2023-10-25 10:50:17 <ikke> You'd need to make sure everything is setup properly though
2023-10-25 10:50:27 <ikke> things that are normally arranged through openr
2023-10-25 10:50:29 <ikke> openrc
2023-10-25 10:51:52 <singham> Yes, currently I'm installing alpine on my new Orange Pi R1
2023-10-25 10:52:19 <singham> Major size taken in tarball is by linux right?
2023-10-25 10:52:33 <ikke> linux + firmware
2023-10-25 10:58:35 <singham> Yes, boot directory is heavy!
2023-10-25 11:01:03 <Ermine> You can try building a kernel tailored to your hardware and pick up only firmware you need
2023-10-25 11:16:15 <singham> How much would that bring down the size of it?
2023-10-25 11:25:30 <Ermine> it depends
2023-10-25 11:27:53 <singham> Still, worst and best case?
2023-10-25 11:36:05 <singham> linux source is so so gigantic!
2023-10-25 11:36:18 <singham> And 9k lines config!!!! 
2023-10-25 11:36:24 <singham> Insane!
2023-10-25 13:17:21 <minimal> singham: alpine-uboot is for *generic* Arm systems, over time support is added for more SBCs and therefore the size increases (as different SBCs require additional driver modules).
2023-10-25 13:17:48 <minimal> the only way to try and stop it growing would be to stop adding support for more SBCs
2023-10-25 15:17:04 <singham> https://orangepi.com/index.php?route=product/product&path=237&product_id=861
2023-10-25 15:17:14 <singham> What is the right way to access this board?
2023-10-25 15:21:05 <WhyNotHugo> Upstream for wayland compositors, seatd and related tools discourage users having direct access to video hardware.
2023-10-25 15:21:25 <WhyNotHugo> However, on Alpine, the 'video' group is dual-purposed; it grants access to video rendering hardware AND to video input hardware..
2023-10-25 15:21:46 <WhyNotHugo> So there is no way to grant my user access to the webcam without suddently giving all my user's processes raw access to the GPU.
2023-10-25 15:22:35 <ikke> I suppose you'd have to adjust the *dev config to use a different group for input devices
2023-10-25 15:23:22 <WhyNotHugo> ikke: Yeah, basically things would need to be split in two groups.
2023-10-25 15:23:40 <WhyNotHugo> But I feel that this is something that should happen at a distro level, since there's a security issue at hand here.
2023-10-25 15:27:07 <ikke> WhyNotHugo: why are graphical output devices more sensitive as input devices?
2023-10-25 15:27:43 <WhyNotHugo> They're not. Access to input devices is also mediated via something like seatd.
2023-10-25 15:28:55 <WhyNotHugo> (I can run sway just fine without being a member of the 'input' group)
2023-10-25 15:29:09 <donoban> I have camera:x:127:
2023-10-25 15:29:13 <ikke> I mean what you meantioned, like webcams
2023-10-25 15:29:27 <donoban> i don't know what created it, but looks a better group for the webcam
2023-10-25 15:31:02 <WhyNotHugo> This does seem to be an upstrem eudev issue though
2023-10-25 15:31:31 <WhyNotHugo> I don't have a camera group, and only one rule seems to mention it. Check: ag camera /usr/lib/udev/rules.d /lib/udev/rules.d /etc/udev/rules.d
2023-10-25 15:38:27 <singham> How do I enable uart at certain pins before bootup?
2023-10-25 15:38:54 <ikke> singham: isn't that something board specific?
2023-10-25 15:39:21 <singham> Yes, how to do it?
2023-10-25 15:39:46 <singham> https://orangepi.com/index.php?route=product/product&path=237&product_id=861 
2023-10-25 15:39:59 <singham> On top left, there are 3 pins
2023-10-25 15:40:46 <singham> UART, I want to enable access to this board only via those pins and not any other ones
2023-10-25 15:41:46 <donoban> omni: I can't reproduce :\ , I'm running https://silver.urih.com/ with many tabs and windows, 99% cpu usage on a QtWebEnginneProcess... and I can type reliable, scrolling is pretty slow but acceptable
2023-10-25 15:58:50 <WhyNotHugo> singham: Does the hardware even support mapping arbitrary pins to an UART? What are you trying to do?
2023-10-25 15:59:28 <singham> Ofc. All hardware with GPIO can do so
2023-10-25 16:00:16 <singham> I am trying to enable input output via those pins at bootup so I can access it
2023-10-25 16:01:31 <WhyNotHugo> singham: You can expose an UART over arbitrary pins via software. But you won't get an early-boot UART.
2023-10-25 16:01:45 <WhyNotHugo> This sound off-topic, isn't #alpine-linux a better fit?
2023-10-25 16:03:32 <singham> No one is replying there
2023-10-25 16:04:23 <singham> So say, I change config.txt and add a line saying throw up a console at uart
2023-10-25 16:44:15 <celie> Did libdrm_intel.so.1 get removed in !54058?
2023-10-25 16:46:16 <celie> Ah, !54086 should fix it
2023-10-25 18:24:15 <bl4ckb0ne> celie: I can merge it if you need it soon
2023-10-25 18:27:01 <hjaekel> Hi, what happened to libdrm_intel.so.1?
2023-10-25 18:32:23 <bl4ckb0ne> see !54086
2023-10-25 18:38:29 <hjaekel> Ah ok, the patch is already available. My local build fails because the library is missing
2023-10-25 18:39:52 <bl4ckb0ne> alright then, merging
2023-10-25 18:40:47 <hjaekel> thank you
2023-10-25 20:39:13 <omni> donoban: thanks for trying, I may have an even older laptop or something
2023-10-25 20:39:43 <omni> but it's not always, sometimes it's fine, and I guess I only check load when I experience the issues
2023-10-25 20:42:57 <omni> !54104 don't we prefer one commit per moved aport? I mean, I guess a single MR for them is fine, even thought they don't seem to depend on eachother or belong together
2023-10-25 20:45:43 <mio> omni: sorry if 1 per MR is preferred. since drops and adopts were in batches, had initially thought it was okay
2023-10-25 20:46:25 <ikke> we mostly prefer separate commits for each package, but in case a change affects many packages, they can be bundled
2023-10-25 20:47:09 <mio> sorry. would you like me to close this one and split them up?
2023-10-25 20:47:45 <ikke> mio: no need to close the MR, you can update the branch instead
2023-10-25 20:48:47 <mio> update the branch?
2023-10-25 20:48:58 <mio> oh, separate commits
2023-10-25 20:49:20 <ikke> A single MR is fine
2023-10-25 20:49:45 <mio> separate commits unsquashed ... sure, will do
2023-10-25 21:12:18 <ptrc> https://ptrc.gay/gvuzeWww
2023-10-25 21:12:25 <ptrc> any clue why it breaks?
2023-10-25 21:12:35 <ptrc> ikke: i remember you used glab to merge stuff, does that work for you?
2023-10-25 22:27:55 <omni> donoban: maybe it's latency/sometimes crappy connection, and that gitlab wants to do a lot of back-and-forth, but not sure why PyQt6/112-based ChromiuOCOCOCm would be worse than  PyQt5/87-based Chromium
2023-10-26 00:22:15 <andypost[m]> omni: > re py3-qt6: https://www.riverbankcomputing.com/pipermail/pyqt/2023-October/045553.html
2023-10-26 02:24:47 <ikke> ptrc: yes, but with a patched version 
2023-10-26 02:26:31 <ikke> ptrc: 405 can mean there are unresolved comments, the source branch is protected or there are conflicts 
2023-10-26 08:13:56 <indy> hi all, how to link https://security.alpinelinux.org/vuln/CVE-2022-40897 to https://security.alpinelinux.org/srcpkg/py3-setuptools
2023-10-26 08:14:19 <omni> andypost[m]: but soon https://www.riverbankcomputing.com/pipermail/pyqt/2023-October/045561.html
2023-10-26 08:14:22 <omni> https://www.riverbankcomputing.com/pypi/simple/pyqt6/
2023-10-26 11:45:49 <singham> Folks, typically for uart, one has to add
2023-10-26 11:46:25 <singham> a line in config.txt but here in R1, I am unable to understand how to do it
2023-10-26 11:59:21 <omni> I'm not entirely sure about check() in !54145 if someone would like to have a look
2023-10-26 13:00:46 <omni> I cannot rebase !54117
2023-10-26 13:01:29 <ikke> omni: how so?
2023-10-26 13:03:56 <omni> ikke: on the swipeguess MR, gitlab says "Something went wrong. Please try again." and I'm also not allowed to force-push to it with git
2023-10-26 13:04:29 <ikke> interesting, rebased just fine f or me
2023-10-26 13:05:53 <omni> perhaps it's due to your über privileges
2023-10-26 13:06:28 <ikke> Normally it's because the branch is protected, but that was not the case
2023-10-26 13:15:43 <omni> yeah, it was a bit odd...
2023-10-26 14:03:58 <PabloCorreaGomez[m]> Is there any chance that anybody with some knowledge about shells can have a look at !54014?
2023-10-26 14:04:17 <PabloCorreaGomez[m]> Part of the discussion is unfortunately split into #15396
2023-10-26 14:33:38 <omni> should we gpep517 all the py3-things in main before release?
2023-10-26 14:37:48 <minimal> omni: related to that, I was going to gpep517 one of my packages but wasn't sure if the 
2023-10-26 14:38:22 <minimal> oops, if in the "package" stage you can pass options to "python3 -m installer"
2023-10-26 14:38:50 <minimal> my existing "package" section passes some package-specific options
2023-10-26 14:40:18 <minimal> i.e. https://git.alpinelinux.org/aports/tree/community/cloud-init/APKBUILD#n100
2023-10-26 14:40:44 <minimal> the "--init-system" option
2023-10-26 14:44:18 <omni> I'm not sure if I'm the right person to answer that (yet =) but I'd search the git history for "gpep517" for guidance
2023-10-26 14:44:58 <minimal> I did a brief search of packages already converted and didn't notice any handling such extra options
2023-10-26 14:46:30 <omni> ok
2023-10-26 14:56:05 <omni> a rough estimate is that there are ~50 aports in main that would need to be converted and closer to 600 in community
2023-10-26 15:12:27 <kuna1> Hi, i am trying to cross compile for armv7 with CBUILDROOT=~/sysroot-armv7 ~/aports/scripts/bootstrap.sh armv7 but it failes with openssh. Can anyone help me out?
2023-10-26 15:19:29 <kuna1> this is the last output https://pastebin.com/MkUy5qhy
2023-10-26 15:37:00 <ncopa> kuna1: do you think you could include the compiler error?
2023-10-26 15:37:45 <ncopa> seems like it fails building the testsuite
2023-10-26 15:37:49 <ncopa> make[1]: *** [Makefile:21117: test/p_test.so] Error 1
2023-10-26 15:38:07 <ncopa> i dont think building test suite makes any sense when crosscompiling
2023-10-26 15:38:17 <ncopa> you cannot run it anyway
2023-10-26 15:45:12 <kuna1> so i should ignore this and procees to the cross compile?
2023-10-26 15:47:53 <kuna1> @ncopa i posted the error in pastebin link above. You want some more input?
2023-10-26 16:20:45 <kuna1> @ncopa: thx, I was able to cross compile the kernel. now a question, i want to continue using the diskless mode, do i need to manually change the kernel files and make the modloop????
2023-10-26 18:09:08 <mio> omni: following on the topic of converting packages to gpep517, what happens to packages that don't seem to be compatible yet? if they are in testing, do they remain in testing, or for community, where do they go?
2023-10-26 18:27:24 <omni> I don't think they need to go anywhere
2023-10-26 18:30:46 <mio> omni: okay, thanks
2023-10-26 20:28:23 <kuna1> i was able to build an x86 iso image, but i want an armv7 archive. when trying "aports/scripts/mkimage.sh --tag v3.18 --outdir ~/outdir/ --repository https://dl-cdn.alpinelinux.org/alpine/v3.18/main --profile uboot --arch armv7" i got the error:
2023-10-26 20:28:26 <kuna1> WARNING: updating and opening https://dl-cdn.alpinelinux.org/alpine/v3.18/main: UNTRUSTED signature
2023-10-26 20:28:26 <kuna1> fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/armv7/APKINDEX.tar.gz
2023-10-26 20:29:15 <kuna1> so far i am trying to build from public repo, after success i want to try with modified kernel which i need to support some display connected.
2023-10-26 20:29:56 <kuna1> i am building on x86_64 VM
2023-10-27 10:21:46 <aparcar> what is a good strategy to build a local git repository via abuild? I need to figure out what to patch and rather work with a local repository than pulling in patch files in and out
2023-10-27 10:47:20 <WhyNotHugo> aparcar: I just commit my changes into my own master branch, and just rebase from upstream when I pull.
2023-10-27 10:47:30 <WhyNotHugo> This is likely not a good approach if you want to share the repository with others.
2023-10-27 15:04:28 <omni> aports up for adoption before they get removed from testing: !54248
2023-10-27 15:30:37 <WhyNotHugo> In case anybody cares: here is a list of orphan packages in testing and their last commit: https://paste.sr.ht/blob/5d7e6a75f593dd7f7f0589c2ec1d1ef6300fe06f
2023-10-27 16:48:43 <tomalok> andypost[m]: !54262 should fix #15407 -- just waiting for s390x build
2023-10-27 16:50:56 <andypost[m]> tomalok: thank you! let's merge it and unblcok builders
2023-10-27 16:52:04 <tomalok> fwiw the non-inotify cachefilesd will probably also need the patch
2023-10-27 17:07:24 <tomalok> !54263
2023-10-27 17:12:55 <fluix> asked this in a comment, but how do we proceed with https://gitlab.alpinelinux.org/alpine/aports/-/issues/15193
2023-10-27 17:13:17 <fluix> do we wait for someone to comment? is it a TSC issue? not sure how things work in that regard :)
2023-10-27 17:54:05 <Saijin_Naib[m]> WhyNotHugo that's a lot, and a lot I use... 
2023-10-27 17:54:24 <Saijin_Naib[m]> I can probably take those over in testing for now, at least 
2023-10-27 17:56:58 <Saijin_Naib[m]> I think thermald should probably go Community, if not main, since it provides important thermal protection for Intel CPUs, so that might be beyond me currently 
2023-10-27 18:12:06 <Saijin_Naib[m]> <Saijin_Naib[m]> "I can probably take those over..." <- The like 5 things I use, I mean, not that whole thing 
2023-10-27 18:31:19 <WhyNotHugo> Saijin_Naib[m]: Sure, please do.
2023-10-27 18:31:35 <WhyNotHugo> I'd prefer to delete as few as possible ;)
2023-10-27 18:48:18 <Saijin_Naib[m]> Me too 🤣
2023-10-27 18:48:37 <Saijin_Naib[m]> Anyone willing to bring thermald out of testing? 
2023-10-27 18:49:11 <WhyNotHugo> Saijin_Naib[m]: Can't you submit a PR moving it into community?
2023-10-27 18:49:27 <WhyNotHugo> Check the pre-conditions in the documentation.
2023-10-27 18:49:39 <Saijin_Naib[m]> Not without a maintainer, right? 
2023-10-27 18:49:59 <Saijin_Naib[m]> I don't think I can be relied upon for community packaging yet
2023-10-27 18:51:45 <fluix> packages shouldn't really stay in testing for a while anyways, unless they're projects that are still in early/unstable development
2023-10-28 01:31:36 <Saijin_Naib[m]> WhyNotHugo: Here we go :D
2023-10-28 01:31:36 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54269
2023-10-28 05:05:50 <celie> omni: snort & snort-extra 3.1.73.0 are out, so you can update !54023
2023-10-28 12:27:25 <omni> thanks
2023-10-28 12:39:17 <omni> uh-oh, no space left on device on arm builders
2023-10-28 14:46:12 <ikke> builders or CI?
2023-10-28 14:47:16 <ikke> builders
2023-10-28 15:03:54 <chereskata> I think !54110, !54234, !53915 and !52683 are ready to merge
2023-10-28 15:18:52 <chereskata> thanks :)
2023-10-28 15:20:05 <omni> 3.18-stable would probably need firefox and chromium security upgrades too
2023-10-28 15:31:36 <ikke> omni: arm builders should have plenty of space again
2023-10-28 19:41:48 <ikke> Executing busybox-1.36.1-r13.trigger
2023-10-28 19:41:50 <ikke> [1]    4456 segmentation fault  abuild-apk fix
2023-10-28 21:50:44 <khem> here is my first port addition to alpine @ncopa :), any feedback is welcome, I might have missed some dev steps 
2023-10-28 21:50:56 <khem> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54325
2023-10-29 11:07:17 <ovf> ikke: thank you for approving my recent merge request for evolution*. in general, should i do this whenever i feel that something (trivially updateable) is out of date for too long? also, i probably have asked this before but the answer hasn't stuck with me: how reverse dependencies are handled? i.e. if i propose to upgrade something that has dependants, who/how rebuilds those?
2023-10-29 11:32:17 <omni> it is probably good to include additional rebuild commits, if needed, in the same MR
2023-10-29 11:33:09 <omni> that way they are both tested to work with the gitlab CI and also get in immediately when the MR is accepted and merged
2023-10-29 14:35:15 <omni> ovf: and MRs are always welcome
2023-10-29 14:36:40 <omni> !38098 !54353 I don't get why ipxe.usb would grow like that
2023-10-29 16:41:15 <ovf> omni: thanks. is there something i should use to gether revdeps? i seem to remember i was recommended lua-aports, but 'ap revdep evolution-data-server' doesn't produce the expected output (to match pkgs.alpinelinux.org)
2023-10-29 16:41:22 <ovf> s/gether/gather/
2023-10-29 16:43:52 <ikke> ovf: you need to check the -dev subpackage
2023-10-29 16:43:57 <ikke> ap revdep evolution-data-server-dev
2023-10-29 16:44:31 <ovf> oh! sorry, that was stupid
2023-10-29 17:18:37 <omni> it wasn't =)
2023-10-30 00:39:50 <celie> omni: I wonder if !54372 still uses system zstd, looking for clues in the build log, i see -Izstd and -DZSTD_SINGLE_FILE
2023-10-30 00:47:37 <celie> https://github.com/indygreg/python-zstandard/blob/main/setup_zstd.py#L57 and #L81 probably confirms that it isn't system zstd anymore
2023-10-30 00:52:10 <celie> I see you've updated it, but the tests still fail
2023-10-30 00:52:40 <omni> yes =/
2023-10-30 00:53:15 <omni> I forgot to add the option in the first run
2023-10-30 00:54:00 <celie> Any idea if the tests fails without the gpep517 (so i'm thinking about a simple rebuild)?
2023-10-30 00:54:01 <omni> now I just squashed the commits, because I forgot to do that too
2023-10-30 00:57:31 <celie> and the zstandard enable on armhf & s390x commit also ended up in !54370
2023-10-30 00:57:53 <omni> yes, there's where I tried it first
2023-10-30 00:58:03 <omni> and the tests run
2023-10-30 00:58:15 <omni> and pass
2023-10-30 00:58:54 <celie> Ah, okay, so i almost answered my own question :D
2023-10-30 01:02:19 <celie> Hmm, from the log in !54370, it doesn't look like zstandard is using pytest
2023-10-30 01:04:19 <celie> Perhaps you can try -m unittest in 54372, but i would be a little surprised if that allows the tests to pass..
2023-10-30 12:34:54 <omni> celie: I tried locally and it didn't, also tried a few other things, maybe it's just not ready yet
2023-10-30 16:12:18 <celie> Alright, maybe we should just focus on migrating main/ to gpep517 for 3.19
2023-10-30 17:12:33 <omni> that's my thinking too, since they are fewer and that will be supported for a longer time than community/
2023-10-30 17:13:03 <omni> are there like ten left in main/ that aren't already migrated or have pending MRs?
2023-10-30 17:18:35 <omni> or maybe more like ~20
2023-10-30 17:18:39 <omni> https://pkgs.alpinelinux.org/contents?file=PKG-INFO&path=&name=&branch=edge&repo=main&arch=x86_64
2023-10-30 17:40:17 <Ermine> Where upstream tarballs for kbuild come from?
2023-10-30 17:48:50 <Ermine> celie: what's the point of 'use gpep517' patches?
2023-10-30 18:19:41 <celie> Ermine: That seems to be the recommended way to package Python aports now, and omni started migrating main/ to that in preparation for Alpine 3.19. However, there are some aports that don't seem to be ready yet, so if you think one of yours is not ready then you can discuss that in the merge request.
2023-10-30 18:29:53 <minimal> celie: gpep517 doesn't work for all types of Python packages as I found out from discussing this with sam_ recently
2023-10-30 18:32:24 <tomalok> anyone know if there's anything in edge that would keep dhcpcd from working (like it does with 3.18.4)?  I'm getting a lease, but then dhcpcd exits with "eth0: adding default route via 172.30.2.1
2023-10-30 18:32:24 <tomalok> ifup: failed to change interface eth0 state to 'up'
2023-10-30 18:32:24 <tomalok> dhcpcd_fork_cb: truncated read 0 (expected 4)
2023-10-30 18:32:24 <tomalok> forked to background, child pid 1719
2023-10-30 18:32:24 <tomalok>  [ !! ]"
2023-10-30 18:34:06 <ikke> haven't noticed / heard about that
2023-10-30 18:34:47 <minimal> dhcpcd works fine for me on Edge
2023-10-30 18:37:35 <tomalok> just launched a fresh 3.18.4 aws image, and it's working okay there -- but the latest edge aws image (and one from about a week ago) isn't.
2023-10-30 18:38:21 <minimal> tomalok: when were they built? dhcpcd in Edge was last updated 8 days ago
2023-10-30 18:38:54 <celie> minimal: Ok, but it is late for me now, so i will have to pick up the discussion of this some other time, sorry. Anyway, if anyone disagrees with any of the gpep517 merge requests that i have started, just say so in Gitlab, and i will close the MR.
2023-10-30 18:40:07 <minimal> celie: from memory of what sam_ said, basically gpep317 puts everything inside the sit4e-packages directory hierarchy, which is my case doesn't work for my cloud-init package as it needs to put stuff in /etc/ etc...
2023-10-30 18:40:15 <minimal> s/317/517/
2023-10-30 18:41:14 <tomalok> minimal: edge is trying 10.0.4-r0, 3.18.4 is using 10.0.2-r1
2023-10-30 18:41:25 <minimal> celie: to quote from sam_ in a different channel: "there's no standard way for pep517 things to install outside of site-packages"
2023-10-30 19:17:24 <tomalok> minimal ikke: managed to roll back my edge instance to dhcpcd-10.0.2-r1 and now dhcpcd doesn't die.
2023-10-30 19:18:07 <minimal> tomalok: only the version of dhcpcd changes? or some other packages/config also?
2023-10-30 19:18:09 <ikke> so something between 10.0.2 and 10.0.4 broke?
2023-10-30 19:19:11 <tomalok> it would seem so.  i've been taking out some old tiny-cloud networking stuff in an attempt to fix, but that wasn't causing it apparently
2023-10-30 19:19:39 <minimal> anything "special" in your network config?
2023-10-30 19:19:59 <tomalok> nope.  just start dhcpcd (or try to)
2023-10-30 19:20:29 <minimal> hmm, not seeing an issue here (dhcpd 10.0.4 with cloud-init on Virtualbox VM)
2023-10-30 19:21:10 <tomalok> initially you get an IP but dhcpd dies and an hour later you lose your lease
2023-10-30 19:21:30 <tomalok> s/dhcpd/dhcpcd/
2023-10-30 19:21:46 <ikke> Ok, so it's not immediately
2023-10-30 19:21:52 <tomalok> "dhcpcd_fork_cb: truncated read 0 (expected 4)"
2023-10-30 19:22:00 <minimal> what's in your /etc/network/interfaces for eth0?
2023-10-30 19:22:16 <minimal> tomalok: that message appears when dhcpcd 1st runs, right?
2023-10-30 19:22:16 <tomalok> auto eth0
2023-10-30 19:22:16 <tomalok> iface eth0
2023-10-30 19:22:16 <tomalok>   use dhcp
2023-10-30 19:22:55 <tomalok> yep, message shows up on the console first (and subsequent) boots
2023-10-30 19:23:19 <tomalok> going to do anothe rreboot after rolling back to 10.0.2 and see if it still shows
2023-10-30 19:23:26 <minimal> right, I don't see that message at all
2023-10-30 19:23:57 <minimal> I'm using "classic" /etc/network/interfaces format: "iface eth0 inet dhcp"
2023-10-30 19:24:25 <tomalok> ifupdown-ng?
2023-10-30 19:24:28 <minimal> I think I *did* see some dhcpcd extra output/errors recently on 3.18.x
2023-10-30 19:24:58 <tomalok> reboot after downgrade of dhcpcd -- no more error, dhcpcd is running
2023-10-30 19:25:05 <minimal> yupe, ifupdown-ng as ifupdown is gone for Edge
2023-10-30 19:25:44 <tomalok> so ... no more ifupdown-ng?
2023-10-30 19:25:48 <minimal> 3.18 has borth ifupdown & ifupdown-ng packages, Edge only has ifupdown-ng
2023-10-30 19:26:16 <tomalok> yeah, ifupdown-ng is what's used here, explicitly
2023-10-30 19:26:27 <minimal> no, the ifupdown package is an alternative to ifupdown-ng, it's now gone in Alpine
2023-10-30 19:27:12 <tomalok> ng is there, not-ng is gone, right?
2023-10-30 19:27:18 <minimal> yes
2023-10-30 19:27:42 <tomalok> ifupdown-ng is what these images have always used, so that's still ok
2023-10-30 19:34:25 <tomalok> just to be sure this isn't somehow some kind of weird leftover from the tiny-cloud-network package, i'm stripping that outdated stuff out
2023-10-30 20:03:56 <omni> we're migrating to gpep517 from the "Please avoid running ``setup.py`` directly." deprecation warning
2023-10-30 20:08:53 <Ermine> oic
2023-10-30 20:17:51 <omni> it may not work for everything but is probably good to move to for as much as possible
2023-10-30 20:23:59 <PabloCorreaGomez[m]> Is there any chance somebody can have a look at !54014? Certainly fixes the issue the user reported, and that I had indeed been experimenting for a while
2023-10-30 20:39:51 <tomalok> minimal: checking cloud-init image -- it uses dhclient, not dhcpcd
2023-10-30 20:41:01 <minimal> tomalok: ok. upstream cloud-init recently added dhcpcd (and udhcpc) support. I was referring to my own local cloud-init image using dhcpcd
2023-10-30 20:42:21 <tomalok> then i can undo dhclient and switch to dhcpcd and see what happens for cloud-init
2023-10-30 20:44:50 <minimal> just checking, yeah cloud-init 23.3 added udhcpc support
2023-10-30 20:45:06 <minimal> hmm, checking version for dhcpcd...
2023-10-30 20:48:27 <minimal> tomalok: I'll have to dig further: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/dhcp.py#L529
2023-10-30 20:48:57 <minimal> that might apply to ephemeral dhcp (or get IP in order to reach Metadata server), I'm using dhcpcd fine with NoCloud
2023-10-30 20:49:13 <minimal> s/or get/to get/
2023-10-30 20:49:52 <tomalok> nocloud doesn't need an interface to get metadata
2023-10-30 20:50:39 <minimal> tomalok: exactly, in that scenario its being used when the network-config specifies DHCP
2023-10-30 20:51:06 <tomalok> (well, doesn't look like i can test cloud-init with dhcpcd then)
2023-10-30 20:51:21 <minimal> I'm saying I'm not sure if cloud-init Ephemeral DHCP (for Metadata Server-based conifg like AWS, Azure, etc) works with dhcpcd
2023-10-30 20:51:54 <tomalok> i have the edge image built, will find out soon, then
2023-10-30 20:53:40 <tomalok> 2023-10-30 20:53:18,894 - dhcp.py[WARNING]: DHCP client not found: dhcpcd
2023-10-30 20:54:11 <tomalok> but then it goes on...
2023-10-30 20:56:01 <tomalok> and networking init starts up
2023-10-30 20:56:19 <minimal> but did it talk to the IMDS?
2023-10-30 20:56:33 <tomalok> network says...
2023-10-30 20:56:35 <tomalok> ifup: failed to change interface eth0 state to 'up'
2023-10-30 20:56:36 <tomalok> forked to background, child pid 1729
2023-10-30 20:56:36 <tomalok> dhcpcd_fork_cb: truncated read 0 (expected 4)
2023-10-30 20:56:49 <tomalok> and then cloud-init-hotplugd starts up
2023-10-30 20:57:25 <minimal> I suspect it ended up in "fallback" mode rather than setting up AWS DataSource
2023-10-30 20:58:01 <tomalok> it's just setting up IPv6
2023-10-30 20:59:42 <tomalok> ...but since eth0 isn't actually up i can't SSH in on either v4 or v6
2023-10-30 21:00:50 <tomalok> aws EC2 console status check still says "initializing" whien it whould have already a 2/2 checks passed
2023-10-30 21:01:01 <tomalok> eventually it will probably say 1/2 checks passed
2023-10-30 21:01:29 <minimal> well as I said it seems that the dhcpcd support is missing with regarding to prepping for Metadata Server connection
2023-10-30 21:04:52 <tomalok> (i'm glad i added "rollback" to alpine-cloud-images) i'm going to build an edge image with the 3.18 dhcpcd and see how that goes
2023-10-30 21:17:32 <tomalok> a brand new edge tiny-cloud image + 3.18's dhcpcd = working just fine
2023-10-30 21:21:36 <tomalok> (well, at least for ipv4... :/)
2023-10-30 21:22:56 <tomalok> ah, probably an issue with the VPC route table
2023-10-30 21:23:58 <tomalok> yep, that fixed it.
2023-10-30 21:24:14 <tomalok> now what happened between dhcpcd 10.0.2 and 10.0.4?
2023-10-30 22:05:33 <minimal> tomalok: have you tried tiny-cloud NoCloud with dhcpcd to see if the problem also occurs there? I'm assuming tc NoCloud handles networking differently than tc AWS
2023-10-30 22:15:14 <tomalok> minimal: unfortunately i lack the setup (or time to create that setup) to test that scenario...  it's possible that maybe dhcpcd doesn't like AWS's dhcpcd, but the error message i'm seeing seems to be related to forking, and not anything it received from the server. (#15417)
2023-10-30 22:16:24 <tomalok> i'm happy to create an edge nocloud image for someone to test with, though.
2023-10-30 22:26:13 <tomalok> https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/edge/cloud/nocloud/aarch64/alpine-20231030-aarch64-uefi-tiny-r0.qcow2 and https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/edge/cloud/nocloud/x86_64/alpine-20231030-x86_64-uefi-tiny-r0.qcow2 are available for nocloud testing of this issue (both have dhcpcd 10.0.4)
2023-10-31 11:43:53 <lennartp> Hey. I see that jirutka took libguestfs and put it back into testing, which is great
2023-10-31 11:44:23 <lennartp> but now it builds without libvirt, which means guestfs-tools don't have virt-make-fs
2023-10-31 11:45:09 <lennartp> I know libguestfs is a piece of work, but I could really use virt-make-fs or something similar. Does anyone know of any usable alternative?
2023-10-31 11:45:37 <lennartp> (I can script what virt-make-fs does, but it requires root privileges, to open a loop device)
2023-10-31 12:33:39 <omni> I knew skarnet was just your alter ego
2023-10-31 12:34:40 <lennartp> muhahahaha
2023-10-31 15:25:10 <omni> so, s6-storage™ when?
2023-10-31 15:25:42 <minimal> twice as good as s3 storage? ;-)
2023-10-31 16:15:32 <lennartp> the whole "make filesystems on a virtual image from the outside" space is a clown fiesta
2023-10-31 16:15:48 <lennartp> I gave up and went back to my scripts that require being root
2023-10-31 16:17:07 <ikke> yeah, that somehow remains a pain to achieve without root
2023-10-31 16:18:10 <minimal> especially if you want to do stuff like LVM/LUKS for the VM images
2023-10-31 16:24:01 <ikke> Anyone an idea how to make a dependency optional / dynamic in a makefile target? Goal is to be able to toggle building test objects based on a flag
2023-10-31 16:26:06 <ikke> define a variable and use $(var) in the target?
2023-10-31 16:26:28 <lennartp> yes, use a variable as a prerequisite
2023-10-31 16:29:31 <omni> I'm.. sceptic to 'npm run build' in aports.. shouldn't be needed, right?
2023-10-31 16:51:35 <ikke> lennartp: thanks, managed it
2023-10-31 16:52:36 <tomalok> re: dhcpcd 10.0.4 issues -- i've determined that 10.0.3 worked just fine... so that narrows down the commits a bit
2023-10-31 16:53:30 <tomalok> https://github.com/NetworkConfiguration/dhcpcd/compare/v10.0.3...v10.0.4
2023-10-31 17:01:19 <ikke> maybe https://github.com/NetworkConfiguration/dhcpcd/commit/ac4a70dc89ffd545e7a8c8c07711497376ac85f5 ?
2023-10-31 17:02:55 <tomalok> i just rebuilt 10.0.4 without privsep and it's forking fine
2023-10-31 17:08:18 <ikke> tomalok: so that's the issue?
2023-10-31 17:12:26 <tomalok> something that changed in privsep is likely the culprit
2023-10-31 17:13:10 <tomalok> ps_daemonized() is brand new
2023-10-31 17:15:43 <ikke> yeah, noticed it
2023-10-31 17:16:11 <tomalok> but it could be a side effect of some of the other changes...
2023-10-31 17:16:32 <tomalok> alas, i need to set this aside for today, gotta get ready to drive into the mountains for the next couple days
2023-10-31 19:12:25 <hjaekel> Does anyone have time to review a new aport? !53080 has been waiting for some time.
2023-10-31 19:21:18 <omni> hjaekel: you had a quastion wrt armhf that I cannot answer but you've disabled builds for that arch so let's get it in
2023-10-31 19:22:39 <hjaekel> yes, I could not solve the build issue with armhf, so I disabled that arch.
2023-10-31 19:26:00 <hjaekel> Thank you omni. Now I can view my X-ray images in Alpine Linux. 
2023-10-31 21:36:04 <omni> cool
2023-10-31 21:36:14 <omni> hope you're well
2023-10-31 21:37:05 <omni> dev/null, not that's an interesting tag https://github.com/google/brotli/tags
2023-10-31 21:37:34 <ikke> Lol
2023-10-31 21:39:57 <omni> s,not,now,
2023-10-31 23:35:31 <omni> is there any way so that the rebuilt qt6-qttools could be available for the qt6-qtwebengine build on the aarch64 builder?
2023-10-31 23:35:51 <omni> not sure if this would help or if there is something else going on