2021-05-01 11:11:51 so what needs to be done to make it happen 2021-05-01 13:24:55 i guess dispatch service needs to be deployed and some bot account needs to be set up on gitlab to handle things 2021-05-01 13:25:32 I have already set up dispatch.a.o 2021-05-01 13:25:58 https://paste.sr.ht/~sircmpwn/16d4cfa18614a75f762771a701c8544c8c7c9f7e 2021-05-01 13:26:00 wrote this a while ago 2021-05-01 13:27:46 i meant the DNS record for it 2021-05-01 13:28:01 dispatch.a.o seems to not have a DNS 2021-05-01 13:28:10 right, I was referring to the software deployment 2021-05-01 13:29:05 on that front, dunno :) 2021-05-01 13:56:23 mcrute: are you talking about repos? because group membership is now managed in terraform :) 2021-05-01 14:17:04 Ariadne: fyi, groups hosts both teams and repos, in gitlab, there is no distinction, but we separate those out 2021-05-01 15:06:08 ddevault: how does the bot work? is it possible to have the bot work in its own repo? 2021-05-01 15:06:53 not without some significant changes to how it works 2021-05-01 15:07:38 i think making it work in its own repo, like other bots that interact with aports would if they were doing git changes, would help move things forward 2021-05-01 15:08:00 it's designed to be operated from a position of trust, which simplifies the design substantially 2021-05-01 15:08:13 dispatch.a.o is on alpine infrastructure 2021-05-01 15:10:37 the concern is not whether dispatch.a.o is trusted, but whether an abuser could trick the bot into doing something it isn't supposed to do. the current systems we have in place for ensuring unauthorized pushes don't happen are a little bit fragile. 2021-05-01 15:11:14 would a group code review help to reassure these concerns? 2021-05-01 15:11:19 (improving that is on the list of things to figure out, of course) 2021-05-01 15:11:36 it *can* be done with a dedicated user who is not given permission to commit to aports master 2021-05-01 15:11:45 In my opinion, seperation of concerns is good security practice 2021-05-01 15:11:53 priciple of least privilege 2021-05-01 15:12:13 I agree, but it makes an already complex integration a lot more so 2021-05-01 15:12:18 Why? 2021-05-01 15:12:21 yes, from security team POV we would prefer to see separation of privilege here 2021-05-01 15:12:27 Isn't it a single field to specify the target repo? 2021-05-01 15:12:34 for the MR 2021-05-01 15:12:40 or is there more involved? 2021-05-01 15:12:55 well, we could set up an entirely separate aports repo on gitlab for funneling ML MRs into, if that's what you mean 2021-05-01 15:13:04 which is periodically pulled into the main repo 2021-05-01 15:13:07 yes, that is what i was asking :) 2021-05-01 15:13:08 but that seems... less than ideal 2021-05-01 15:13:31 if nothing else all of the reviewers would have to subscribe to notifications for a second repository 2021-05-01 15:13:31 it doesn't seem like a big step to go from that to having the bot make MRs directly against the main aports repo 2021-05-01 15:13:56 but admittedly i am not familiar with gitlab APIs :) 2021-05-01 15:14:02 why not just use gitlab ACLs here? 2021-05-01 15:14:11 we can set up a user to handle the mirroring which is not allowed to push to master, easy enough 2021-05-01 15:14:12 ddevault: the MR would still appear in the main repo 2021-05-01 15:14:42 okay, that's what I initially thought you were asking for 2021-05-01 15:15:03 I'm not saying no. But I am asking why the existing gitlab ACLs are not good enough 2021-05-01 15:15:32 we don't use strictly gitlab ACLs for this 2021-05-01 15:15:43 there are custom git hooks too 2021-05-01 15:15:47 AND the ACLs don't allow you to specify per user what they can push to 2021-05-01 15:15:53 yep :) 2021-05-01 15:16:06 right, but it should still be good enough 2021-05-01 15:16:22 basically, what would be ideal is if there was a separate repo that collected the patches, and then the bot opened the MRs in the main repo 2021-05-01 15:16:30 so you have say 2021-05-01 15:16:31 yes, I understand what you're asking for 2021-05-01 15:16:37 okay :) 2021-05-01 15:16:42 I'm asking for a bit of compromise 2021-05-01 15:16:46 to make the software simpler 2021-05-01 15:17:43 not speaking with security hat on, wouldn't this also put a bunch of refs in the main aports repo? 2021-05-01 15:17:58 keep in mind also that dispatch.sr.ht (the software) serves a broader audience than dispatch.a.o and I'm pretty opposed to maintaining alpine-specific patches for it 2021-05-01 15:18:08 yeah, it will 2021-05-01 15:18:18 I'll add a gc thing before it becomes a problem 2021-05-01 15:18:42 note that gitlab already adds a ref for every MR, so it won't increase the refs added any greater than what we'd already have seen if these patches were normal MRs 2021-05-01 15:19:02 correction: they already get GC'd 2021-05-01 15:19:08 they're deleted when the mr is closed 2021-05-01 15:19:32 well my concern is more about what happens if somebody git pulls aports and sees all these refs and gets confused :) 2021-05-01 15:19:58 seems like a somewhat shallow concern to be honest 2021-05-01 15:20:10 the branches have fairly obvious names, fwiw, "mailed-patch-${id}" 2021-05-01 15:20:17 as long as they are not in refs/heads, they are not pulled by default 2021-05-01 15:20:27 ok 2021-05-01 15:21:29 But we cannot say: developers can push to *-stable / master, and this bot user can only push to refs/mailing/* (or whatever it will be called) 2021-05-01 15:21:58 git by default does not allow you to push to refs/$arbitrary_string/* 2021-05-01 15:22:30 ikke: so I think there's a case to be made that the cloud team needs to be able to push to main 2021-05-01 15:23:05 our current ec2 support package is in main and I'm working to split out and package the cloud-specific bits that we've just kinda rolled into the ami with scripts 2021-05-01 15:23:18 I think those also belong in main because they'll be critical to booting cloud images on various providers 2021-05-01 15:23:31 ddevault: git ls-remote https://gitlab.alpinelinux.org/kdaudt/aports.git refs/test/this/does/work 2021-05-01 15:23:54 hm, yes, it does 2021-05-01 15:23:54 git does not restrict the refs namespace at all 2021-05-01 15:24:13 mcrute: there is a case but it would be easier for us to wait until that is migrated to terraform :) 2021-05-01 15:24:21 it would require some testing, but I can look into using refs/mail/* 2021-05-01 15:24:26 would that be acceptable? 2021-05-01 15:24:44 That would address the refs namespace polution, but not the security concern 2021-05-01 15:25:11 tests which prove it can only push to refs/mail/* would help with addressing the security concern i think 2021-05-01 15:25:15 and we need to test if gitlab supports creating merge requests from that 2021-05-01 15:26:02 we will need to adjust some of our scripts to resolve the rest of the security concern, but they need to be adjusted anyway as part of the terraform migration :) 2021-05-01 15:27:03 Ariadne: okay, I definitely need to do some backporting today of tiny-ec2-bootstrap and was planning to work the support package for ec2 through testing this weekend 2021-05-01 15:27:12 mcrute: sure, lets work on it 2021-05-01 15:27:18 maybe we should make an #alpine-cloud 2021-05-01 15:27:20 it seems like a lot of mindless cherry-picking, is there anything that can be done in the short term to not make you have to deal with all that? 2021-05-01 15:27:54 Ariadne: I am there :-) 2021-05-01 15:28:32 mcrute: yes, if you can publish aports trees with all of the needed changes, i can do all of it in one go :) 2021-05-01 15:29:17 Ariadne: okay, that would make it less drugery :-D I can do that 2021-05-01 15:30:20 recommended plan: assuming testing demonstrates it to work as expected, we move patch MRs into refs/mail/* on the upstream aports repository, with a dedicated gitlab user. I'm also open to doing a group cdoe review on the dispatch.a.o bits if that would be helpful. Whatever hooks you've got going on would then be updated to exclude the mail namespace 2021-05-01 15:30:22 is this agreeable? 2021-05-01 15:30:33 code review* 2021-05-01 15:32:20 We can't have those patches in a separate fork? 2021-05-01 15:32:39 I would prefer not to 2021-05-01 15:34:21 Having all those mail branches in Gitlab would mean every Gitlab contributor would fetch then too via git fetch --all and makes it a lot harder to use the branch picker tool in the Gitlab webUI 2021-05-01 15:34:38 So IMHO if at all possible, we should use a fork to keep the upstream repo tidy 2021-05-01 15:34:47 Cogitri: it is theorized that the refs/ namespace is hidden in gitlab 2021-05-01 15:34:58 refs/ 2021-05-01 15:35:08 The default fetch refspec is refs/heads/* 2021-05-01 15:35:26 and for the branch list, it also looks at refs/heads 2021-05-01 15:35:47 from security POV, we want to talk about the proposal a little bit more internally, but we don't wish to apply "stop energy" to it either 2021-05-01 15:36:03 Oh okay, if it's not fetched&hidden in Gitlab please disregard my point :) 2021-05-01 15:36:17 i think the larger question is whether the infra team is okay with the proposal 2021-05-01 15:36:25 I can be patient 2021-05-01 15:36:39 the team agreed not to stop reviewing aports patches from the mailing list until a system like this was put into place 2021-05-01 15:36:48 I'm ok with having a service that creates MRs from mailing list patches 2021-05-01 15:36:48 I bring it up again now because someone asked me to set it up for alpine 2021-05-01 15:37:11 The concern about the refs namespace is being addressed 2021-05-01 15:37:23 so I only have a concern regarding security 2021-05-01 15:37:40 But, I guess extending the git hook we use, can alleviate that 2021-05-01 15:37:43 I think an acceptable level of security can be reached without a fork 2021-05-01 15:38:26 ikke: yep, i just think it makes sense to incorporate this into the rework plans we are already doing :) 2021-05-01 15:38:32 yes 2021-05-01 15:39:49 if you can complete the first step in the paste I linked earlier (DNS and reverse proxy) 2021-05-01 15:39:54 i think from top-level view it is easy to solve 2021-05-01 15:40:01 it would unblock the necessary work to test the refs/mail/* idea 2021-05-01 15:40:20 which can be done in parallel with whatever you need to do privately 2021-05-01 15:41:35 privately it is talking about the git hooks 2021-05-01 15:42:09 Ariadne: missed your q before about cloud subgroups... I mean something like the infra folder so we can stash our repos not at the root of the alpine project 2021-05-01 15:42:10 we are in the process of redesigning them as part of the implementation of terraform 2021-05-01 15:42:29 I know we already have a group for people and security purposes, this is purely organizational for repos 2021-05-01 15:42:30 yes, we should make one for the security team too 2021-05-01 15:42:57 ddevault: what do you mean with a root proxy? 2021-05-01 15:42:58 one of the GitLab "owners" has to create at afaict 2021-05-01 15:43:52 I don't recall what I meant by a "root" proxy 2021-05-01 15:44:02 i think he said reverse proxy 2021-05-01 15:44:05 not root 2021-05-01 15:44:10 yes, the paste mentions root proxy 2021-05-01 15:44:11 but basically a DNS record, SSL cert, and proxy for dispatch.a.o needs to be set up similarly to lists.a.o is now 2021-05-01 15:44:32 That's why I asked 2021-05-01 15:48:10 ddevault: Would a project access token suffice? (it automatically creates a user associated with it) 2021-05-01 15:51:29 I don't know what a project access token is, ikke 2021-05-01 15:51:46 oauth token 2021-05-01 15:51:51 i believe 2021-05-01 15:51:56 https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html 2021-05-01 15:52:04 suffice for what? 2021-05-01 15:52:14 oh, I see 2021-05-01 15:52:20 I don't know, this would require re-testing the entire system 2021-05-01 15:52:47 It allows API and push access to that specific project 2021-05-01 15:53:08 using a user account has less unknowns. Why prefer this? 2021-05-01 15:53:19 principle of least privilege 2021-05-01 15:53:39 user accounts created in this way cannot be logged into :) 2021-05-01 15:53:39 what privilege does a user have that this approach takes away? 2021-05-01 15:53:54 well 2021-05-01 15:54:12 it might work, but it creates a lot of work for me at a minimum, and would likely require large scale overhaul to address usability for general use 2021-05-01 15:54:16 I don't like this idea 2021-05-01 15:54:42 How are you currently pushing these refs? 2021-05-01 15:54:54 the other bots we have are working in the same way 2021-05-01 15:54:58 shelling out to git using HTTP basic auth with the user's oauth token as the password 2021-05-01 15:55:13 ddevault: afaik it should work the same 2021-05-01 15:55:13 that should work with a project-access-token 2021-05-01 15:55:16 yes 2021-05-01 15:55:20 but only for the git push 2021-05-01 15:55:24 how would it work with the MR? 2021-05-01 15:55:30 the project access token is just an oauth token that is pre-shared 2021-05-01 15:55:30 you use the API, right? 2021-05-01 15:55:37 who owns the MR? 2021-05-01 15:55:41 the bot does 2021-05-01 15:55:48 and how do we obtain the token? right now we use the normal OAuth flow, pasting in a token requires a new UI and is error prone and less usable 2021-05-01 15:56:35 as I said: it might work, but creates a lot of work for me 2021-05-01 15:57:06 ikke: do you know if gitlab burns pre-existing tokens on password change? 2021-05-01 15:57:30 No, I don't know 2021-05-01 15:57:36 maybe we can create an account, and then delete the password somehow after the token is set up 2021-05-01 15:58:38 the goal here is to ensure that there aren't credentials laying around that can leak 2021-05-01 15:58:50 set it to a random password and don't write it down? 2021-05-01 15:58:52 which is why we use project access tokens for the other bots 2021-05-01 15:59:05 i guess we could do that 2021-05-01 15:59:24 2 minutes of work vs several hours 2021-05-01 15:59:44 yeah, i get your point :) 2021-05-01 16:01:30 so basically 2021-05-01 16:01:34 what we would do 2021-05-01 16:01:49 is create a user, and then at that moment, just go into dispatch.a.o and set up the association 2021-05-01 16:02:02 probably use uuidgen or something for the password 2021-05-01 16:02:17 Yeah, I can create secure random passowrds 2021-05-01 16:03:02 alright, i think we can make that work, although it is not completely ideal 2021-05-01 16:03:52 we will figure out the githooks issue and circle back to this 2021-05-01 16:03:55 :) 2021-05-01 16:04:11 thanks, let me know 2021-05-01 16:04:22 on a timeframe, this is not likely to happen until after 3.14 release, so please don't feel the need to rush anything 2021-05-01 16:04:37 it was delayed until after the 3.13 release, too :) 2021-05-01 16:04:54 we will always have an impending release 2021-05-01 16:04:59 yes 2021-05-01 16:05:13 definitely *do* ping after 3.14 release if you don't hear back by say, end of the month 2021-05-01 16:07:08 but we will likely be having a discussion about the githooks within a few weeks. right now we're working some more urgent issues, but it is coming for sure 2021-05-01 16:07:10 can we decide on a specific schedule, rather than a vague one 2021-05-01 16:07:16 any timeline so long as it's a specific timeline 2021-05-01 16:07:26 sure. when would you like an answer by? 2021-05-01 16:07:36 well, I'm not blocked by anything, you are 2021-05-01 16:07:40 so when can you have an answer by? 2021-05-01 16:10:07 next week we plan to focus on some last remaining governance items, and determining what relationship, if any, Alpine will have with the secret distros list 2021-05-01 16:10:21 we can discuss githooks the week afterward 2021-05-01 16:10:26 so, lets say May 14 2021-05-01 16:10:52 that's around alpineconf, right? 2021-05-01 16:10:56 right before 2021-05-01 16:11:07 but this is just the security side of the discussion 2021-05-01 16:11:48 okay, may 14th 2021-05-01 16:11:50 thanks 2021-05-01 16:12:00 err, no, I'm travelling then 2021-05-01 16:12:11 how about may 17th 2021-05-01 16:13:10 sure, that works :) 2021-05-01 16:14:14 alright, I'll make a note 2021-05-01 16:14:16 thanks 2021-05-01 16:14:50 though we will likely have preliminary discussions about the githooks the week of may 14th, as the way we've been doing things is to focus on specific goals in weekly sprints 2021-05-01 16:15:52 fwiw i don't think there will be a "negative" answer in terms of moving forward as a result of the githooks rework discussion. quite the opposite in fact :) 2021-05-01 16:16:32 that's fine, I just don't want the can to keep being kicked ahead 2021-05-01 16:16:45 agreed 2021-05-01 16:21:28 Ariadne: mind if I tag in on the githooks conversation? I have an interest in it as well 2021-05-01 16:21:51 mcrute: sure, the discussions are public :) 2021-05-01 16:22:13 awesome! they just happen in the channel here? 2021-05-01 16:22:28 well the security team is in -security, but yes 2021-05-01 16:22:29 fyi: the githook itself is rather simple, but managed manually 2021-05-01 16:23:50 we will probably have the githooks conversation mostly here :P 2021-05-01 16:24:01 yes, makes sense 2021-05-02 15:42:12 ikke: do you have any objections to https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/merge_requests/3 ? 2021-05-02 15:43:40 personally, I don't have an issue with that, but I'd like the confirm it with ncopa 2021-05-02 15:45:05 sounds good, thanks. I'll ping him Monday as well 2021-05-02 15:46:06 Nice you found that repo :)_ 2021-05-02 15:46:39 do you know if there's some permission issue with the TF credentials that are causing the plan test to fail? 2021-05-02 15:46:47 I try to be self service :-) 2021-05-02 15:47:34 yes, it does not work for forks 2021-05-02 15:47:48 Still thinking about how to arrange it properly without compromising the access keys 2021-05-02 15:48:01 I have some ideas, but still need to think it through 2021-05-02 15:49:47 ah I see... maybe if there were some way the builder itself had the credentials independent of the project, seems like GitLab should have some setting for that *shrug* 2021-05-02 15:50:17 Yes, that's part of the solution 2021-05-02 15:50:26 The other halve is locking down what the pipeline can execute 2021-05-02 15:51:50 I'm interested how you eventually solve this, the cloud builder will have similar issues I think 2021-05-02 15:52:38 You can lock down a specific builder to only allow a single image 2021-05-02 15:52:57 You can also disable overriding the entrypoint 2021-05-02 15:55:03 oh, that's a bit more straightforward in this case, you won't have people possibly modifying the code that does that orchestration 2021-05-02 15:55:23 like the cloud builder/publisher code itself 2021-05-02 15:56:58 hey, could you give me permissions to create subgroups (of repos)/repos within the Alpine GitLab organization? 2021-05-02 15:58:59 I can make a cloud subgroup under the alpine group 2021-05-02 15:59:08 You can create repos there, but I need to make them public 2021-05-02 15:59:22 that'll work 2021-05-02 15:59:45 I don't think I need to keep anything private... secrets are in vault on my side :-) 2021-05-02 16:01:55 I also want to integrate hashicorp vault 2021-05-02 16:02:50 gitlab is a jwt auth provider, which vault supports 2021-05-02 16:03:47 vault is really great, we use it a ton internally for secrets and certificate management... haven't tried the JWT provider yet 2021-05-02 16:04:15 Yes, I've used it as well 2021-05-02 19:39:19 Cogitri: I've tested that you can get pipeline / job status info from forks with a project access token 2021-05-02 19:39:25 curl -sH "PRIVATE-TOKEN: $aports_access_token" -H "Content-Type: application/json" https://gitlab.alpinelinux.org/api/v4/projects/mdekstrand%2Faports/pipelines/80739/jobs 2021-05-02 19:39:36 Will test if you can also cancel jobs 2021-05-02 19:48:42 Ah neat πŸ‘οΈ 2021-05-02 19:50:14 Hmm, need to test it on someone who does not have push access, otherwise the pipeline gets created in the alpine/aports repo 2021-05-02 19:51:46 Oh, it does? 2021-05-02 19:53:10 yes 2021-05-02 19:54:00 :( 2021-05-02 19:54:02 403 2021-05-02 19:55:04 so you cannot cancel it :-/ 2021-05-02 19:55:38 That's unfortunate :/ 2021-05-02 19:57:05 But that probably explains the error you've been seeing with the pipeline canceller though, currently that just always assumes that the pipelines are run on the fork and never on aports 2021-05-02 19:58:42 I was already wondering how you would deal with that :) 2021-05-02 22:54:36 ikke: are you around? could you make the cloud gitlab sub-group public? it's currently marked private and I can only make it private or internal but not public 2021-05-02 22:54:53 it's not super urgent, I plan to start migrating public repos over there within the next few weeks at the earliest 2021-05-03 04:33:09 I thought I had it set to public. Anyway, it's public now 2021-05-03 05:50:58 thanks 2021-05-03 05:54:13 it's werid, I still can't select public for the repos in cloud... only private or internal 2021-05-03 05:54:21 GitLab permissions continue to vex me 2021-05-03 05:54:56 I can see that public is an option but it's grayed out and I can not select it, when looking at the subgroup I can only see private or internal, not public 2021-05-03 06:33:17 Yes, that's what I mentioned earlier 2021-05-03 06:33:30 Just create te projects, I'll make them public 2021-05-03 06:33:59 We disabled that to prevent people using our gitlab instance as a generic git forge 2021-05-03 06:34:42 sigh... okay thats frustrating 2021-05-03 06:35:21 given all these permission issues I might just stick to GitHub, GitLab is a pretty hostile 2021-05-03 06:36:09 can you just give me the access I need to deal with the cloud project? I promise I won't use GitLab as a generic forge, I have plenty of other places to store my code :-) 2021-05-03 06:40:15 This is a system wide setting, and I can't make you gitlab admin 2021-05-03 06:40:28 I'm not worry about you using it 2021-05-03 06:40:33 That way 2021-05-03 06:41:03 okay, I'm just becoming frustrated I had all weekend to do something useful and instead I wasted a huge amount of it dealing with these permissions issues 2021-05-03 06:41:54 but it's midnight PST so I'm going to go to bed now... I'll re-visit this later next week I guess 2021-05-03 06:43:07 Sorry about that, then 2021-05-03 14:04:40 Ariadne: any news about the mips64 builder? 2021-05-03 15:18:44 ncopa: wdyt re: https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/merge_requests/3 2021-05-03 15:18:52 I'd like your input before I merge that 2021-05-03 15:20:07 also I spun up a #alpine-cloud room for our cloud work... will op the normal people if anyone wants to join... it'll probably be a pretty quiet room 2021-05-03 15:35:14 ikke: what do you think? about that MR? ^^^ 2021-05-03 15:36:11 Technically it looks ok. mcrute do you manage ns1.as398223.net? 2021-05-03 15:37:01 ikke: yeah as398223.net (and that whole AS) is owned by my consuling company 2021-05-03 15:37:13 ok 2021-05-03 15:39:33 i think the approach is ok. will probably be better for you to initially run it on your own infra so alpine infra does not slow you down 2021-05-03 15:42:06 thanks, that works for me... I have all the alpine stuff running on a dedicated VM on my side so it should be easy to merge if we ever want to do that 2021-05-03 15:42:38 the marginal cost to host it is basically zero for me so I feel no rush to merge though 2021-05-03 15:46:43 ncopa: should be coming up tomorrow i think. 2021-05-03 15:49:44 mcrute: good! thanks! 2021-05-03 15:49:58 fyi, it has been merged, and applied 2021-05-03 15:50:01 Ariadne: great 2021-05-03 15:50:19 anyone heard anything about the ppc64le machine? 2021-05-03 15:50:26 nope :( 2021-05-03 15:50:49 I'd like to tag an edge snapshot as soon they are up again and havae catched up on the builds 2021-05-03 16:00:05 thanks ikke 2021-05-04 17:08:03 Ariadne: We have less then 2 weeks for the conference, I guess we should start making preparations 2021-05-04 17:08:18 indeed 2021-05-04 17:10:36 how are you planning to host it? 2021-05-04 17:12:15 Ariadne was trying to contact people she knows from ccc 2021-05-04 17:12:33 yes, i should get around to doing that :p 2021-05-04 17:12:46 ccc? 2021-05-04 17:13:13 clandmeter: the chaos computing congress, you may have heard of it hopefully 2021-05-04 17:13:36 before the plague, they used to have big huge meeting in berlin several times a year :p 2021-05-04 17:13:36 https://en.wikipedia.org/wiki/Chaos_Computer_Club 2021-05-04 17:13:37 [WIKIPEDIA] Chaos Computer Club | "The Chaos Computer Club (CCC) is Europe's largest association of hackers with 7700 registered members. Founded in 1981, the association is incorporated as an eingetragener Verein in Germany, with local chapters (called Erfa-Kreise) in various cities in Germany and the surrounding countries, particularly..." 2021-05-04 17:14:00 sorry. i didnt know about it, maybe heard about it but didnt stick. 2021-05-04 17:14:22 Mostly known for the yearly conferences 2021-05-04 17:14:42 and you are going to use something like jitsi? 2021-05-04 17:15:00 Ariadne mentioned bigbluebutton 2021-05-04 17:15:22 yes, but the CCC uses some other system 2021-05-04 17:15:23 that does ring a bell 2021-05-04 17:15:25 i'm not sure :) 2021-05-04 17:17:55 And I guess we want to do at least a partial rehearsal? 2021-05-04 17:28:08 ikke: are you going to present something? 2021-05-04 17:28:17 no 2021-05-05 07:34:07 if there's anything i can help with, i will 2021-05-05 07:34:16 sorry for being a bit quiet, been on guard duty for a week, and it's been terribly busy 2021-05-05 08:46:32 I agree that we should have some sort of rehersal, to test if things works as expected 2021-05-05 08:46:46 Ariadne: do you have an estimate on how many attendees? 2021-05-05 15:15:40 no idea :) 2021-05-05 16:13:46 is there any update from IBM/Unicamp on the ppc64le builder 2021-05-05 16:20:42 nope 2021-05-05 16:20:43 nothing 2021-05-05 17:42:17 okay 2021-05-06 13:23:06 hi guys, has the day for alpineconf already been set? 2021-05-06 13:30:21 Yes 2021-05-06 13:30:46 fcolista: 15th and 16th of May 2021-05-06 13:38:55 build-edge-mips64 is back! \o/ 2021-05-06 13:47:35 Nice 2021-05-06 13:47:49 Now ppc64le 2021-05-06 13:54:11 thx ikke ! 2021-05-06 16:28:35 ncopa: nice, what happened to it? 2021-05-06 16:30:47 danieli: it's kind of a contraption atm 2021-05-06 16:30:57 so network is instable 2021-05-06 16:31:07 courtesy of Ariadne? :) 2021-05-06 16:31:32 courtesy of the startup i worked for last year 2021-05-06 16:31:38 i see 2021-05-06 16:31:51 there is a second board, i am trying to get it shipped to me so i can put it in my colo 2021-05-06 16:32:06 the current board is on fixed point LTE connection behind CGNAT 2021-05-06 16:32:13 and sometimes gets unplugged 2021-05-06 16:32:22 ouch, that sounds painful for something that will have to download and upload a fairly large amount of data 2021-05-06 16:32:32 CGN is evil 2021-05-06 16:32:42 the fixed point LTE is fast enough 2021-05-06 16:32:50 300 down, 150 up 2021-05-06 17:08:05 Anyone got a clue why I can't seem to get any output from a qemu vm I'm running on aarch64? I've tried different things, but not a lot seems to be happening. qemu invocation: qemu-system-aarch64 -machine virt,accel=kvm,gic-version=3 -cpu host -smp 32 -name gitlab-runner-aarch64 - 2021-05-06 17:08:08 enable-kvm -m 32G -vga virtio -cdrom /var/lib/iso/alpine-virt-3.13.5-aarch64.iso -drive format=raw,file=/dev/mapper/vg0- 2021-05-06 17:08:29 qemu-system-aarch64 -machine virt,accel=kvm,gic-version=3 -cpu host -smp 32 -name gitlab-runner-aarch64 - 2021-05-06 17:08:31 enable-kvm -m 32G -vga virtio -cdrom /var/lib/iso/alpine-virt-3.13.5-aarch64.iso -drive format=raw,file=/dev/mapper/vg0- 2021-05-06 17:08:38 https://tpaste.us/K5YB 2021-05-06 17:08:46 sorry, wanted to paste that link 2021-05-06 17:09:31 I tried -spice, -nographic, -serial stdio, -serial pty 2021-05-06 17:10:07 With spice (and connecting to the spice port), I see it's connected, but no view at all 2021-05-06 17:10:42 (this is over ssh) 2021-05-06 17:40:04 I try with -display curses, but I just get a cursor, nothing else 2021-05-06 17:40:37 seems to be qemu monitor 2021-05-06 17:41:12 ohh... 2021-05-06 17:41:39 I've added a bios, and now it works with -serial pty 2021-05-06 17:54:15 Now just networking :( 2021-05-07 06:28:40 FYI, got it to work eventually 2021-05-07 06:30:47 ikke: what are you trying to get? 2021-05-07 06:32:05 -nographic is usually enough to get 'serial' console 2021-05-07 06:32:28 -serial pty 2021-05-07 06:33:33 never added '-serial pty' and always have serial console with just -nographic 2021-05-07 06:33:33 It was the lack of a bios that prevented it to boot 2021-05-07 06:33:46 aha 2021-05-07 06:34:01 Yeah, that would probably suffice 2021-05-07 06:34:03 understand now 2021-05-07 06:34:41 -nographic is enough if run from terminal 2021-05-07 06:35:08 could be that you have more 'complicated' setup 2021-05-07 06:57:25 nographic should be fine 2021-05-07 06:57:56 but you tend to add stuff when shit doesnt work :) 2021-05-07 07:16:33 Ahuh 2021-05-07 10:46:59 is aarch64 CI is busy or stuck 2021-05-07 10:48:23 busy 2021-05-07 15:36:42 clandmeter: Do I need to do something special to be able to run 32 bits programs on aarch64? 2021-05-07 15:46:40 should not 2021-05-07 15:46:44 if the cpu supports it 2021-05-07 15:47:19 are you running into issues? 2021-05-07 15:55:50 standard_init_linux.go:219: exec user process caused: exec format error 2021-05-07 15:59:07 hmm that doesnt sound good 2021-05-07 16:04:38 ikke: does kernel have enable CONFIG_COMPAT=y 2021-05-07 16:06:11 and maybe KUSER_HELPERS=y 2021-05-07 16:09:06 i would guess its the same kernel as we used before 2021-05-07 16:11:13 ikke: ah you are running it in qemu? 2021-05-07 16:11:38 i just tried the host with busybox static and works just fine 2021-05-07 16:12:54 clandmeter: yes, in qemu 2021-05-07 16:13:42 im looking at the cmdline 2021-05-07 16:14:19 the old runners were also on aarch64 right? 2021-05-07 16:14:42 clandmeter: yes 2021-05-07 16:15:43 cpu = host 2021-05-07 16:15:46 which should be good 2021-05-07 16:16:10 do other programs behave the same? 2021-05-07 16:20:59 ikke: my key is not on the runner? 2021-05-07 16:22:01 I did add your key 2021-05-07 16:22:11 but you ed25519 one, not the rsa 2021-05-07 16:23:27 mps: yes, CONFIG_COMPAT is set 2021-05-07 16:24:56 clandmeter: maybe because I use the virt kernel instead of lts? 2021-05-07 16:30:25 Ok, yes, that fixed it 2021-05-07 16:33:30 ikke: and CONFIG_COMPAT is not set in -virt kernel 2021-05-07 16:33:44 mps: yea, I accidentally looked at the old VM :) 2021-05-07 16:33:50 same hostname :D 2021-05-07 16:34:36 mps: thanks 2021-05-07 16:38:00 you are welcome 2021-05-07 16:52:19 ncopa: clandmeter anything on usa1 / usa4 that we need to keep? 2021-05-07 16:52:26 / still migrate 2021-05-07 17:02:18 btw, linux-edge-virt have these two options enabled, can be added to lts -virt also 2021-05-07 17:38:34 mps: I do need -serial pty, otherwise no pts device is created 2021-05-07 17:40:26 hmm, interesting. and you use -nographic? 2021-05-07 17:40:43 yes 2021-05-07 17:41:04 you intrigued me, will check again later 2021-05-07 17:41:04 Maybe it's creatd, but I canot find it 2021-05-07 17:42:15 mps: note that the vm runs in the background 2021-05-07 17:42:41 what you mean by 'backgroud' 2021-05-07 17:42:51 it's run as a service 2021-05-07 17:43:01 aha 2021-05-07 17:43:37 for long running I use screen in detached mode to start VM 2021-05-07 17:46:58 but, do any program in VM 'creates' pts nodes 2021-05-07 17:47:13 with -serial pty, one gets created 2021-05-07 17:47:19 you can then use screen to attach to it 2021-05-07 17:50:19 interesting, maybe I didn't noticed that because never (iirc) started them without screen or from terminal 2021-05-08 07:02:29 ikke: goede morgen 2021-05-08 07:04:18 I tested last night qemu armv7 guest on x86_64 host without -serial pty and run it with screen, I got /dev/ptmx and /dev/pts dir 2021-05-08 07:05:25 screen is 'connected' (its tty dev) to /dev/ttyAMA0 2021-05-08 07:06:27 btw, linux-virt armv7 is broken, had to use linux-edge-virt. 2021-05-08 07:06:31 ncopa: ^ 2021-05-08 07:06:59 mps: are you looking inside the vm? 2021-05-08 07:07:05 I'm talking about the host side 2021-05-08 07:07:31 mps: what do you use as image and bios for armv7? 2021-05-08 07:09:28 ikke: yes, in VM. I thought that is your issue with pts 2021-05-08 07:09:50 aha, no 2021-05-08 07:10:03 I want to attach to the vm console on the host 2021-05-08 07:10:09 ah 2021-05-08 07:10:34 so with -serial pty, it creates a pts device on the host 2021-05-08 07:10:40 but then you have to use some terminal for this 2021-05-08 07:10:45 screen 2021-05-08 07:10:47 yes 2021-05-08 07:10:57 or minicom or something like that 2021-05-08 07:11:08 But I use screen 2021-05-08 07:11:20 I use simple 'screen -dmS $name qemu-system-arm .....' 2021-05-08 07:11:37 These vms need to start with the os 2021-05-08 07:12:08 so now they run as a service in the background 2021-05-08 07:12:13 yes, I create start script for this which is in /etc/local.d. 2021-05-08 07:12:15 and you can attach to the console when you want 2021-05-08 07:12:18 yes, that's what we had 2021-05-08 07:12:55 but this is a little bit more controlled 2021-05-08 07:12:59 now I understand little more 2021-05-08 07:13:01 you can easily control individual vms 2021-05-08 07:13:14 rc-service qemu.gitlab-runner-armv7 stop 2021-05-08 07:13:23 rc-service qemu.gitlab-runner-armv7 start 2021-05-08 07:13:42 now I understand even more :) 2021-05-08 07:14:11 and 'we' use qemu-openrc for this? 2021-05-08 07:14:16 correct 2021-05-08 07:14:48 thanks for explanation, will try to find some time later and look at qemu-openrc 2021-05-08 07:15:22 one thing you did not answer yet: what do you use as image and bios for armv7? 2021-05-08 07:15:31 for running armv7 VM I use efi ovmf from debian 2021-05-08 07:15:32 there is no armv7 iso 2021-05-08 07:15:35 \aha 2021-05-08 07:16:04 yes, I asked ncopa about two months ago to make one but he is busy 2021-05-08 07:16:12 For now, we just use aarch64 and run the containers with linux32 2021-05-08 07:16:29 that's why we needed 32-bits mode 2021-05-08 07:16:43 and I create vm image using netboot and use it in uefi boot mode 2021-05-08 07:16:51 ok 2021-05-08 07:17:24 I'll open an issue btw to request CONFIG_COMPAT for -virt images 2021-05-08 07:17:31 (kernels) 2021-05-08 07:17:55 this is needed only on aarch64 2021-05-08 07:18:04 right 2021-05-08 07:18:20 and what about x86_64? 2021-05-08 07:18:57 I think it works 'out-of-the-box' 2021-05-08 07:19:13 ok 2021-05-08 07:20:47 never had problem to run x86 lxc or qemu VM on x86_64 host, so didn't looked for this on x86_64 2021-05-08 07:22:18 ok 2021-05-08 07:22:37 hmm, x86_64 also have it 2021-05-08 07:23:44 but it is already enabled on all 'our' kernels for x86_64 2021-05-08 07:24:22 #12658 2021-05-08 07:49:46 s390x CI is 'on lunch'? 2021-05-08 07:57:54 it's working on ceph 2021-05-08 07:58:16 ah, this will take time 2021-05-08 18:30:26 \o/ 2021-05-08 18:30:38 Another one bites the dust 2021-05-09 11:20:27 clandmeter: I see lately we have an increase in outbound traffic on deu1 2021-05-09 11:20:45 from <5Mb/s to ~20Mb//s 2021-05-09 11:42:29 Outbound? 2021-05-09 11:42:36 yes 2021-05-09 11:42:51 Hmm 2021-05-09 11:43:37 It's not public announced 2021-05-09 11:43:55 Oh it's deu1 2021-05-09 11:44:16 Not sure what it runs 2021-05-09 11:44:20 git 2021-05-09 11:44:27 pdns-geop 2021-05-09 11:44:33 secdb 2021-05-09 11:45:07 Which interface used most traffic? 2021-05-09 11:45:38 I think the can find the container that belongs to it 2021-05-09 11:46:17 I remember I had some script before as it's not obvious from the host 2021-05-09 11:46:36 It maybe docker can show it 2021-05-09 11:46:41 Or... 2021-05-09 11:47:20 br-9b7b71b2fd1f veth4ce0b5d vethb3ae52f veth33b682f 2021-05-09 11:48:12 that bridge is dmvpn 2021-05-09 11:48:46 Weird 2021-05-09 11:49:07 But no docker container used anything? 2021-05-09 11:50:43 That host is not even connected to dmvpn :) 2021-05-09 11:51:06 I guess it's traefik 2021-05-09 11:51:11 Yes 2021-05-09 11:51:18 Ipv6 2021-05-09 11:51:35 That's what we use that network for 2021-05-09 11:51:47 btw, I guess we should fix this: http://deu1-dev1.alpinelinux.org:8080 2021-05-09 11:52:06 Now for sure 2021-05-09 11:52:15 :) 2021-05-09 11:52:53 You can disable it if you like 2021-05-09 11:53:14 Or block the port 2021-05-09 11:53:17 deu1 is btw upgraded to 3.13, fyi 2021-05-09 11:53:45 disabled it for now 2021-05-10 07:05:02 ppc64le builder is still down 2021-05-10 09:37:45 good monday morning/day 2021-05-10 09:37:58 did anyone hear anything from ibm re ppc64le machine? 2021-05-10 10:31:38 No, haven't heard a thing 2021-05-10 10:31:43 except from zabbix :P 2021-05-10 10:31:57 i think we just got an email 2021-05-10 10:32:12 I haven't yte 2021-05-10 10:36:32 it was an "im on vacation email" 2021-05-10 10:36:45 oh :) 2021-05-10 11:19:56 ncopa: ikke: #12658 2021-05-12 14:41:41 Hmmmmm 2021-05-12 15:01:11 i'm disappointed in ibm that they haven't been able to find any ppc64le solution yet 2021-05-12 18:37:49 disappointed but not surprised 2021-05-13 08:55:39 ikke: we're getting 3 power9 ubuntu vms. I think we could use the first one as edge builder, the second as stable builder, the third as experiment to alpinize. 2021-05-13 08:56:14 OK 2021-05-13 08:56:26 once we managed to replace ubuntu with alpine on the third one, we can move the lxc containers from the first or second, and replace ubuntu with alpine 2021-05-13 08:57:51 let me create a ticket for the dns setup 2021-05-13 08:58:19 Or an MR πŸ˜‰ 2021-05-13 09:03:24 i don tthink we have the alpinelinux.org zone in git? 2021-05-13 09:03:57 We have 2021-05-13 09:04:19 linode-tf project 2021-05-13 09:11:11 i created a ticket in infra/infra since i didnt know where to create it 2021-05-13 09:11:17 Ok 2021-05-13 12:08:59 ikke: i'm adding you to the power9 machines. what ssh key do you want to use? 2021-05-13 12:09:16 https://gitlab.alpinelinux.org/kdaudt.keys ? 2021-05-13 12:13:05 Yes 2021-05-13 13:49:59 ikke: i have added your ssh key to the ppc64le vms 2021-05-13 13:50:08 im setting up the edge and 3.14 builders 2021-05-13 13:50:35 rsync the data was super fast 2021-05-13 14:10:58 we need enable port forward to 172.16.22.6 so the new ppc64le machines can upload build logs 2021-05-13 14:11:08 ssh port forward on some custom port 2021-05-13 14:11:35 maybe we can use port 22006? 2021-05-13 14:12:27 the ppc64le ubuntu machiens does not have the dmvpn routing 2021-05-13 14:12:48 Right 2021-05-13 14:13:25 currently the other build servers has a .ssh/config: 2021-05-13 14:13:28 Host distfiles.alpinelinux.org 2021-05-13 14:13:28 Hostname 172.16.22.6 2021-05-13 14:13:58 ikke: can you please help me set up ssh portforward? 2021-05-13 14:14:44 i should have worked on the presentation(s) for AlpineConf but am now stuck with those ppc64le machines... 2021-05-13 14:22:28 Yes, will do that 2021-05-13 16:49:57 ncopa: fyi: https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/merge_requests/4 2021-05-13 17:11:43 ncopa: it does not accept my ssh key 2021-05-13 22:42:16 ncopa: heh i decided i am just YOLOing my talks :) 2021-05-14 06:09:12 morning 2021-05-14 06:09:43 ikke: user is ubuntu 2021-05-14 07:08:13 Maybe it's better here actually. :) . i have jobs stuck in "pending". someone can help ? https://gitlab.alpinelinux.org/GreyXor/aports/-/pipelines/81748 2021-05-14 07:13:02 GreyXor: CIs are probably busy with something else 2021-05-14 07:14:10 ah, ceph is in queue, and it takes a lot of time 2021-05-14 09:51:02 clandmeter: do you want me to add your keys to the ppc64le vms? 2021-05-14 09:52:03 ncopa: could come in handy, i think mine were also on the other ones. 2021-05-14 09:52:29 do you need my help on those boxes? 2021-05-14 09:52:43 not sure what you are planning to do, i read reinstall alpine on them? 2021-05-14 09:58:21 clandmeter: there were 3 machines, ncopa started using 3 of them, the 3rd we can try to get alpine on it 2021-05-14 09:59:02 i guess 2 of them? 2021-05-14 09:59:32 i dont think we have OOB access on them? 2021-05-14 10:06:46 No, we only received ssh access 2021-05-14 10:07:03 clandmeter: ncopa used one for edge, ther other for stable 2021-05-14 10:11:06 nod 2021-05-14 10:11:30 but you need to be confident to install alpine without oob, or stupid :) 2021-05-14 11:00:10 clandmeter: ok. i'll add them. which keys do you want me to add? https://gitlab.alpinelinux.org/clandmeter.keys? 2021-05-14 11:20:29 >>> lua-aports: Fetching https://gitlab.alpinelinux.org/alpine/lua-aports/-/archive/v1.1.0/lua-aports-v1.1.0.tar.gz 2021-05-14 11:20:30 >>> lua-aports: Checking sha512sums... 2021-05-14 11:20:30 lua-aports-v1.1.0.tar.gz: FAILED 2021-05-14 11:20:30 sha512sum: WARNING: 1 of 1 computed checksums did NOT match 2021-05-14 11:22:07 Yeah, we need to start using releases 2021-05-14 11:22:41 the change is maximum compression 2021-05-14 11:23:17 β”‚ -gzip compressed data, max compression, from Unix 2021-05-14 11:23:17 β”‚ +gzip compressed data, from Unix 2021-05-14 11:23:55 seems like several implementations switched to that 2021-05-14 11:23:58 sr.ht, gitlab 2021-05-14 11:24:11 i think in gitlab case they went the other way? 2021-05-14 11:24:21 ah, yes 2021-05-14 11:27:34 im tired 2021-05-14 12:47:20 ikke, clandmeter: I have added your ssh keys from gitlab to ppc64le machines: ubuntu@158.175.161.154 ubuntu@158.175.161.156 ubuntu@158.175.161.157 2021-05-14 12:49:29 looks like ubuntu@gbr3-vm[1-3].alpinelinux.org also works 2021-05-14 12:54:24 Error relocating /home/buildozer/aports/main/wayland-protocols/src/wayland-protocols-1.21/output/tests/test-build-pedantic-unstable_xdg_decoration_xdg_decoration_unstable_v1_xml: xdg_toplevel_interface: symbol not found 2021-05-14 12:54:48 sorry wrong chan 2021-05-14 13:03:14 i have tried to enable portforward on 172.16.22.1, port 22006 -> 172.16.22.6:22 so ppc64le machines can upload build logs without the dmvpn 2021-05-14 13:03:39 but i cannot make it it work for some reason. ssh -p 22006 nld9-dev1.alpinelinux.org does not work 2021-05-14 17:33:26 alpine should probably prep for an IRC migration to libera.chat 2021-05-14 17:33:39 ddevault: we are aware of the situation 2021-05-14 17:34:07 ddevault: We planned a discussion on the conf about it 2021-05-14 17:35:45 if I were you I would prioritize it ASAP 2021-05-14 17:36:06 coming from a perspective with more information than the general public 2021-05-14 17:36:16 at least prep an alternative and then wait to throw the switch 2021-05-14 17:37:46 libera.chat is not working yet? 2021-05-14 17:38:04 oh, I guess they closed it 2021-05-14 17:38:11 yeah, website is offline as well 2021-05-14 17:38:26 tis not, but /shrug 2021-05-14 17:38:32 anyway, keep your eyes peeled and be prepared for fast action 2021-05-14 18:10:27 why libera.chat? what'd i miss? 2021-05-14 18:10:55 many freenode staffers are planning to quite 2021-05-14 18:10:57 quit 2021-05-14 18:11:29 oh ouch, i wonder what directions various communities will scatter in 2021-05-14 18:11:36 https://p.haavard.me/407 2021-05-14 18:12:59 i see 2021-05-14 18:14:03 info is limited, seems some legal stuff is blocking it. 2021-05-14 18:16:04 "OFTC is a competing IRC network run by tomaw who also is staging a hostile takeover of freenode as we speak. 2021-05-14 18:16:15 (unconfirmed) 2021-05-14 18:37:05 20:35 [libera] -!- Irssi: Connection to irc.libera.chat established 2021-05-14 18:37:47 what port? 2021-05-14 18:37:58 ah, irc. 2021-05-14 18:38:10 20:35 [libera] -!- Irssi: Connecting to irc.libera.chat [46.16.175.175] port 6667 2021-05-14 18:39:08 and '(Bad Password)' at the end 2021-05-14 18:40:05 yes, me too 2021-05-14 18:40:14 so password protected, I guess? 2021-05-14 18:41:08 and no info how to 'register', maybe it is same as freenode 2021-05-14 18:41:13 I don't think OFTC allegations are substantiated 2021-05-14 18:41:47 and tomaw's hands are pretty much clean 2021-05-14 18:42:53 mm, that part sounds like gossip and/or slander so i'll just pretend i didn't hear that until firm proof is presented 2021-05-14 19:15:47 Ariadne: do you still recall how the issue with the builders was solved where they log all build output to build.a.o? 2021-05-14 19:22:28 OFTC is run by Debian 2021-05-14 19:22:37 i am sure that it would be fine to use OFTC 2021-05-14 19:22:44 Alpine and Debian get along quite well anymore 2021-05-14 19:23:55 #alpine-linux and #alpine-devel are owned by ^7heo 2021-05-14 19:23:58 on oftc 2021-05-14 19:24:06 that seems like a problem 2021-05-14 19:24:19 I tried to ping him there, waiting for a response 2021-05-14 19:24:32 apparently there are lots of matrix users in oftc #alpine-linux 2021-05-14 19:24:35 ^7heo is liwakura 2021-05-14 19:24:37 or whatever 2021-05-14 19:25:07 I only know ^7heo from here 2021-05-14 19:26:08 no, he is not liwakura 2021-05-14 19:27:00 he is not? 2021-05-14 19:27:07 i thought they were the same person 2021-05-14 19:27:28 well, either way, #oftc should be able to sort that issue 2021-05-14 19:27:34 iirc, they are not same 2021-05-14 19:27:48 I would register the OFTC channels, just in case 2021-05-14 19:27:56 ddevault: they are already registered 2021-05-14 19:27:59 but imo we should put our weight behind libera.chat to forward their cause 2021-05-14 19:28:18 ddevault: libera.chat seems to expect a password 2021-05-14 19:28:24 they're not open yet 2021-05-14 19:28:32 but when they do, that's where I intend to take my channels 2021-05-14 19:31:50 ddevault: i believe we intend to 2021-05-14 19:32:47 however, the staff have asked us to try to support their attempt to get the freenode domains away from rasengan first before pulling the trigger on that 2021-05-14 19:33:01 (which is why the network is password-protected now) 2021-05-14 19:33:28 libera.chat going into production is "plan B" should rasengan not relinquish control of the domains to a trusted entity 2021-05-14 19:34:18 but we want to talk about all possible options 2021-05-14 19:34:23 understood 2021-05-14 19:34:46 a lot of people want the features that stuff like discord brings 2021-05-14 19:35:08 although discord is non-free software, there is mattermost, which does have an irc frontend 2021-05-14 19:36:05 so we want to ask the community what they want to see in the chat solution 2021-05-14 19:36:10 yikes 2021-05-14 19:36:20 if alpine leaves IRC I'm not coming with 2021-05-14 19:36:41 ddevault: also fair :) 2021-05-14 19:36:54 but in terms of the user base, alpine already left IRC 2021-05-14 19:37:05 the unofficial discord server is more active for support than our own IRC 2021-05-14 19:37:14 also I prefer irc 2021-05-14 19:38:09 most likely what will happen is that we will use libera.chat and also work with libera.chat to enable features that can let us win back users from discord 2021-05-14 19:38:27 there are nice clients out there with push support, like the lounge 2021-05-14 19:38:42 alpine already has an instance of the lounge that some developers use 2021-05-14 19:38:49 we can expand upon that, for example 2021-05-14 19:39:33 sr.ht will be shipping a public bouncer in the next few months 2021-05-14 19:39:43 with a hosted webchat attached to it as well 2021-05-14 19:39:47 I see a lot of users are connected over matrix to irc alpine channels 2021-05-14 19:39:51 that could be a good solution 2021-05-14 19:40:02 if the UI is pretty :) 2021-05-14 19:40:17 https://git.sr.ht/~emersion/gamja 2021-05-14 19:40:23 the screenshot is outdated but gamja is quite pleasant to use 2021-05-14 19:40:25 i associate sourcehut UIs with efficiency, not with pretty 2021-05-14 19:40:49 hmm, that is not too bad 2021-05-14 19:41:09 we could skin it 2021-05-14 19:41:32 looks a lot like weechat 2021-05-14 19:41:35 or irssi 2021-05-14 19:42:10 i think what most people want is something that looks acceptable on their phone and supports web push 2021-05-14 19:43:11 discourse ;) 2021-05-14 19:43:21 ddevault: this looks like a pretty viable path to "sexing up" irc 2021-05-14 19:44:35 if we could make it look like discord 2021-05-14 19:44:42 i think it would work well 2021-05-14 19:44:53 thats probably mainly a matter of CSS 2021-05-14 19:45:55 ddevault: by the way, while you're here, we have basically figured out the changes we need to make to our git-hooks to enable the gitlab bridge 2021-05-14 19:46:03 cool 2021-05-14 19:46:14 so if you will be around on monday, we can work to enable it 2021-05-14 19:46:14 I am still on vacation, technically, so we'll discuss the next steps as scheduled 2021-05-14 19:46:34 sure, i just wanted to let you know that we are go :) 2021-05-14 19:46:48 coolio 2021-05-14 19:59:59 ddevault: gamja and soju do look like something we could build with to solve the "zoomer user experience problem" 2021-05-14 20:09:20 set up the latest version 2021-05-14 20:09:36 send a few messages so I can make a pretty screenshot 2021-05-14 20:58:44 okay 2021-05-14 20:58:48 here's a few messages 2021-05-14 20:58:51 blah blah blah 2021-05-14 20:58:52 :) 2021-05-14 21:40:49 you're almost an hour late, already closed it 2021-05-14 21:41:00 just imagine a cool looking webchat and you'll be alright 2021-05-15 05:25:08 < 2021-05-15 05:52:47 irc served as alpine main communication channel for years and helped alpine to be as it is now. and now we have to switch to something else because some newcomers don't want/can't learn to use this simple thing 2021-05-15 09:48:10 i don't think alpine is what it is because of IRC or Freenode specifically, and it's not about switching away from IRC, it's about potentially switching from Freenode to another IRC network *if* it gets hijacked 2021-05-15 10:51:24 danieli: some people want to 'retire' irc and switch to something more modern 2021-05-15 10:51:54 right, that might be, and i don't blame them 2021-05-15 10:53:47 well, I prefer irc 2021-05-15 10:54:28 but will not cry if the alpine stop to using it 2021-05-15 10:54:43 will have more time for something more serious :) 2021-05-15 18:32:33 let's replace IRC with a WhatsApp group? 2021-05-15 18:42:02 sounds good, I'll implement it right away. Please everyone share your mobile phone number 2021-05-15 18:43:33 my is 00000000000 2021-05-15 20:51:50 +47 123 45 678 2021-05-15 20:59:15 huh!? frome where got my number!? 2021-05-15 21:01:10 in Telegram can use usernames and if not allow then others cant see the number but still need mobile to connect, and servers are closed source :\ 2021-05-16 07:20:25 s390x CI is stuck? 2021-05-16 07:33:58 building ceph 2021-05-16 07:34:39 yes, just looked on queue 2021-05-16 07:34:58 thanks 2021-05-17 07:19:33 morning! 2021-05-17 07:19:47 ikke: the abuild keys are copied to build-3-*-ppc64le 2021-05-17 10:26:05 ncopa: thanks 2021-05-17 10:35:57 enabled the 3.13 ppc64le builder 2021-05-17 11:00:21 morning 2021-05-17 11:00:30 available to handle the lists<>gitlab integration today 2021-05-18 07:29:47 seems there is some problems with gitlab today https://gitlab.alpinelinux.org/HRio/aports/-/jobs/395256 2021-05-18 07:38:52 maybe disk is full? 2021-05-18 07:40:25 i dont think so 2021-05-18 07:40:30 looks like 50GB free 2021-05-18 07:41:16 HRio: did you retry it? 2021-05-18 07:42:05 looks like network issue 2021-05-18 07:46:31 LBlaboon: seems like accept_ra is still set to 1 in network helper for alpine? 2021-05-18 07:52:39 looks like more users have issues, also on aarch64 (same host) 2021-05-18 08:05:27 yes, did a retry failed again 2021-05-18 08:06:13 found this failure as well https://gitlab.alpinelinux.org/LordVeovis/aports/-/jobs/395283 2021-05-18 08:06:27 "fatal: unable to access 'https://gitlab.alpinelinux.org/alpine/aports/': Failed to connect to gitlab.alpinelinux.org port 443: Operation timed out" 2021-05-18 08:07:04 that an x86_64 job 2021-05-18 10:14:01 HRio: i just retry it and it seems to work 2021-05-18 10:15:21 Seems intermittent 2021-05-18 10:50:19 clandmeter: OK 2021-05-18 10:51:33 thx 2021-05-18 12:33:19 who runs the irclogs service? 2021-05-18 12:33:26 i dont see a docker for it in gitlab 2021-05-18 12:41:10 Ariadne: algitbot 2021-05-18 12:41:22 so it needs to join the channels thatwe want logged 2021-05-18 12:41:26 okay 2021-05-18 12:41:39 can we join it to #alpine-cloud and i guess #alpine-security ? :) 2021-05-18 12:41:52 I'll look into it 2021-05-18 12:42:09 thanks 2021-05-18 18:23:36 clandmeter: thanks for pointing that out. there were some changes made to the way our networkhelper feature works and it looks like the accept_ra behavior got flipped back to how it was before. i'll see if we can get that fixed 2021-05-18 18:23:48 aha 2021-05-18 18:24:32 in the meantime, if you have networkhelper disabled then you get the correct value of "2" out of the box 2021-05-18 18:24:39 on a fresh deploy 2021-05-18 18:27:02 did you find out why we needed something like npd6 for smaller subnets? 2021-05-18 18:29:13 yea, i think it's related to the way we handle smaller subnets on the backend. i didn't realize that /116 subnets are handled specially and only given out under certain circumstances. /64 subnets are the ones we usually give out, so i swapped out each of your /116 subnets for /64 ones 2021-05-18 18:29:40 is the armv7 edge builder dead? 2021-05-18 18:29:51 hmm, let me check 2021-05-18 18:30:42 I think it's stuck 2021-05-18 18:30:50 aha 2021-05-18 18:31:19 iirc, andypost asked this last night 2021-05-18 18:31:26 yes 2021-05-18 18:31:29 forgot to look 2021-05-18 18:31:44 it's building python 2021-05-18 18:31:58 heh :) 2021-05-18 18:53:44 LBlaboon: yes we have it disabled for now via boot options 2021-05-18 18:54:43 clandmeter: did you get everything to work now? 2021-05-18 18:55:04 well kind of, if i had more time :) 2021-05-18 19:01:40 so now we need to add a /80 to daemon.json 2021-05-18 19:01:59 and the next we use for a network with ipv6 support 2021-05-19 05:01:34 we need to look at what's happening on deu1 2021-05-19 08:17:15 ikke: whats wrong on deu1? 2021-05-19 08:18:01 traffic 2021-05-19 12:07:53 time to move the alpine IRC channels 2021-05-19 12:07:58 cc clandmeter ikke ncopa Shiz 2021-05-19 12:09:02 ddevault: we were ahead of you 2021-05-19 12:09:07 cool 2021-05-19 12:09:13 we are already working on it 2021-05-19 12:09:32 The channels are on irc.oftc.net 2021-05-19 12:14:51 I guess -infra is +i there? 2021-05-19 12:15:28 by accident 2021-05-19 12:20:32 ddevault: where will sourcehut move? 2021-05-19 12:21:17 libera.chat 2021-05-19 12:24:53 commits mqtt should be adjsuted where to send messages 2021-05-19 12:25:05 yes 2021-05-19 12:49:58 bye 2021-05-19 12:50:11 see you on oftc 2021-05-19 16:22:19 yay 2021-05-19 16:22:21 oh 2021-05-19 16:22:23 it fixed 2 issues 2021-05-19 16:22:25 you fixed it? 2021-05-19 16:22:29 how did you fix it 2021-05-19 16:22:33 like you said :P 2021-05-19 16:23:16 i dont see any change to sircbot git or the docker-compose 2021-05-19 16:23:29 I changed the .env file 2021-05-19 16:23:43 https://tpaste.us/vZnk 2021-05-19 16:23:43 which is read by docker-compose 2021-05-19 16:23:54 is what i had in mind 2021-05-19 16:24:12 Yeah, probably still good to do 2021-05-19 16:24:13 i think the sircbot data structures need the channels to be specified separately 2021-05-19 16:24:15 I just now provided a single param 2021-05-19 16:24:20 ah ok 2021-05-19 16:24:55 for the hooks and similar 2021-05-19 17:37:28 o/ 2021-05-19 17:37:40 blaboon: hey 2021-05-19 17:37:44 welcome here :) 2021-05-19 17:38:07 i have a (slightly) different nick on OFTC 2021-05-19 17:38:21 I see 2021-05-19 18:17:24 clandmeter: we pushed out a fix for the accept_ra issue this morning, so that should be all good now 2021-05-19 18:17:48 oh....not here yet 2021-05-19 18:18:29 oh, hmm 2021-05-19 18:18:33 I'll relay it to him 2021-05-19 18:18:52 thanks! 2021-05-19 18:21:37 there he is 2021-05-19 18:21:47 blaboon β”‚ clandmeter: we pushed out a fix for the accept_ra issue this morning, so that should be all good now 2021-05-19 18:22:09 ^ 2021-05-19 18:26:11 is irc.alpinelinux.org service still running? 2021-05-19 18:27:10 no, I guess not for quite some time 2021-05-19 18:27:42 so I think we can set a CNAME for irc.alpinelinux.org 2021-05-19 18:27:53 for irc.oftc.net 2021-05-19 18:28:12 That was discussed 2021-05-19 18:28:13 debian does the same 2021-05-19 18:28:25 ah ok, sorry. I missed it, ikke 2021-05-19 18:28:53 It could lead to confusion for people who are already connected to oftc 2021-05-19 18:32:05 ppl who uses oftc will keep on using that one...if we had to change irc betweem oftc/libera.chat we will update the cname 2021-05-19 18:32:23 but if there was already a discussion on it, i'm not going to re-open it :) 2021-05-19 18:33:38 It was during AlpineConf 2021-05-19 18:51:14 it's a pity libera was not ready this morning 2021-05-19 19:08:16 blaboon: thx 2021-05-19 19:13:57 kunkku: welcome 2021-05-19 19:14:44 thank you, nice to see you all 2021-05-19 19:26:02 oh 2021-05-19 19:26:05 uhh 2021-05-19 19:26:09 i just realized something 2021-05-19 19:26:17 gitlab can put a message up that everyone sees, right? 2021-05-19 19:26:24 can we use that to advertise the IRC channel move 2021-05-19 19:27:10 fcolista: CNAMEs will break TLS clients 2021-05-19 19:27:50 [13:51:13] it's a pity libera was not ready this morning 2021-05-19 19:27:51 there's also ~alpine/announce 2021-05-19 19:28:01 i dont think libera was planning to have to launch today 2021-05-19 19:28:24 they were the preferred option, but we couldn't work out a migration plan with them 2021-05-19 19:28:29 we had one already with OFTC :) 2021-05-19 19:31:46 Ariadne: aren't we on libera #alpine-devel ;) 2021-05-19 19:32:10 not anymore :) 2021-05-19 19:32:30 ah, I see 2021-05-19 19:32:41 we're not doing that :) 2021-05-20 09:23:53 Ariadne: if we want to keep using bbb, maybe we should move it under alpine namespace? 2021-05-20 09:24:24 yes 2021-05-20 09:24:29 i have some ideas on how we could do this 2021-05-20 09:24:37 can we work on it next week? :) 2021-05-20 09:24:45 how much power does it actually need? 2021-05-20 09:25:18 it needs to run in a VM or on bare metal, you can't run it in a container 2021-05-20 09:25:24 sure, whenever you have time and feel like it 2021-05-20 09:25:32 we have some space on linode 2021-05-20 09:25:44 other than that, a typical linode should probably be able to do it 2021-05-20 09:25:53 i would recommend just using ubuntu and running bbb-install.sh 2021-05-20 09:26:08 nod 2021-05-20 09:47:23 by the way i think it is possible to make bigbluebutton use gitlab for login 2021-05-20 09:47:27 i'm not sure though 2021-05-20 09:47:36 i read something about oauth for federated login 2021-05-20 09:55:30 ikke: I adjusted the build-3-*-ppc64le machines to only build main and community and not testing 2021-05-20 09:56:15 ncopa: oh, oops 2021-05-20 09:56:30 no worries 2021-05-20 13:40:09 i was idling in #alpina-infra for two days wondering why nobody was there 2021-05-20 13:40:12 good at this irc thing 2021-05-20 13:44:52 Heh 2021-05-20 14:28:21 ikke: change irc net every week, so we are 'secured' 2021-05-20 14:29:27 (though after two days libera looks like have more 'features', certfp is one interesting) 2021-05-20 14:32:50 Isn't it oftc that has certfp? 2021-05-20 14:33:55 I think it libera, as freenode also have it 2021-05-20 14:34:15 https://libera.chat/guides/certfp 2021-05-20 14:46:31 i think most networks have had certfp for ages :p 2021-05-20 14:46:59 I'm not sure oftc have it 2021-05-20 14:47:30 but didn't read thoroughly their docs so maybe I'm wrong 2021-05-20 14:48:33 hmm, hello from other side! 2021-05-20 14:49:38 if somebody could be nice and paste with what host/address I joined 3 minutes ago... please! :) 2021-05-20 14:50:37 ACTION checking if "cloak" working right after connection or no 2021-05-20 14:55:45 mps: they do 2021-05-20 14:55:52 16:46:24 > : MY-R (~MY-R@0002b700.user.oftc.net) has joined #alpine-infra 2021-05-20 14:56:11 mps: https://www.oftc.net/NickServ/CertFP/ 2021-05-20 14:56:14 thank you Shiz, looks like working fine 2021-05-20 14:56:33 ye cert working, using it now with weechat 2021-05-20 14:57:50 Shiz: ah, I see, thanks 2021-05-20 15:20:42 does OFTC support password auth as freenode did? 2021-05-20 15:20:57 yes 2021-05-20 15:21:40 I didn't find it in the docs 2021-05-20 15:22:59 only certfp is explained there 2021-05-20 15:27:03 certfp is nice 2021-05-20 15:28:07 my client automagically generated a cert, i just need to add the fingerprint. 2021-05-20 15:29:56 will the server honor the CRL distibution point extension if I include one? :) 2021-05-20 15:30:15 It's a self-signed cert 2021-05-20 15:30:20 ikke: gitlab <> lists 2021-05-20 15:30:38 yes, I'm preparing 2021-05-20 15:32:09 I did have a brief look at the code, it appears there is no option yet for pushing to a different ref namespace? 2021-05-20 15:32:11 https://git.sr.ht/~sircmpwn/dispatch.sr.ht/tree/master/item/dispatchsrht/tasks/gitlab/patch_to_gitlab_mr.py#L277 2021-05-20 15:32:23 no, I can add this fairly easily 2021-05-20 15:32:45 if you can rig up the domains and such I can start testing on a secondary (i.e. not aports) repo 2021-05-20 15:32:57 that was the recommended next step when we talked about this several weeks ago 2021-05-20 15:34:38 we have gitlab-test.alpinelinux.org 2021-05-20 15:34:50 it's a couple of weeks old (db), but should work for testing 2021-05-20 15:35:04 ACTION shrugs 2021-05-20 15:35:09 it's not gitlab that we're testing here, per-se 2021-05-20 15:35:12 I can use it if you want 2021-05-20 15:37:19 I have a little patch which should move them to a different refs namespace 2021-05-20 15:37:42 with the DNS updated, reverse proxy installed, and an SSL cert for dispatch.a.o, I should be able to take the next steps for testing & validation 2021-05-20 15:59:33 ikke: progress? 2021-05-20 16:00:03 dispatch.alpinelinux.org 2021-05-20 16:01:33 I'm not sure this is actually being forwarded to the server right 2021-05-20 16:01:39 I don't see it show up in the access log when I boop the pages 2021-05-20 16:02:30 now it should 2021-05-20 16:02:35 though, it's hanging 2021-05-20 16:02:37 nice 2021-05-20 16:02:51 okay, I'll take it from here 2021-05-20 16:03:06 I'm going to run updates on this box, anyone offended if there's some brief lists downtime? 2021-05-20 16:03:24 not me 2021-05-20 16:06:05 does alpine use prometheus, by the way? 2021-05-20 16:06:44 We use zabbix for monitoring, there is some prometheus integration 2021-05-20 16:07:23 But we don't run prometheus as a tsdb 2021-05-20 16:07:33 the sr.ht services have some prometheus metrics that I can export if you want to add those 2021-05-20 16:07:42 just noticed some notes about that in my 3.13 upgrade notes 2021-05-20 16:07:48 rebooting the listserv box 2021-05-20 16:24:38 nginx is behaving really bizzarely on this server 2021-05-20 16:24:43 how so? 2021-05-20 16:24:49 maybe it's on my end 2021-05-20 16:24:53 but requests will just hang for a long time 2021-05-20 16:25:01 yes, I see that too 2021-05-20 16:25:11 it's definitely not the sr.ht code, cause it happens to static assets served by nginx too 2021-05-20 16:25:24 It's the same setup as for lists 2021-05-20 16:25:33 well, it's reproducible on lists, too 2021-05-20 16:25:38 the main difference is that I upgraded to 3.13 2021-05-20 16:26:15 hmm, I guess ipv6 2021-05-20 16:26:39 I only have v4 here 2021-05-20 16:26:53 yes, exactly :) 2021-05-20 16:27:01 oh 2021-05-20 16:27:24 have you seen this on any of the other servers after the 3.13 upgrade? 2021-05-20 16:27:34 I've seen this once before 2021-05-20 16:28:04 do you have any leads on a remidiation? 2021-05-20 16:28:48 working on it, still need to confirm the actual isseu 2021-05-20 16:28:54 alright, I'll leave you to your work 2021-05-20 16:36:27 ok fixed 2021-05-20 16:36:29 it was dns 2021-05-20 16:36:32 it's always dns 2021-05-20 16:36:33 nice, thanks 2021-05-20 16:36:38 what was the DNS issue? 2021-05-20 16:36:50 needed to add our internal resolved to nginx' resolvers 2021-05-20 16:36:55 not sure why it was suddenly an issue though 2021-05-20 16:37:11 I refer to the container by dns name in the proxy_pass statement 2021-05-20 16:37:17 ah 2021-05-20 16:37:27 something similar called for a change to sr.ht's internal configuration 2021-05-20 16:51:01 and, perhaps predictably, is causing me other problems now 2021-05-20 16:51:13 have to write a few more sr.ht patches to get the software to behave right when it cannot reach itself over its own URL 2021-05-20 16:52:48 here we go: https://gitlab-test.alpinelinux.org/ddevault/scdoc/-/merge_requests/7 2021-05-20 16:52:59 now I'll work on moving the branch into a separate refs namespace 2021-05-20 16:56:07 aww, gitlab lets me do it but it messes up the diff: https://gitlab-test.alpinelinux.org/ddevault/scdoc/-/merge_requests/8/diffs 2021-05-20 16:56:42 :( 2021-05-20 16:57:45 lemme try one more thing 2021-05-20 17:00:33 lol https://gitlab-test.alpinelinux.org/ddevault/scdoc/-/merge_requests/9 2021-05-20 17:11:50 okay 2021-05-20 17:11:59 I have everything working, but refs/not-head/whatever is not going to work 2021-05-20 17:12:08 I can file a bug with gitlab upstream, but in the meantime, is it acceptable to use a normal branch? 2021-05-20 17:14:19 I was preparing refs/heads/patches/* 2021-05-20 17:15:09 I can use that 2021-05-20 17:15:15 but not refs/patches/*, apparently 2021-05-20 17:15:47 yeah, they probably special case refs/heads 2021-05-20 17:16:03 it totally should have worked, and it was a good idea, though 2021-05-20 17:16:14 gitlab earns a lame/10 for this one 2021-05-20 17:16:24 agreed 2021-05-20 17:16:26 which seems to be the only grade I ever manage to award it anyway ;) 2021-05-20 17:24:05 https://gitlab.com/gitlab-org/gitlab/-/issues/331536 2021-05-20 17:29:24 at the normal pace of gitlab development we can expect a fix to land in about 8 years 2021-05-20 17:34:40 okay, I have validated the integration using a "patches/{id}" branch 2021-05-20 17:35:46 these are the remaining steps to complete the deployment: https://paste.sr.ht/~sircmpwn/fc8eac88c5d49adf2b0fb41bc9355a3a24203048 2021-05-20 17:36:36 I'm working on point 2 2021-05-20 18:00:46 https://gitlab-test.alpinelinux.org/alpine/aports/-/tree/patches/test 2021-05-20 18:01:12 hm? 2021-05-20 18:01:47 Testing the hook that would have otherwise prevented this 2021-05-20 18:01:54 ah cool 2021-05-20 18:43:59 ikke: where are we at now? 2021-05-20 18:44:17 I've created a bot user 2021-05-20 18:44:31 I'm updating the hook on prod now 2021-05-20 18:44:36 cool 2021-05-20 18:49:57 how does dispatch decide what projects to show? 2021-05-20 18:51:18 ah shit 2021-05-20 18:51:24 we might need to (temporarily) make the bot account an admin 2021-05-20 18:51:28 it needs to be able to create webhooks 2021-05-20 18:51:30 but only for the initial setup 2021-05-20 18:51:53 I'm assuming that's why it's not showing up in the list 2021-05-20 18:52:29 does it do that on project level? 2021-05-20 18:52:57 I think? Not sure how the gitlab API works in this respect 2021-05-20 18:53:35 I assume it does not need system hooks, which basically run gitlab instance wide 2021-05-20 18:53:40 no 2021-05-20 18:53:41 but each project has separate webhooks 2021-05-20 18:53:45 just for the project, not for the whole of gitlab 2021-05-20 18:56:06 it has access to create webhooks, but it does not show up yet 2021-05-20 18:56:41 so what we're doing is 2021-05-20 18:56:49 we call gitlab.projects.list(owned=True) 2021-05-20 18:56:56 let me see if there's something better I could do 2021-05-20 18:57:08 right, it's not an owned project 2021-05-20 18:57:16 it's in a different namespace 2021-05-20 18:58:15 hmmm 2021-05-20 18:58:34 ah I think I can s/owned/membership/ here 2021-05-20 18:58:42 nod 2021-05-20 18:58:47 I'll do a quick hotfix to see if it works, then add it properly 2021-05-20 18:59:09 try again now? 2021-05-20 19:00:17 It shows it now 2021-05-20 19:00:20 woot 2021-05-20 19:00:22 I'll add that upstream, then 2021-05-20 19:00:33 https://dispatch.alpinelinux.org/edit/7 2021-05-20 19:00:49 nice 2021-05-20 19:00:54 should just werk now? 2021-05-20 19:00:58 we'll see when the next aports patch comes in 2021-05-20 19:01:37 So in the hook, I basically limited the ref namespace where that bot can push to 2021-05-20 19:01:54 in what way? 2021-05-20 19:02:28 it can only push to refs/heads/patches/* 2021-05-20 19:02:41 okay, cool, that should(?) work 2021-05-20 19:02:51 yes, that was my thinking as well 2021-05-20 19:02:52 lemme see if I have any outdated packages I can do a quick patch for to test it 2021-05-20 19:05:16 hm, hit an issue 2021-05-20 19:05:17 investigating 2021-05-20 19:05:38 when pushing? 2021-05-20 19:06:32 no, with dispatch.sr.ht 2021-05-20 19:06:56 ok 2021-05-20 19:18:08 man it takes a long time to clone aports 2021-05-20 19:22:16 the issue now is that aports takes such a long time to clone that the HTTP request times out while dispatch.sr.ht is fetching it, and the worker is terminated 2021-05-20 19:22:27 this won't happen every time, just on the first patch it works with 2021-05-20 19:23:46 You can apply a --depth 2021-05-20 19:23:56 ACTION shrugs 2021-05-20 19:23:57 temporary problem 2021-05-20 19:24:02 behold: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21596 2021-05-20 19:24:25 should be rocking and rolling now 2021-05-20 19:24:28 thanks for your help, ikke! 2021-05-20 19:25:34 while we're looking at the mailing lists, one more point of note 2021-05-20 19:25:37 ~alpine/infra is overrun with spam 2021-05-20 19:25:52 does this list even need to exist anymore? we might want to archive it 2021-05-20 19:25:59 yeah, we should discontinue that 2021-05-20 19:26:06 I'll make it read only and clean out the spam 2021-05-20 19:28:01 100% of this spam would have been foiled by prohibiting HTML email ;) 2021-05-20 19:36:13 alright, I think that's a bow on everything 2021-05-20 19:36:19 let me know if anything breaks 2021-05-20 19:37:21 You said you had some monitoring endpoints? 2021-05-20 19:37:42 https://meta.alpinelinux.org/metrics 2021-05-20 19:37:49 Nice that the bot works now :) 2021-05-20 19:37:50 https://lists.alpinelinux.org/metrics 2021-05-20 19:37:55 https://dispatch.alpinelinux.org/metrics 2021-05-20 19:38:04 that's all, can also set up prometheus-node-exporter on the box if you so wish 2021-05-20 19:38:13 Can devs handle the MRs by the bot the same way we can handle normal MRs? 2021-05-20 19:38:24 If not, could we have a ~devel post saying how we should handle these MRs? 2021-05-20 19:38:30 they can treat them like normal MRs, yes 2021-05-20 19:38:42 the one limitation is that if the submitter sends a v2, it will create a new merge request, and the old one must be manually closed 2021-05-20 19:38:50 this will be addressed in the long term, but not the near term 2021-05-20 19:38:55 I can write a devel post, though 2021-05-20 19:39:17 Yup, I think that's a good idea either way so everyone is on the same page 2021-05-20 19:39:24 Thanks for the work on the bot :) 2021-05-20 19:39:34 no problem :) 2021-05-20 19:41:11 ah so patches from ML will automatically show on gl.a.o? 2021-05-20 19:41:22 aye 2021-05-20 19:41:31 wow, nice, gj! :) 2021-05-20 19:43:24 awesome 2021-05-20 19:43:26 irc server changed, bot got extra features, all moving on :) 2021-05-20 19:45:57 https://lists.alpinelinux.org/~alpine/devel/%3CCBIBXMCZAEGA.1AI1ROGFMRV0Z%40taiga%3E 2021-05-20 19:46:25 hmm, did someone merge that MR? 2021-05-20 19:46:32 !21595 2021-05-20 19:46:41 It's not merged 2021-05-20 19:46:52 investigating an issue leo found 2021-05-20 19:47:01 something weird is going on 2021-05-20 19:47:14 ah, it created the MR again 2021-05-20 19:47:23 !21596 2021-05-20 19:47:51 it seems that it created two? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21596 2021-05-20 19:47:58 yes 2021-05-20 19:48:03 this is for two different patches 2021-05-20 19:48:13 I sent the emails several times to test it out, maybe it caught a backlogged one 2021-05-20 19:48:23 let's assume it won't happen again until further evidence contradicts this 2021-05-20 20:12:36 hmm, strange, download.redis.io is acting up on our ppc64 machines 2021-05-20 20:12:50 almost like they're tarpitted 2021-05-20 21:17:36 can someone with mail server access blackhole no-reply@dispatch.alpinelinux.org please 2021-05-20 21:17:43 just suck it into /dev/null 2021-05-20 21:17:48 right now it bounces and sends errors back to the user 2021-05-21 10:26:33 ikke: tpaste is giving bad gateways 2021-05-21 10:26:58 like 50% of the time 2021-05-21 10:27:08 maybe one of the workers has crashed 2021-05-21 10:27:08 Yeah noticed that, any idea why? 2021-05-21 10:28:29 I already increase the amount of workers to 8, but that did not help 2021-05-21 10:28:34 all workers are up 2021-05-21 10:28:34 Socket operation on closed stream 2021-05-21 10:30:32 was it upgraded recently? 2021-05-21 10:31:05 The host has been upgraded 2021-05-21 10:31:21 I'm not sure if the container has been updated 2021-05-21 10:31:22 btw, ive seen kernel issies with one of the hosts 2021-05-21 10:31:32 linode one 2021-05-21 10:31:46 deuX 2021-05-21 10:33:36 i restarted them and back to 4 2021-05-21 10:33:53 did you kill the old containers? 2021-05-21 10:34:15 they were recreated 2021-05-21 10:34:38 its okish now 2021-05-21 10:34:43 lets see what happens 2021-05-21 10:47:14 for some reason, our ppc64le builders cannot download from download.redis.io 2021-05-21 10:47:19 curl requests just hang 2021-05-21 16:12:09 what would be the impression of sunsetting the alpine twitter account in favor of a free software platform 2021-05-21 17:02:10 i've asked about setting up an alpinelinux mastodon or similar that could be the preferred microblog option 2021-05-21 17:02:41 given the lack of activity on the alpinelinux account, i don't think it matters much either way 2021-05-21 17:03:27 we should create an actual marketing team which handles these issues and makes the decisions, but of course, i would prefer our authoritative social channels to be on systems that we own, just like our code is 2021-05-21 17:03:48 (i also think that is the case for liberachat, but the bikeshed was stressing me out) 2021-05-21 17:05:44 this is outside the technical aspects of the distribution though, and so the alpine council would need to create a social team to handle this (regardless of whether we use mastodon or twitter) 2021-05-21 17:05:52 ddevault: that's basically my thoughts ^ 2021-05-21 17:08:08 it should be noted that mastodon's docker images run on alpine out of the box, so we would be immediately self-dogfooding should we choose to deploy a mastodon instance 2021-05-21 17:08:46 but i think equally important is having an actual person posting content 2021-05-21 17:10:35 so basically +1 on having a mastodon 2021-05-21 17:11:00 i think we should retain the alpinelinux account to prevent impersonation though 2021-05-21 17:11:10 and i think at least urgent notices should continue to be posted there 2021-05-21 17:30:44 I think that the twitter account should be removed from the community page and demoted to unofficial status 2021-05-21 17:31:34 I agree that setting up a mastodon instance to replace it would be ideal, and that it would be pretty straightforward to do 2021-05-21 17:32:00 but as far as finding content to post there and someone to maintain it - well, I don't think that answering this question is a requirement for sunsetting the twitter account 2021-05-21 17:32:11 after all, we'd need the same problem solved to generate new activity for twitter 2021-05-21 17:45:27 part of the point of using twitter is to reach users with important annuoncements and information, and an online presence probaby helps promote it as well 2021-05-21 17:46:13 if you want to get rid of the twitter account, i'm not sure what good replacing it with mastodon will do, so in that case i'd be in favor of not having official social media accounts for alpine 2021-05-21 17:46:45 I agree that alpine would be quite alright without any social media presence at all 2021-05-21 17:46:56 self-hosting more software would also lead to less time for more important work 2021-05-21 18:38:36 i think the alpine twitter is fine and should be kept as such :P 2021-05-21 18:39:22 having a masto presence is good, although i'm wary of the infra load of having our own masto instance 2021-05-21 18:41:13 do you follow the twitter account? 2021-05-21 18:41:48 ? 2021-05-21 18:41:55 i do, it is very inactive 2021-05-21 18:41:59 do you follow the alpine twitter account, Shiz? 2021-05-21 18:42:09 i can read 2021-05-21 18:42:13 i am just wondering what relevance the question has 2021-05-21 18:42:21 well, the follow-up is if you find it useful or relevant as such 2021-05-21 18:42:32 i follow ncopa, who retweets ~everything from there 2021-05-21 18:42:38 i find it useful 2021-05-21 18:43:00 does it need to be "official" for it to provide that utility for you 2021-05-21 18:43:01 i think most of the actual evangelism of alpine on twitter comes from sources other than @alpinelinux 2021-05-21 18:43:27 yes 2021-05-21 18:43:36 why? 2021-05-21 18:43:47 anyway i don't see what this has to do with -infra 2021-05-21 18:44:00 I reckon the twitter account qualifies as part of alpine's infrastructure as it is an official communications channel 2021-05-21 18:44:18 i mean i guess 2021-05-21 18:44:53 because i am not interested in info that i'd need to separately verify 2021-05-21 18:45:35 why twitter for that purpose when it could be any number of other mediums 2021-05-21 18:45:43 because i don't use those mediums 2021-05-21 18:45:55 an official facebook page, and an official yellow pages ad, and an official chalkboard at the local cafe 2021-05-21 18:46:03 how do we choose? *someone* uses all of those mediums 2021-05-21 18:46:17 come on now, this is just bordering on dishonest at this point 2021-05-21 18:46:21 I think it's valid to critically examine the mediums even if they are used by someone, every medium is used by someone 2021-05-21 18:46:22 i know you don't like twitter, that is perfectly clear 2021-05-21 18:46:27 and I think "should be FOSS" is a good criteria 2021-05-21 18:46:32 in what way am I being dishonest 2021-05-21 18:47:40 downplaying one of the primary mechanisms for selecting a communication medium, reach, as "well everything is used by someone" and cmparing it to mediums with almost no reach 2021-05-21 18:47:47 but i don't think i need to tell you that, you know that 2021-05-21 18:48:08 painting masatodon as having "almost no reach" isn't very honest, either 2021-05-21 18:48:26 i never said that about mastodon, though 2021-05-21 18:48:32 I could point out that mastodon offers access to a large audience which *isn't* on twitter, if we want to talk in terms of reach 2021-05-21 18:48:35 and in fact, i am in favor of having a mastodon presence :) 2021-05-21 18:48:43 so you're not arguing against me on that one 2021-05-21 18:48:48 what medium are you saying I'm comparing it to, then? 2021-05-21 18:48:53 20:45:55 ddevault : an official facebook page, and an official yellow pages ad, and an official chalkboard at the local cafe 2021-05-21 18:48:56 ah 2021-05-21 18:49:14 okay, that was dishonest, but for illustrative purposes 2021-05-21 18:49:16 I thought that was apparent 2021-05-21 18:49:40 i disagree with the illustrated point ;) 2021-05-21 18:49:45 the question is: what criteria matters? (1) reach 2021-05-21 18:49:48 anything else? 2021-05-21 18:49:57 I would say yes, there are other criteria that matter 2021-05-21 18:50:33 there's always a ton of criteria, the question is how they are weighed :) 2021-05-21 18:50:34 and in this specific instance I'm saying that it's something we should talk about and figure out deliberately, rather than waving it away without critical thought 2021-05-21 18:50:39 cost of being on there is another criterium 2021-05-21 18:50:53 e.g. major billboard ads tend to be expensve 2021-05-21 18:50:59 as such we don't do them 2021-05-21 18:51:08 (reach aside...) 2021-05-21 18:51:13 also the cost of not being there, efficacy of the medium for outreach, ethical criteria of the platform in question, reliability, etc 2021-05-21 18:52:50 for full disclosure: as of right now I'm not fully convinced it's worth the limited time effectively deliberating all criteria by the infra team and will lead to a discussion with only you having put effort into it (and maybe 'winning' by default?) 2021-05-21 18:53:05 which leads back into Ariadne's earlier point of a social media/PR team that could take on this role/discussion 2021-05-21 18:53:11 hence my apprehension :) 2021-05-21 18:53:13 haha 2021-05-21 18:53:20 establishing a social media or PR team is a WAY bigger effort 2021-05-21 18:54:43 very possible, but it has good returns and leads to higher quality discussion of these issues, I feel 2021-05-21 18:54:57 death by committee is a CIA-endorsed sabotage tactic 2021-05-21 18:55:46 i can assure you i am not involved with any three-letter agency 2021-05-21 18:55:49 let's drag this discussion back out of the meta realm and down into the actual matter at hand: should alpine have a twitter account 2021-05-21 18:56:12 we can discuss the establishment of additional bureaucracy separately 2021-05-21 18:56:25 perhaps using the twitter discussion as a case study to motivate its arguments :) 2021-05-21 18:56:35 ddevault: it is, but it is also necessary 2021-05-21 18:56:50 I disagree, but again, I would prefer not to veer off topic 2021-05-21 18:56:51 right now social stuff falls largely on me and ncopa 2021-05-21 18:57:15 i mean, don't get me wrong, i love bragging about how great the alpine community is 2021-05-21 18:57:23 gets those endorphins flowing every time 2021-05-21 18:57:24 with the kind of bandwidth alpine is working with, booting an issue to an as-of-yet unestablished committee is the same thing as doing nothing 2021-05-21 18:57:40 well that is the thing 2021-05-21 18:57:51 you are asking about an account which basically does nothing 2021-05-21 18:57:58 so it does not seem that important 2021-05-21 18:58:08 well, I think the optics are important 2021-05-21 18:58:20 i agree with you 2021-05-21 18:58:23 at the least, I can produce at least one person who feels the matter is important enough to discuss 2021-05-21 18:58:40 and if it does nothing: why have it? 2021-05-21 18:58:56 It does enough for 8k people to care following it 2021-05-21 18:59:00 why are you obsessed with this today 2021-05-21 18:59:02 if it's neglected it's almost a vulnerability, what if the account is compromised and no one notices the fake security advisory it tweets 2021-05-21 18:59:17 It's not neglected, just used for specific purposes 2021-05-21 18:59:49 I don't see twitter as part of infrastucture 2021-05-21 18:59:51 Ariadne: I was having a similar discussion elsewhere (you know the one) and it occured to me that alpine is another space that the discussion ought to occur in 2021-05-21 18:59:51 is it not neglected, and unless there's specific data to suggest it has a relevant impact on the optics of alpine it also doesn't seem like a high-prio issue 2021-05-21 18:59:55 ikke: i think given the size of alpine's community, there should be more than 8k followers if it was actually doing something useful 2021-05-21 19:00:08 if there is need to host our own things, we can talk about facilitating that 2021-05-21 19:00:15 Ariadne: some people like me, follow it through ncopa, but that is likely a very small number :p 2021-05-21 19:00:16 anyway 2021-05-21 19:00:34 i need to focus on alpine 3.14 release engineering 2021-05-21 19:00:40 and i think ikke needs to too 2021-05-21 19:00:43 yup 2021-05-21 19:00:51 the releases never stop being a priority -_- 2021-05-21 19:00:55 w/e, it's fine 2021-05-21 19:01:05 well, we are a linux distribution 2021-05-21 19:01:12 linux distributions release things 2021-05-21 19:01:13 I don't mean that they shouldn't be 2021-05-21 19:01:15 after a release is done, it's not an immediate priority 2021-05-21 19:01:16 kinda what we do 2021-05-21 19:01:27 I mean "we're working on a release" is the constant excuse for not doing something 2021-05-21 19:01:43 well, you could time things when we're not working on a release 2021-05-21 19:01:52 that's the thing. Alpine is almost always working on a release. 2021-05-21 19:01:58 No, we're not 2021-05-21 19:02:04 yes, but you know that crunch time is may and november 2021-05-21 19:02:07 I admit 3.14 is right around the corner 2021-05-21 19:02:13 I'll bring it up again shortly thereafter 2021-05-21 19:02:19 okay thanks 2021-05-21 19:02:24 I have not had success with that timing before, and I don't expect to again 2021-05-21 19:02:27 but so be it 2021-05-21 19:02:27 i agree with you, we should do something with fediverse 2021-05-21 19:02:52 but we should strive to actually solve the social problem too. 2021-05-21 19:03:15 fwiw, I also think it'd be good for alpine to be active on the fediverse 2021-05-21 19:04:31 there is some implementation called micropub 2021-05-21 19:04:38 that i guess would work well for this 2021-05-21 19:05:51 ddevault: 100% agree with you on optics and everything, alpine as one of the most software freedom oriented distributions should prioritize free software communications channels over proprietary ones 2021-05-21 19:06:14 (this is also why alpinelinux twitter is neglected in the first place, i think we are not really that interested in it anyway) 2021-05-21 19:06:50 I'm not sure if you want me to engage with this or if we agreed to defer to post-release 2021-05-21 19:08:32 i am just summarizing my thoughts :) 2021-05-21 19:09:40 okay :) 2021-05-21 19:11:15 what would be really neat would be a mastodon instance which allows alpine contributors to sign up using gitlab 2021-05-21 19:11:38 if there's one thing that I know will increase Alpine's infra load it's a single sign-on system 2021-05-21 19:12:44 indeed, but if the cost is mild i don't think they will mind, given the benefits it will generate 2021-05-21 19:13:14 i know that debian have pleroma which is integrated with their gitlab 2021-05-21 19:13:55 fwiw I have no opinion regarding which fedi implementation is used 2021-05-21 19:14:24 I definitely would not block this on the prospect of the infra team agreeing to maintain social networking services for alpine contributors in general 2021-05-21 19:14:37 I'm also not convinced that alpine even needs a social media presence 2021-05-22 21:37:42 Hi there! Roman here (RISCV guy). There seems to be a consensus on the fact that it would be useful for Alpine 3.15 to have riscv64 support and I'd like to start making progress towards that. 2021-05-22 21:37:45 My preliminary builds of aports produced 10Gb of riscv64 binaries with 50% of testing/community and 90% of mains buildable (with a few patches I'm upstreaming now) 2021-05-22 21:38:18 Aridane suggested we should now proceed with putting together a riscv64 builder (qemu-user-static based) and I'd love to know how can I help make this happen 2021-05-22 21:39:25 rhatr: most members of infra are in CET TZ, so probably they are sleep right now 2021-05-22 21:39:39 (also I should go to bed) 2021-05-22 21:39:53 no worries -- as long as they take a look when they wake up -- we're all good ;-) 2021-05-22 21:40:13 sure, they will :) 2021-05-22 21:40:44 oh, awesome! I'm keen on riscv64 :) 2021-05-22 21:41:00 but yes - it is currently 11.40 pm here 2021-05-22 22:00:34 rhatr: hi 2021-05-22 22:01:57 hi there! 2021-05-22 22:02:40 you want to use qemu-user right? 2021-05-22 22:03:46 yeah we gonna use qemu-user 2021-05-22 22:03:57 might move mips64 to qemu-user too if it works well with riscv64 2021-05-22 22:04:07 i thought you had issues with qemu user 2021-05-22 22:04:24 i did, but qemu 6.0 makes a lot of improvements 2021-05-22 22:04:28 i think its viable now 2021-05-22 22:04:45 riscv64 will be the testcase imo 2021-05-22 22:05:42 yup -- currently using qemu-user-static + binfmt -- works like a charm (even on GH x86 ubuntu runners) 2021-05-22 22:05:50 and despite the issues, we did initially bring up, and even build the entirety of main, and most of community and testing 2021-05-22 22:05:56 for mips64 2021-05-22 22:06:09 i just did not want to make it official until i had real hw that was viable 2021-05-22 22:06:13 since real hw did exist 2021-05-22 22:06:18 for riscv64 well :p 2021-05-22 22:06:36 i wonder how to implement it in our current build infra 2021-05-22 22:07:11 What IS your current build infra if I may ask? ;-) 2021-05-22 22:07:12 my guess would be LXC container with qemu-user outside 2021-05-22 22:07:22 thats how i did it with mips64 initially 2021-05-22 22:08:04 it would be nice to have actual real hardware 2021-05-22 22:08:05 anyway i have been up since 2am fixing packages 2021-05-22 22:08:24 >it would be nice to have actual real hardware 2021-05-22 22:08:26 clandmeter: yeah, it would, unfortunately it doesnt exist yet :p 2021-05-22 22:08:33 unless you're in China -- that doesn't exist yet 2021-05-22 22:08:55 Actually -- let me take it back -- Chinese Academy of Sciences offered me a really fast build server -- but I'd rather not do that ;-) 2021-05-22 22:09:19 good luck getting them to actually ship it to you 2021-05-22 22:09:30 they only offer ssh 2021-05-22 22:09:37 but it IS fast 2021-05-22 22:09:41 all of our attempts to get loongson hardware have failed miserably over the years 2021-05-22 22:09:52 they even showed up offering hw to alpine 2021-05-22 22:09:57 yeah -- the concept of donating hardware is foreign to them 2021-05-22 22:09:58 we give them address to ship to 2021-05-22 22:10:00 poof, gone 2021-05-22 22:10:19 "hi i want to buy loongson machine" 2021-05-22 22:10:30 "ok wire to here, account info blah blah blah" 2021-05-22 22:10:38 "oh, you're in USA? we can't sell to you sorry" 2021-05-22 22:11:03 HiFive Unmatched isnt that riscv64? 2021-05-22 22:11:04 LOL -- yup! But the ssh works, on the other hand -- I'm not in the mood of scrubbing backdoors off of my binaries 2021-05-22 22:11:13 > HiFive Unmatched isnt that riscv64? 2021-05-22 22:11:18 it is -- but it is dog slow 2021-05-22 22:11:38 Huawei is the only one who has REALLY competitive server chip at this point 2021-05-22 22:12:53 But it seems that 2022 is when the drought is about to be over -- there's a LOT of activity in China around building riscv64 server chips 2021-05-22 22:13:16 And rightfully so -- both Intel and ARM are now US owned companies 2021-05-22 22:13:21 clandmeter: hifive unmatched is slow 2021-05-22 22:13:33 clandmeter: it also has the most bullshit bootloader on the planet 2021-05-22 22:13:42 they looked at chromebooks and went "oh this looks good" 2021-05-22 22:13:46 and basically did that 2021-05-22 22:14:15 worst use of my money ever 2021-05-22 22:14:33 well maybe not ever, but i wouldn't consider it fruitful 2021-05-22 22:14:40 qemu is faster 2021-05-22 22:14:44 i am not even kidding 2021-05-22 22:15:28 anyway i've been up since 2am fixing packages so i'm going to take a nap 2021-05-22 22:32:47 have a good night! 2021-05-23 07:29:33 is it soooooo important which government injects backdoors 2021-05-23 09:23:48 anyone knows if multithread qemu-user is supported (from host) 2021-05-23 09:24:14 looks like qemu does show 8 threads but it actually used a single one on the host 2021-05-23 09:33:31 Ariadne: any clue? 2021-05-23 09:53:59 i have no clue :) 2021-05-23 09:54:29 make -j8 should spawn 8 processes though still 2021-05-23 09:57:58 [02:29] is it soooooo important which government injects backdoors 2021-05-23 09:58:10 alpine is committed to quality, including the government back doors 2021-05-23 09:58:13 :) 2021-05-23 09:59:11 We're picky with the backdoors 2021-05-23 09:59:13 :P 2021-05-23 11:24:09 :) 2021-05-23 18:00:03 I am back -- not sure if anyone got any ideas -- but I'd love to continue the above discussion today if there's interest 2021-05-23 18:00:16 rhatr: hi 2021-05-23 18:00:25 ikke: hi there! 2021-05-23 18:20:45 hi rhatr 2021-05-23 18:21:05 i have tried qemu-user and your work 2021-05-23 18:21:08 rhatr: how are you running the gitlab runner with qemu-user? 2021-05-23 18:21:23 im bumping into issues with multi thread and qemu-user 2021-05-23 18:22:30 ikke: you can use https://github.com/multiarch/qemu-user-static 2021-05-23 18:25:56 rhatr: my host only uses a single core while my container thinks it uses 8 2021-05-23 18:25:58 Is that available for risc? 2021-05-23 18:26:37 Yes it's regular qemu which supports riscv64 2021-05-23 18:27:16 The container is just whatever the host is 2021-05-23 18:28:19 But in not sure everything is available to build the runner 2021-05-23 18:29:02 rhatr said he is already using a gitlab-runner 2021-05-23 18:53:36 ikke: I actually used GitHub runner for my EVE work -- and it works like a charm 2021-05-23 18:54:23 ah, not yet for risc v? 2021-05-23 18:54:40 clandmeter: can you elaboriate on your issues with multi thread and qemu-user ? I haven't found any while running on a 32-core x86 box. All of those 32-cores were visible and functional and I definitely had make running native riscv64 code utilize them all 2021-05-23 18:57:10 btw, just to be clear here's the entire setup that is required on GitHub while utilizing their x86 ubuntu-latest https://github.com/lf-edge/eve/blob/master/.github/workflows/publish.yml#L27 2021-05-23 18:57:41 My question to y'all is what are the steps to get the same kind of builder hooked up to Alpine infra 2021-05-23 18:59:34 Our official builders are lxc alpine containers which run aports-build 2021-05-23 19:00:28 Is there some kind of a "infrastructure as code" thingie that defines a builder? E.g. what kind of packages need to be installed, etc. 2021-05-23 19:00:42 no 2021-05-23 19:00:59 Like I'm saying -- I'm more than willing to do the work of preparing one for y'all (but obviously I can't run one -- since I'm not part of the Alpine infra team) 2021-05-23 19:01:01 you might want to watch ncopas talk :) 2021-05-23 19:01:53 ikke: sure I'll watch the talk -- but then the question still stands -- what exactly can I hand over to y'all so that a riscv64 lxc builder pops up into existence? 2021-05-23 19:03:10 rhatr: Normally our builders are all native, so this is a bit of a new situation 2021-05-23 19:03:51 ikke: interesting! Ariadne told me that there was a similar situation with mips -- but I guess that migrated? 2021-05-23 19:04:03 yes, indeed 2021-05-23 19:04:32 As a total aside: where did you manage to find a decent MIPS build server? What HW are you using? 2021-05-23 19:04:42 An octeon based router 2021-05-23 19:04:52 and, I'm not sure if we can call it decent :P 2021-05-23 19:05:46 I was about to say -- that's dog slow 2021-05-23 19:06:22 I mean -- two options are: have a qemu-user based builder OR have a full fledged qemu-system riscv64 VM 2021-05-23 19:06:36 rhatr: let me test a few things 2021-05-23 19:06:48 I will get back to you 2021-05-23 19:06:49 rhatr: I think the situation with riscv is different from mips 2021-05-23 19:06:58 Maybe you can create an issue? 2021-05-23 19:07:08 I understood that qemu for riscv is more viable than misp64 2021-05-23 19:07:14 not sure who/how needs to make that decision, but: 1. as I said -- feel free to pull me in -- I'd LOVE to help as much as I can. 2. personally qemu/riscv64 seems very decent these days 2021-05-23 19:08:17 ideally we'd have 2 servers, one for the builders, and one for CI 2021-05-23 19:08:19 ikke: yes -- given that riscv in general lagged BIGGLY on delivering actual hardware -- the qemu/riscv64 ended up being the only way to develop for riscv64 (and hence got MUCH more attention) 2021-05-23 19:08:45 clandmeter: good idea on the issue -- let me do that right now 2021-05-23 19:09:01 I have a project I used that to build a builder in docker 2021-05-23 19:09:13 rhatr: https://gitlab.alpinelinux.org/alpine/infra/infra 2021-05-23 19:09:22 I did most of the riscv work on real hardware 2021-05-23 19:09:24 fwiw 2021-05-23 19:09:33 Keyboard mess... 2021-05-23 19:10:40 But I do wonder why I'm not getting all threats working on the host 2021-05-23 19:13:40 FYI: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10722 2021-05-23 19:14:19 ddevault: SiFive Unleashed or something? 2021-05-23 19:14:23 yeah 2021-05-23 19:14:44 That's been dog slow for me -- especially for the builds that are highly parralelizable 2021-05-23 19:15:31 https://mirror.drewdevault.com/alpine/edge/ 2021-05-23 19:15:40 fast enough to build all of these packages in a reasonable amount of time 2021-05-23 19:15:41 Β―\_(ツ)_/Β― 2021-05-23 19:15:53 how many packages are there and how long did it take? 2021-05-23 19:16:13 I don't recall how long it took, less than two weeks and only partial utilization during that time 2021-05-23 19:16:27 Here's what I got in 5 days: 2021-05-23 19:16:30 $ find ~/packages -type f | wc 2021-05-23 19:16:30 10027 10027 662220 2021-05-23 19:16:34 as for how many, a few hundred I gess 2021-05-23 19:17:05 I would guess that it would take about 2-3 times that long to build them all natively 2021-05-23 19:17:07 so not terrible 2021-05-23 19:17:09 uploading it to Linux Foundation S3 bucket as we speak 2021-05-23 19:19:33 Subset of it (required by EVE) is already under https://eve-alpine-packages.s3.amazonaws.com/edge 2021-05-23 19:59:23 rhatr: it is 16-core octeon router 2021-05-23 19:59:31 so it is slow, but at least there is 16 cores 2021-05-23 20:02:39 Ariadne: how did you run lxc with qemu-user? 2021-05-23 20:03:36 qemu-openrc's qemu-binfmt service on the host 2021-05-23 20:03:45 i worked with jirutka to make it use fixate mode 2021-05-23 20:04:15 alpine 3.12 and newer have the bits :) 2021-05-23 20:04:23 ok 2021-05-23 20:04:28 ubiquiti iirc 2021-05-23 20:04:34 clandmeter: yes, edgerouter infinity 2021-05-23 20:04:53 oh i had scrolled up :) 2021-05-23 20:05:38 they dont sell it anymore 2021-05-23 20:05:54 which is why i hope that qemu-riscv64 works well 2021-05-23 20:06:10 because i don't think we will be able to get viable hardware for mips64 again 2021-05-23 20:06:16 its just not on the market 2021-05-23 20:06:37 i am curious about loongarch though 2021-05-23 20:06:47 like riscv, they are doing a qemu-first approach 2021-05-23 20:06:54 with qemu acting as an officially blessed simulator 2021-05-23 20:07:10 though i don't think i am interested in doing a loongarch port 2021-05-23 20:07:52 Ariadne: does it still make sense to have a mips64 alpine release? 2021-05-23 20:08:08 i would like to 2021-05-23 20:08:29 there are some people using it outside of what my previous employer was doing with it 2021-05-23 20:08:34 ok 2021-05-23 20:08:37 so it's used 2021-05-23 20:08:38 seems kinda like a dick move to just drop it 2021-05-23 20:08:52 only reason i supported that for ppc64le was because IBM was giving us the runaround ;) 2021-05-23 20:12:16 Ariadne: so openrc-qemu installs binfmt, and then you can run a container for that arch? 2021-05-23 20:13:13 if binfmt is installed and set properly nothing else not needed, iirc 2021-05-23 20:13:30 but long time passed I did that last time, so not sure 2021-05-23 20:13:35 ikke: yes 2021-05-23 20:14:40 for example, on my desktop (aarch64 honeycomb), i have LXCs for every arch supported by alpine 2021-05-23 20:14:47 and you can just lxc-attach to them 2021-05-23 20:14:49 like any other 2021-05-23 20:14:51 works fine 2021-05-23 20:14:52 :) 2021-05-23 20:15:22 and because of the work the riscv64 people have done on qemu-user 2021-05-23 20:15:23 what has openrc-qemu to do with this? 2021-05-23 20:15:43 clandmeter: it includes the qemu-binfmt service 2021-05-23 20:15:52 if you start that service 2021-05-23 20:15:58 it will look for qemu-user binaries 2021-05-23 20:16:01 and set up the binfmt 2021-05-23 20:16:05 with fixate mode 2021-05-23 20:16:11 so you don't have to copy qemu-user into the container 2021-05-23 20:16:26 doesnt qemu ship a helper script? 2021-05-23 20:16:33 no idea 2021-05-23 20:16:41 i use the qemu-openrc one 2021-05-23 20:16:44 its cleaner 2021-05-23 20:16:51 it makes sure the binfmt is always set up at boot 2021-05-23 20:16:56 you dont know but its cleaner? :) 2021-05-23 20:17:13 i meant in terms of how it integrates into my setup 2021-05-23 20:17:27 running some helper script by hand is not something i want to do 2021-05-23 20:18:04 clandmeter: and, no idea if it is qemu upstream or if everyone is just copying debian's :p 2021-05-23 20:19:28 anyway, the qemu-openrc's qemu-binfmt service is just the helper script adapted to run under openrc 2021-05-23 20:19:35 https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh 2021-05-23 20:19:35 use it or don't 2021-05-23 20:19:47 yeah 2021-05-23 20:19:50 well 2021-05-23 20:19:56 i didn't know if that was upstream or not :p 2021-05-23 20:20:02 debian has some script written in perl 2021-05-23 20:20:05 that's also what fedora uses 2021-05-23 20:21:12 ok so that qemu openrc file is this file converted into openrc (kind of) 2021-05-23 20:21:31 same data 2021-05-23 20:21:40 https://github.com/jirutka/qemu-openrc/blob/master/qemu-binfmt.initd 2021-05-23 20:21:54 atleast the flags are correct 2021-05-23 20:21:59 this gave me some issues before 2021-05-23 20:22:43 yes 2021-05-23 20:22:44 i fixed it 2021-05-23 20:22:47 in alpine 3.12 :p 2021-05-23 20:23:20 And how do we get an lxc alpine template for a new arch? 2021-05-23 20:23:36 glad you asked 2021-05-23 20:23:47 the answer is: you don't 2021-05-23 20:23:56 what you do, is 2021-05-23 20:24:00 i think you can just use a rootfs 2021-05-23 20:24:02 lxc-create -t none -n blahblah 2021-05-23 20:24:05 and then use rootfs yeah 2021-05-23 20:24:30 so i think the next step 2021-05-23 20:24:32 ok, copy the rootfs to /var/lib/lxc/ yes 2021-05-23 20:24:38 precisely 2021-05-23 20:24:52 in the mips bootstrap case 2021-05-23 20:24:54 what i did was 2021-05-23 20:24:54 maybe you need to do some magic 2021-05-23 20:24:58 i created an x86 rootfs 2021-05-23 20:25:02 and then i replaced that 2021-05-23 20:25:07 with the mips64 one 2021-05-23 20:25:12 but kept all the other lxc stuff 2021-05-23 20:25:21 thats what the templates do, add some sugar on top of rootfs. 2021-05-23 20:25:24 worked well enough 2021-05-23 20:25:39 kinda janky but it would work with riscv64 i think 2021-05-23 20:25:54 what kind of sugar? 2021-05-23 20:26:06 it works in docker, so why not on lxc :) 2021-05-23 20:26:08 that /var/lib/lxc//config 2021-05-23 20:26:16 s/that/the/ 2021-05-23 20:26:16 Ariadne meant to say: the /var/lib/lxc//config 2021-05-23 20:26:26 ikke: check the template 2021-05-23 20:26:37 not sure, probably some networking and such? 2021-05-23 20:27:16 mostly network, but also mountpoints 2021-05-23 20:27:27 maybe some services get added 2021-05-23 20:29:25 lxc.arch, lxc.include = /usr/share/lxc/config/alpine.common.conf, and rest 2021-05-23 20:29:31 yep 2021-05-23 20:30:14 I always create lxcs 'by hand' 2021-05-23 21:55:51 What Ariadne said ;-) // I am back['ish] ;-) 2021-05-24 07:17:54 ppc64le CI have problems again 2021-05-25 07:51:59 good morning 2021-05-25 07:52:04 (problem solved) 2021-05-25 07:54:41 :) 2021-05-25 11:44:26 apparently docker-compose can be called through the docker-cli 2021-05-25 11:44:33 docker compose version 2021-05-25 12:41:34 i wonder what the future of docker is compared to podman for instance. 2021-05-25 13:46:41 with a backer like ibm/redhat it feels like an uncertain future, especially considering how aggressively they've marketed and pushed docker 2021-05-25 13:47:05 you can no longer run docker on RHEL without screwing around *a lot*, I had to fiddle around on Fedora 32/33 too 2021-05-25 13:47:33 at least it's easier for fedora, many of those who run RHEL do it for the perceived stability and support from RH 2021-05-25 13:47:38 including my org 2021-05-25 13:53:41 with or without a backer like RH/IBM? 2021-05-25 17:24:38 ikke: when podman/buildah and friends have RH/IBM as a backer, the future for Docker feels uncertain 2021-05-25 17:25:30 ah, like that 2021-05-25 17:28:33 Sadly you cannot run podman / buildah in an unpriliged docker container 2021-05-26 00:41:16 uhhhhhhh 2021-05-26 00:41:19 ok 2021-05-26 00:42:33 looks like a network maintenance at linode has gone south 2021-05-26 00:42:41 hugs for blaboon 2021-05-26 01:14:19 we're working on it :) 2021-05-26 01:14:23 should be coming back up soonβ„’ 2021-05-26 06:54:17 get "no space left on device" on the s390x builder 2021-05-26 06:54:29 https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/vault/vault-1.7.2-r0.log 2021-05-26 07:43:57 HRio: checking 2021-05-26 07:56:00 i have a feeling this disk is not the fastest 2021-05-26 07:57:45 ikke: can i delete the cept build src? 2021-05-26 07:57:49 ceph 2021-05-26 07:59:09 i just deleted it :) 2021-05-26 07:59:38 HRio: storage is almost full, but it has some space now 2021-05-26 08:45:22 ok 2021-05-26 08:45:26 thanks 2021-05-26 08:46:41 possible to tell algitbot to only retry master and 3.14 for s390x? 2021-05-26 08:46:55 No 2021-05-26 08:47:10 But it doesn't matter a lot 2021-05-26 08:48:50 ah vault was already built OK, on earlier retry. Now the build is only missing for ppc64le 2021-05-26 08:49:39 and that was just uploaded according to algitbot, so lets hope its part of that upload 2021-05-26 08:50:41 looks like https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/vault/vault-1.7.2-r0.log 2021-05-26 08:51:01 clandmeter: thanks again for your help. 2021-05-26 10:28:19 s390x still out of space 2021-05-26 10:35:09 did it build ceph again? 2021-05-26 10:35:55 src exists, so I assume so 2021-05-26 10:37:10 oh, src is empty 2021-05-26 10:37:19 so, no 2021-05-26 13:36:57 i read that other projects got their freenode channel hijacked, maybe i should ask the feenode staff to hijack the #alpine-* channels? 2021-05-26 13:37:15 would speed up the move to OFTC :) 2021-05-26 13:37:30 ncopa: just mention Liberia in the topic 2021-05-26 13:37:38 Lebera* 2021-05-26 13:37:45 Ugh 2021-05-26 13:38:26 so maybe we should change it to: "we did not move to libera.chat, we moved to irc.oftc.net" :) 2021-05-26 13:38:42 Yes, exactly! 2021-05-26 13:38:46 ye... https://www.gentoo.org/news/2021/05/26/gentoo-freenode-channels-hijacked.html 2021-05-26 13:39:14 same appeared to happen with void and musl https://voidlinux.org/news/2021/05/freenode-takeover.html 2021-05-26 13:39:23 I set all channels to +m btw 2021-05-26 13:39:37 ikke: yes i left src to let it skip 2021-05-26 13:39:37 On freenode 2021-05-26 13:39:48 that host does not seem healty 2021-05-26 13:39:53 lots of issues in dmesg 2021-05-26 13:40:04 s390x? 2021-05-26 13:40:09 nod 2021-05-28 07:10:45 ikke: seems that old amd epyc box keeps on going. 2021-05-28 07:11:35 ikke: nld9 is yours? i cannot login to it. 2021-05-28 07:19:14 Yes 2021-05-28 07:19:55 nld8/9 are the x86(_64) builders 2021-05-28 07:22:27 ok then i back off :) 2021-05-28 07:22:37 let you do that cleaning 2021-05-28 10:06:13 I've made some space again 2021-05-28 10:06:19 mainly be deleting logs older than 2m 2021-05-28 10:08:33 i thikn for edge logs we can delete older than 7 days 2021-05-28 10:08:51 for stable we should probably keep longer 2021-05-28 10:09:07 We can also cleanup a lot of edge destfiles 2021-05-28 10:31:29 nice, 38G space saved by rdfind 2021-05-28 10:31:38 Totally, 38 GiB can be reduced. 2021-05-28 10:58:58 So anoying, for some reason our ppc64le builders cannot reach httpbin 2021-05-28 10:59:02 just no response 2021-05-28 10:59:55 https://tpaste.us/ZEb9 2021-05-28 17:37:52 wtf 2021-05-28 17:37:55 is gitlab down again 2021-05-28 17:38:27 oh there it goes 2021-05-28 17:38:33 must be my meme internet 2021-05-28 17:40:16 https://imgur.com/a/VKaXFOI 2021-05-28 17:40:44 hmm, imgur is doing stupid 2021-05-28 18:13:37 and ofcourse, s390x CI host cannot reach 1.1.1.1 πŸ€” 2021-05-29 07:04:25 clandmeter: ^ 2021-05-29 07:04:34 usa5 crashed, I guess? 2021-05-29 07:14:46 hmm, no 2021-05-29 07:45:58 ikke: what was it 2021-05-29 07:47:09 clandmeter: Not sure why, zabbix pinged 172.16.9.1, which for some reason is suddenly not reachable anymore 2021-05-29 14:19:57 whats the current state of the s390x builder? 2021-05-29 14:21:11 In what sense? 2021-05-29 14:21:40 https://tpaste.us/N8Nq 2021-05-29 14:22:09 These messages are shown often in dmesg 2021-05-29 14:59:38 weird 2021-05-29 15:01:14 ikke: i mean, is it still out of disk space 2021-05-29 16:14:30 /var was indeed full 2021-05-29 16:14:34 I should add monitoring 2021-05-29 18:25:45 I have upgraded zabbix to 5.4 :) 2021-05-29 18:26:09 neat, what minor version did the UI have a major change in? 2021-05-29 18:26:34 Not sure what major change you are refering to 2021-05-29 18:26:52 it was redesigned in some version, can't remember which one 2021-05-29 18:26:56 there have been multiple iterative improvements 2021-05-29 18:27:40 3.0 I guess 2021-05-29 18:27:42 https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300 2021-05-29 18:28:30 hmm, it must have been the 4.4 to 5.0 bump i am thinking of, must've been mistaken 2021-05-29 18:28:56 That was not that big if an interface change 2021-05-29 18:29:13 The vertical menu was introduced then, though 2021-05-29 18:31:36 5.4 comes with a new trigger syntax 2021-05-29 18:33:58 from 4.4 to 5.0 there was a new layout in general, new side menu, changes to visualization, and a bunch of unrelated changes 2021-05-29 18:34:05 and i see, is the old one still supported? 2021-05-29 18:34:13 No 2021-05-29 18:34:24 They migrate everything 2021-05-29 18:34:26 I see 2021-05-29 18:34:43 https://www.zabbix.com/documentation/current/manual/introduction/whatsnew540#new_expression_syntax_for_triggers_and_calculated_items 2021-05-29 18:34:55 Also support for API tokens 2021-05-30 08:49:45 really strange, from one of the ppc64le hosts: curl http://httpbin.org hangs, curl http://httpbin.org/headers works, curl https://httbin.org/{,headers} hangs 2021-05-30 08:52:58 I have a tcpdump, trying to make sense of it 2021-05-30 08:53:51 ikke, is gnu curl o busybox curl? 2021-05-30 08:54:03 curl is not gnu :) 2021-05-30 08:54:23 is whatever/curl or busybox curl? :D 2021-05-30 08:54:35 afaik bb does not provide curl 2021-05-30 08:54:44 so curl proper 2021-05-30 08:54:59 ikke, sorry i typed curl but I was thinking to wget 2021-05-30 08:55:18 I had the suspicion :) 2021-05-30 08:55:32 :) 2021-05-30 08:56:10 ah ok this happens only for ppc64le 2021-05-30 08:56:26 yes 2021-05-30 08:56:36 and both ubuntu (the host) as alpine linux 2021-05-30 08:56:51 with wget works? 2021-05-30 08:57:26 same with wget 2021-05-30 08:57:56 It was a test suite for a go program that has this issue 2021-05-30 08:58:01 might be something related to certificate then 2021-05-30 08:58:17 curl http://httbin.org hangs as well 2021-05-30 09:01:03 curl --verbose --trace-ascii ? 2021-05-30 09:03:46 just verbose shows that we do get headers back, but not the body 2021-05-30 09:03:55 perhaps MTU issue? 2021-05-30 09:04:32 check mtu -d httpbin.org 2021-05-30 09:05:07 sadly icmp is blocked 2021-05-30 09:05:30 /0\ 2021-05-30 09:05:49 it's something hosted on aws 2021-05-30 09:08:49 yes 2021-05-30 09:08:51 it's mtu 2021-05-30 09:09:23 ip l set dev ibmveth2 mtu 1200 2021-05-30 09:09:32 yeah the behavior looked like that 2021-05-30 09:09:58 heh, pmtu doesn't work 2021-05-30 09:10:03 which router mess up with pmtu? 2021-05-30 09:10:26 routers, firewalls 2021-05-30 09:10:30 mtu -d allows you to follow the pmtu and find the blackhole router 2021-05-30 09:10:45 unless icmp is blocked and you do not get any feedback 2021-05-30 09:11:05 which is *bad*, block all icmp types 2021-05-30 09:11:10 agreed 2021-05-30 09:11:46 if you can enable icmp on that host and run mtu -d, then you'll be able to find the router blocking pmtu... 2021-05-30 09:12:10 or go ahead with traceroute and ping :D 2021-05-30 09:12:21 mtu is 1476 2021-05-30 09:12:31 fcolista: issue is on the destination 2021-05-30 09:12:41 ah ok so last one 2021-05-30 09:13:09 so anybody should have this problem? 2021-05-30 09:13:42 I guess anyone where MTU <1500? 2021-05-30 09:14:49 and something must have do not fragment set 2021-05-30 09:14:56 for ipv4 2021-05-30 09:15:42 fcolista: thanks for helping 2021-05-30 09:15:57 ikke, thx to you 2021-05-30 09:16:13 just helps to have someone to talk to :) 2021-05-30 09:16:34 :) 2021-05-30 09:21:26 heh, httpbin.org/anything can be used as 'ping' 2021-05-30 19:42:32 dotsrc.org can spam [problem] for a while if their "HP D2600 disk enclosures" died... https://dotsrc.org/news/kvaser_crashed/ 2021-05-30 19:42:52 MY-R: thanks 2021-05-30 19:42:59 I already changed it to be less spammy 2021-05-30 19:43:30 :) 2021-05-30 20:00:00 the HPE D2600 was EOL at the end of 2015 so no wonder it crashed and burned :P 2021-05-30 20:12:38 danieli: ^ good old devices, reboot always help :P 2021-05-30 20:20:35 except when they decide they're going to fry some important and hard-to-find components 2021-05-31 20:01:08 it looks like xmas hee 2021-05-31 20:01:11 here 2021-05-31 20:01:46 all these mirrors 2021-05-31 20:04:16 most are our servers today 2021-05-31 20:04:21 i just fixed a few i think