Re: [arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs
On Tue, Aug 25, 2020 at 04:46:36PM -0400, Public mailing list for Arch Linux development wrote: > On Tue, 25 Aug 2020 at 15:58:40, Evangelos Foutras via arch-dev-public wrote: > > I am not sure these serve any purpose. The maintainer line duplicates > > information available from the archweb or aur interfaces and could > > also be outdated. The contributor lines are mostly redundant with svn > > or git history, can take up several lines in the PKGBUILD and can > > become irrelevant after significant refactoring. > > > > What are your thoughts on dropping all these seemingly unnecessary > > lines from our official PKGBUILDs? Anyone feel strongly about keeping > > them (and why)? > > I don't feel strongly and would welcome a better system. > > One of the reasons against such a change that was brought in earlier > conversations around this topic is that original contributors are hard > to reconstruct after a package has been moved from the AUR to the > official repositories or vice versa. Lukas' opinion pretty much reflects my opinion. I just want to add, that other distributions use our PKGBUILDs (Manjaro, ALARM, etc). Having a contributor/maintainer history is the least thing, people can do to 'honor' work related to PKGBUILDs. Maintainer/Contributor lines are also interesting with respect to licensing. This is a difficult topic with no clear answer. Smaller PKGBUILDs are somewhat trivial, but what about bigger ones? I would really like to further read my name in a PKGBUILD in foreign repos like Manjaro, If I have invested hours of work into it (the vault PKGBUILD is one of these examples). Chris signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Wed, May 13, 2020 at 10:16:38PM +0200, Public mailing list for Arch Linux development wrote: > Yo! > > After another few lazy weeks I have finished up the new Go packaging > guidelines. > > https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines#Flags_and_build_options > > The changes that has been done since last time is some structing of the page, > added a list explaining all the flags that have been added to `GOFLAGS`, and > the > addition of `-mod=readonly`. > > The intention of adding this flag is to prevent Makefiles or build systems to > silently modify the lockfile of the source code after checkout. This is > to ensure reproducible build. > > If there are no objections, I'll probably merge the guidelines this weekend > section-by-section to make the wiki admins happy. The new package should land > sometime nextweek. > > At the end of the month I'll make a todo with the remaining packages depending > on `go-pie`. > > The complete future Go PKGBUILD is attached to this email below. > > -- > Morten Linderud > PGP: 9C02FF419FECBE16 Awesome! Thank you so much for your effort Morten. Chris signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Mon, Apr 20, 2020 at 12:32:18AM +0200, Public mailing list for Arch Linux development wrote: > I have also removed `-mod=vendor` from the default listing in `prepare()` as > Anatol wasn't fond of the idea. I'm still unsure if we really want this as we > would be willynilly downloading sources in `build()` and `check()` during > packaging. Opinions welcome. Hi, I think we should use `-mod=vendor`, It's bad practice to download sources in `build()` and/or `check()`. A build should work in isolation. Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Founding an Arch-releng team
On Sat, Mar 28, 2020 at 02:11:02PM +0100, David Runge wrote: > On 2019-11-11 09:40:14 (-0300), Giancarlo Razzolini via arch-dev-public wrote: > > But, we still don't have anyone wanting to become the actual > > maintainer of archiso to help implement these changes. > > I'd be up for it. I have some ideas around certain possible test > scenarios in regards to packer and ansible already. > > What is currently still unclear to me is how the archiso and bootstrap > images on our download page are exactly generated from archiso (the > actual specific calls) and whether a semi-automated way of doing that > exists (I guess this question is aimed towards Pierre). > > I would like to automate this as far as possible and make this more > transparent when maintaining archiso. > > How do we go on from here? > > Best, > David > > -- > https://sleepmap.de Hi, just a general idea, but wouldn't it make sense to revive the arch-releng mailing list a bit + found a release engineering team? We got a few additions to our monthly releases: * Arch Linux Docker * Arch Linux Vagrant Boxes * Arch Linux Cloud Images (soon) * Arch Linux Tarball Would be cool, if we could manage to revive the #archlinux-releng channel on freenode, revive the mailing list and maybe even have weekly meetings, like the devops team has. Just my 2 cents, chris signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Sun, Mar 15, 2020 at 12:09:07PM -0700, Public mailing list for Arch Linux development wrote: > Hello Morten > > On Sun, Mar 15, 2020 at 5:38 AM Morten Linderud via arch-dev-public > wrote: > > > > > > # Introduction > > > > To enable PIE compilation, we have relied on a patched version of the go > > compiler which has been distributed as `go-pie` since around 2017. However, > > full > > RELRO support for go binaries has been a bit back and forth the past years. > > With > > some thing working, and other things don't. > > > > With the release of Go 1.11 there was support for a general `GOFLAGS` > > variable > > that lets us pass flags directly to the compiler. This email details what > > these > > flags should be going forward. > > Big +1 for removing go-pie in favor of using GOFLAGS. It makes the > go-based packages management more straightforward and cleaner. +1 from me to for this step. > > # Flags > > > > Expected environment variables in PKGBUILDs: > > > > export CGO_LDFLAGS="$LDFLAGS" > > export GOFLAGS="-buildmode=pie -trimpath -mod=vendor -modcacherw" > > > > > > Explanation: > > > > * `CGO_LDFLAGS` passes the proper `LDFLAGS` to the linker. This should > > enable > > full RELRO when used in conjunction with `GOFLAGS`. > > > > * `-buildmode=pie` is the proper way to enable PIE and replaces the `go-pie` > > patch. > > > > * `-trimpath` this is to achieve reproducible builds and remove PWD from the > > binary. > > > > * `-modcacherw` modules are downloaded to `$GOPATH/pkg/mod` and by default > > have > > the permissions 444 for god knows why. If we want to run `makepkg -c` or > > `git > > clean` we won't have the correct permissions. This is probably not a big > > problem for repository packages, but it's a nice addition so they work as > > expected. > > > > Notice that `-mod=vendor` is also added to `GOFLAGS`. > > Most of the Go projects do not vendorize their dependencies to avoid > polluting the source tree. > > And there is no point to force vendorizing in the PKGBUILD neither. go > modules are doing a great job with pinning dependencies to a specific > version thus eliminating the main reason for vendor'ization existence > (i.e. reproducible builds). > > Thus following YAGNI principle I propose to drop this "-mod=vendor" flag. > Correct me if I am wrong, but wouldn't that mean that, if you have a package with vendor directory you would download the same content twice? Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)
On Thu, Feb 27, 2020 at 10:11:24AM +0100, Public mailing list for Arch Linux development wrote: > PS. If unmaintained orphans in [core] could be moved to [extra], and > unmaintained orphans in [extra] could be moved to [community], that could > be a nice "trickle down" effect and would be an appreciated cleanup as > well, but that is just my opinion. Wouldn't it make more sense to move from [core]/[extra] to [community] instead of moving from [core] to [extra] to [community]. The group of possible maintainers is constant for a move of [core] to [extra] and I don't think, that such a repository change is helpful. The package will just decay for another year before it will get exposed to a new group of possible maintainers. Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Todos for language specific rebuilds
On Sat, Jan 11, 2020 at 09:57:42AM -0500, Dave Reisner wrote: >On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public ><[1]arch-dev-public@archlinux.org> wrote: > > Hi everybody, > I would like to propose that we create todos for rebuilds of > language > specific packages. > We had two major rebuilds in the last months: python3.8 and ruby2.7. > Can we agree that we create a todo before such rebuilds? > The advantages outweigh the disadvantages. We would gain: > >Hi, >I'm not sure I understand. Can you clearly state the problems we've >encountered due to not doing this? What downsides do you see to your >proposal? Can you think of any alternative solutions? Hi Dave, I am sorry. Looks like my actual proposal was a little bit unclear and the whole discussion drifted to automation. This has been never my intention. I have no problem with the actual rebuild process and I don't care if this happens manually or automated. Actually I didn't want to point out specific package problems, but you asked me, here they are. My problem is that several packages dependending on ruby broke due to the ruby2.7 rebuild: * puppet5 broke due to missing ruby-sync in ruby2.7[1] * puppet broke due to missing ruby-sync in ruby2.7[2] * gitlab has problems with its API after ruby2.7 rebuild[3] Furthermore multiple packages are throwing deprecation warnings now: * gitlab[4] * puppet5/puppet [1][2] * vagrant has issues with the ruby2.7 rebuild[5] Big thanks to Anatol for reporting several of these issues upstream and fixing packages. I really appreciate his work. The rebuild process itself is totally fine for me. I just wanted to point out, that we should have a defined process for rebuilds. Either in form of todos or in form of more communication on a-d-p like "We are going to push all ruby rebuilds from [testing] to [community] on date X. Make sure it's tested, if you encounter any problems, speak with A, B or C or response directly in this thread". > * More people help rebuilding the packages. > >Solving the wrong problem, IMO. This is largely toil and should be >automated away. Foutrelis already has such a system that we've used for >rebuilds in the past. We could/should instead work towards making this >more generally available on the build machines. I agree. > > * Every maintainer gets informed about the rebuild. > >As a maintainer, I don't care that you're rebuilding my package to keep >up with library changes. Rather, I'm thankful to whomever did this for >me. >Why would a language rebuild differ from any other soname bump? I mostly agree, still would be nice to get a notification. > > * Maintainers have the possibility to test the packages. > >Why is this not currently possible? Couldn't we just use testing prior >to pushing out to the repos (something we've done in the past and >continue to do)? What about packages which aren't using the lowlevel >API and are simply interpreted code. Those don't get rebuilt, but >they're potentially impacted by the language version bump. They'll >never be called out on a rebuild lost because we generate those based >on ELF dependencies. >dR > [testing] has been used and I wanted to test my packages, but the push from [testing] to [community] happened before my scheduled date for this. I just say that it would be nice if we have a defined process for rebuilds with specifying a deadline for tests. My hope is that this mail makes my intention clear now. The "proposal" is just a spawn point for a discussion around a defined process for rebuilds to prevent not working packages in the future. Arch Linux is known for bleeding edge software _and_ stability, let's keep it this way. [1] https://bugs.archlinux.org/task/65106 [2] https://bugs.archlinux.org/task/65107 [3] https://bugs.archlinux.org/task/65097 [4] https://bugs.archlinux.org/task/64887#comment185125 [5] https://github.com/hashicorp/vagrant/issues/11290 signature.asc Description: PGP signature
[arch-dev-public] Todos for language specific rebuilds
Hi everybody, I would like to propose that we create todos for rebuilds of language specific packages. We had two major rebuilds in the last months: python3.8 and ruby2.7. Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain: * More people help rebuilding the packages. * Every maintainer gets informed about the rebuild. * Maintainers have the possibility to test the packages. If tools exist for creating todos, I would like to ask the persons with such tools to make them available for everybody (if not already happened). Greetings, shibumi signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On Thu, Dec 12, 2019 at 01:40:19PM +0100, Public mailing list for Arch Linux development wrote: > On 12/12/19 1:21 PM, Christian Rebischke via arch-dev-public wrote: > > 8.2 I can't find any list about punishments for violations of these > > rules. > > > > Best regards, > > Chris > > > > Do we have such lists of punishment in any of our other guidelines? > > I think we generally assume that other team members are acting in good faith, > if someone is doing something by mistake - point them towards it and I'm sure > you can figure it out. > All without threatening someone with /punishments/. > > -- > Rob (coderobe) > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > This is indeed an argument, although it's difficult to differ between a mistake and a "mistake". If you get what I mean. Chris signature.asc Description: PGP signature
[arch-dev-public] Proposal: Build a ruleset for new packages and package quality
Hello everybody, Due to a longer discussion around alpha and beta packages in our repositories in IRC yesterday, I would like to start a hopefully more constructive discussion around this topic on the ML. Short summary for everybody what happened: I wanted to get caddy2.0.0-beta into [community], people started discussing that we don't ship betas in our repositories and I should either wait or ship the stable caddy v1 release. I don't want to start this discussion around caddy again (I will wait for a stable release). What I want to accomplish with this mail is: 1. find a consensus on rules which packages we allow in our repositories and which don't. 2. find a consensus on rules on violating our rules regarding package requirements. (e.g. What happens when TU/Dev XY violates our package requirements? what is the punishment?) 3. revive the discussion around better PKGBUILD quality (see also Eli's thread about PKGBUILD quality on arch-tu: https://lists.archlinux.org/private/arch-tu/2019-November/83.html) 4. I would like to have this rules written down somewhere, either in the TU bylaws (in dev bylaws if this exists) or in a new format like "community bylaws" (maybe we could combine this with the question about a new leader). 5. What do we do with the existing beta and alpha packages? Are they granted asylum? Or do we remove them, to be consistent? extra libmspack 1:0.10.1alpha-2 extra qt5-webkit 5.212.0alpha3-6 community d-containers 0.8.0alpha.19-1 extra frozen-bubble 2.2.1beta1-14 extra hddtemp 0.3.beta15.53-1 extra libcaca 0.99.beta19-2 extra tsocks 1.8beta5-8 community hydrogen 1.0.0beta1-1 community lablgtk3 3.0.beta6-2 community modclean 3.0.0beta.1-1 community sdedit 4.2beta8-1 community sniffit 0.3.7.beta-17 community vbindiff 3.0_beta5-1 community wqy-microhei 0.2.0_beta-9 community wqy-microhei-lite 0.2.0_beta-9 6. How do we define stable packages? beta or alpha is just a human made word. I've seen devs who said their "1.0" version is unstable and shouldn't be used in production. Should such a software get packaged? And what about projects who use semantic versioning (the devs said so), but they have a 0.* prefix release? 7. Another topic is a rule about "touching packages of others". In the #archlinux-tu channel we came to the conclusion that TUs or devs should ask the package maintainer before touching another devs/TUs package, how do we want to handle this? Is this the consensus, or are touches without prior question allowed? What do we do if somebody violates our rules? etc 8. A few guys in the IRC pointed me to this guidelines in our wiki: Note: This page is only editable with Wiki-Admin/Dev Permission. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning My questions to this guidelines: 8.1. under which consensus where this rules defined? Are these rules the result of a developer vote? of a leader decision? Or are they made up by a few persons without consensus. 8.2 I can't find any list about punishments for violations of these rules. 8.3 There is no documentation about our alpha and beta packages. I see that there are exceptions for alpha and betas, but it's not clear for me how these exceptions apply to the packages we have in our repositories. This needs to be documented, otherwise every person could push an alpha package and just 'claim' that one of those exceptions apply for the package and if nobody checks this claim, the package will be in the repository. 9. Do we consider packages, that are build from the latest git tag, as alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g' 10. Do we need to ask software developers in the future if they consider their project stable? It's not clear which versioning schema the devs use, some consider their 0.1 release as unstable, some consider it as stable. Is semantic versioning applied? Do they follow a different schema? 11. What do we do when a package is stable, but the API is unstable? Is the whole package considered unstable? The current guidelines are not clear about APIs, but many users use Arch Linux for software development and maybe rely on stable APIs. Disclaimer: I don't know how we want to find concensus yet (TUs have a transparent vote process, but devs don't have an equivalent for this), therefore I hope for a "final decision" of our still-leader aaron. This topic doesn't need to be decided this year. I am fine with reviving this thread in January or late replies in January. Best regards, Chris signature.asc Description: PGP signature
[arch-dev-public] Dropping OpenVAS/GVM
Hi, I plan to drop the vulnerability management tool "openvas" (Greenbone Vulnerability Manager). I stopped using the software and it gets more and more tedious (due to breaking changes and bad testing at upstream). Moreover I really think that there are better solutions right now (for example cloudflare/flan) Anyone interested in adopting it? Best regards, chris signature.asc Description: PGP signature
Re: [arch-dev-public] Looking for an Arch ISO maintainer
On Fri, Nov 08, 2019 at 10:22:44AM +0100, Jelle van der Waa wrote: > Hi all, > > Gerardo has stepped down as Arch ISO maintainer, which makes archiso > unmaintained. I've asked Pierres if he was interested in maintaining > the project and he is willing to do bug fixes when required but no major > maintenance. Which means that we are looking for a new maintainer :-) > > To be completely honest, I am not sure what maintenance archiso requires > but there are a few things I would love to see: > > - Proper CI / automated testing of the archiso > - Reproducible archiso (patches on the mailing list) [1] > - Support secure boot [2] > - Accessibility improvements (patches available on the mailing list) [3] > > Please reply if you are interested in becoming an archiso maintainer, so > far Alad has shown interested. > > > [1] https://bugs.archlinux.org/task/63683?project=6 > [2] https://bugs.archlinux.org/task/53864?project=6 > [3] https://bugs.archlinux.org/task/63166?project=6 > > -- > Jelle van der Waa Hi, Arch-boxes and cloud images rely on the ISO. So I would be interested as well and would definitely help out with automating/testing. chris signature.asc Description: PGP signature
Re: [arch-dev-public] New ideas for notifying users about (minor) changes
On Tue, Jul 30, 2019 at 10:16:17AM +1000, Allan McRae wrote: > On 30/7/19 8:47 am, Christian Rebischke via arch-dev-public wrote: > > Hello everybody, > > I got assigned to this issue here: > > > > https://bugs.archlinux.org/task/62823 > > > > The users would like to have a notice in pre/post install/upgrade > > notifications via pacman .install files. > > > > I am not a fan of spamming such news via pacman and I think the > > installation/upgrade process should be clean of such messages, but I > > don't have access to the news tool on our website as well. > > I think this is a clear case of user intervention needed. So a > post_install message (restricted to the update where intervention was > needed) is appropriate. > > If the package was more widely used, we have the News section of the > website. > > I don't think anything else is needed. > > Allan One problem I see with the News section is that it's Dev only. I wouldn't even know who I need to ask (and I am TU for several years now). I mean I could just ask around in the IRC, but it would be nice to have this at least documented somewhere. Another question is how fast this will happen.. you will always have a delay if you need to forward the message to another person first before publishing it. I guess I will stick with post_upgrade messages for strongswan, thanks. And I will definitely have a look at this changelog feature (either as news replacement or for providing the actual changelog of the software). signature.asc Description: PGP signature
Re: [arch-dev-public] New ideas for notifying users about (minor) changes
> We already have this feature. > > Add the following to the PKGBUILD, and rebuild it: > > changelog=NEWS > > Now, the user may at any time run the following command for an installed > package: > > $ pacman -Qc pkgname > Changelog for pkgname: > [contents of NEWS file] > > Changelogs are pacman's #1 unused feature. Do note, however, that these > messages are opt-in and thus users won't see them unless they know they > need to. As such, it makes sense for a "changelog", but its utility as a > news bulletin may be in doubt. Ah ok cool. You didn't mention that `pacman -Qc` part when we talked about it in the IRC. One problem what I see with `pacman -Qc` is that we would still need a wrapper for it, because I don't want to trigger `pacman -Qc` for every package on my machine manually (or with some bash magic.. I know it's a one liner). And I guess it will always print the whole changelog, correct? The name changelog is irritating as well, atleast I wouldn't expect minor news in there. > People should already use decent commit messages. But we should *not* > abuse them to contain information that is not about what the commit did, > but instead about how users should respond to the new package release. > > That duplicates the functionality of a changelog without offering a > compelling use case that it would be better at. It additionally makes > commit messages *worse* at effectively doing the job of a commit message. Good points. Another question: How can we enforce better commit messages? This could be a nice question for the next Arch Linux Meetup, to discuss. > That duplicates the functionality of a changelog without offering a > compelling use case that it would be better at. The only thing that > would be possible with this, that a changelog cannot do, is tell you > about the news for a package you don't have installed, but I assume you > don't actually care about that. Yep, I think so as well. > I do not thing we need such a tool, and if we had one, I would refuse to > use it -- instead opting to use the changelog feature. > > I would still use post_upgrade messages that use vercmp to make sure > they run exactly once, to alert users to important issues surrounding a > new release that I do not want them to accidentally miss. My problem with post_upgrade messages is that it's difficult to differ between 'breaking notifications' and 'documentations'. If you have a look into the AUR you will see tons of packages that use the install files as installation documentation (this is exactly the opposite what I want). Furthermore if everybody would use such post_upgrade messages, we would get spammed with it.. If we use them rarely, they are fine, but for everything bigger they are the wrong solution, imho. signature.asc Description: PGP signature
Re: [arch-dev-public] New ideas for notifying users about (minor) changes
On Mon, Jul 29, 2019 at 07:36:31PM -0400, Public mailing list for Arch Linux development wrote: > On Mon, 29 Jul 2019 at 18:47:44, Christian Rebischke via arch-dev-public > wrote: > > So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. > > It would be super awesome if we would have a tool such like `archnews > > ` to retrieve NEWS about a certain package from an > > endpoint. This endpoint should be controllable by every maintainer (devs > > and TUs included). I discussed this with coderobe a bit and we came to > > different solutions: > > > > > > Solution 1: a NEWS file inside of the package repository: > > > > [...] > > Solution 2: commit messages as NEWS > > > > [...] > > Solution 3: A webapp on news.archlinux.org with a fancy UI > > --- > > If we decide to do this, why don't we simply add a file to the package? > It's simple, works offline, and always gives you the right version of > the news for your system. good point, I guess this would be solution number 4. signature.asc Description: PGP signature
[arch-dev-public] New ideas for notifying users about (minor) changes
Hello everybody, I got assigned to this issue here: https://bugs.archlinux.org/task/62823 The users would like to have a notice in pre/post install/upgrade notifications via pacman .install files. I am not a fan of spamming such news via pacman and I think the installation/upgrade process should be clean of such messages, but I don't have access to the news tool on our website as well. So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. It would be super awesome if we would have a tool such like `archnews ` to retrieve NEWS about a certain package from an endpoint. This endpoint should be controllable by every maintainer (devs and TUs included). I discussed this with coderobe a bit and we came to different solutions: Solution 1: a NEWS file inside of the package repository: A maintainer could upload a `NEWS` file into the package repository and then a client could grab this information directly via downloading the file from: https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=packages/0ad Pro: + every maintainer could control this NEWS file easily via our current tools. + It's easy to download the NEWS files (we can expect new tools from the community) Con: - We bloat our repository Solution 2: commit messages as NEWS The maintainer could/should put such news into the latest commit message. Pro: + no extra file + using existing infrastructure + one workflow Con: - I need an actual change in the repository to create a new NEWS object (If we have a look on my example with strongswan, I would need to add something in the PKGBUILD to make a new commit to make a new NEWS object) - It's more difficult to get with tools. The user needs to checkout the repository (in solution 1 it can be just a curl call) Solution 3: A webapp on news.archlinux.org with a fancy UI --- This solution would be the most work. We could have a new webapp (such like our security tracker) just for NEWS objects. Every maintainer should have access to their assigned packages. Pro: + Fancy + Easy to use + API endpoints Con: - A lot of work - I would go for solution 1. What would be interesting to know for me: 1. Do you think that we actually *need* such a tool? 2. Would you use such a tool/workflow? 3. Do you have other/better ideas? I hope for an interesting constructive discussion. Best regards chris [1] https://wiki.gentoo.org/wiki/Gentoo_Cheat_Sheet#Gentoo_Monthly_Newsletter_.28GMN.29 signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping dingo from [community]
On Thu, Jun 27, 2019 at 03:43:37PM +0800, Public mailing list for Arch Linux development wrote: > Hi All, > > I have removed dingo the Google DNS-over-HTTPS client from [community]. > The upstream is inactive for years and supports Google only. > > I would recommend dns-over-https [1] instead which has support for > multiple protocols and is still actively maintained. > > Note that Google announced [2] yesterday that they recommend to use the > newer IETF protocol (at a new endpoint), which is also the protocol of > all other major DoH providers (CloudFlare, Quad9, etc). > > [1] https://www.archlinux.org/packages/community/x86_64/dns-over-https/ > [2] > https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.html > > -- > Regards, > Felix Yan > Hi small addition: It's also possible to use DNS-over-TLS with systemd-resolved[2] as alternative to DNS-over-HTTPS. chris [2] https://wiki.archlinux.org/index.php/Systemd-resolved signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
On Sun, Jun 02, 2019 at 12:38:24AM -0400, Public mailing list for Arch Linux development wrote: > Dear Christian, > > Thank you for your email. > > I do not share your point of view that the organization is chaotic. You > successfully explained the three roles and each of its duties within two > or three clear sentences. We could certainly have a more fine-grained > hierarchy but our team is not very big and I personally do not think the > benefits would outweigh the extra administrative work in the long run. > > Do you have any concrete evidence that adding more bureaucracy would > benefit the project? Any evidence that our current organizational > structure prevents people from contributing (which you seemed to imply > with your statement above)? Well, my proposal was to remove bureaucracy, not to add more bureaucracy. Here are various issues that I had in the past: 1. I am waiting since weeks for a separate section for legal related content in our dev wiki for adding the AUR takedown request answer template. This template was created by awesome team work and I think it would be sad if it would be just gone. Furthermore people said that it would be a good idea to have it somewhere for future takedown requests. 2. At the moment it's difficult to co-maintain packages between [extra] and [community]. A developer who wants to allow co-maintainership by TUs needs to move a package to [community]. In my opinion this step is unnecessary and leads to unnecessary communication and workflows. 3. I don't like that devs and TUs live aside each other instead of finally realizing themselves as community or group. I think the community as itself would work much better if we would have user-access based package repositories and just 'maintainers', instead of this dev/TU split. > As Gaetan already mentioned, the process is clear: somebody suggests a > new developer and we discuss until a consensus is reached. Feel free to > document that somewhere in our wiki if you think it needs to be > documented. If you have specific concerns with that process, feel free > to share them. However, I do not think anybody in the dev team ever had > any objections against that procedure. What interests me is why is this whole process not transparent and public? I mean we discuss adding new TUs publicly. Of course this dicussion comes with all its good and bad parts, but atleast it's transparent and people get a reason why they are not elected. I am a big fan of the 'people can change' attitude, but this only works if they know their mistakes. The only reason for private discussions seems to be 'personal bias'. Atleast thats what I think if I think about private elections or better selections of new devs. And personal bias should never a criteria to select or deny somebodys contribution, it should be based on technical questions. > The idea of having a separate repository for (most) proprietary sounds > sensible to me. > I have a few things to add regarding proprietary software, that we have discussed in IRC. It would be nice to have atleast a list somewhere with proprietary software and their license. I mean we can be glad, that the TU asked for adding vivaldi browser to community, what if he would have just added it? I guess it wouldn't be a problem, until somebody finds it or we get a take down request for the package. Therefore I wonder how many packages we may illegaly redistribute already? Maybe it would be useful to track such packages somehow and a separate repository would be a good starting point for this. > Is there any hidden suggestion here? Yes, a suggestion for user-isolated packages. This will be/can be achieved via the move to a git repository. > I am confused. You are saying we are mixing too many roles above and > suggesting to reduce the number of roles now? Well, I guess it's not possible to simplify all rules. But we could at least start with simplifying the role of package maintainers and start realizing us as one community not as two separate groups. > > It would be also nice to form an actual roadmap (yes.. I know.. we are > > not a company, but a roadmap or overview over all current projects > > inside of our community would be nice). This way it would be also easier > > to contribute for 'outsiders'. > > Does not sound like a bad idea to me. Feel free to create a draft. A kanboard does exist already for it, and I hope more will be discussed at meetups. signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
On Sat, Jun 01, 2019 at 04:10:45PM -1000, Public mailing list for Arch Linux development wrote: > Hi Christian, > > [2019-06-02 01:08:30 +0200] Christian Rebischke via arch-dev-public: > > inspired by the last thread about moving proprietary software to > > community, our general problem of getting more people involved in Arch > > Linux and the (for me) chaotic organisation structure and hierarchy I > > would like to propose a discussion about changes. > > I seem to recall we've had a similar discussion just a couple of months > ago but allow me to reiterate some key points. > > First, contrary to what you keep saying, the process by which devs make > decisions is very clear: by discussing things until a consensus emerges. > In extreme cases where a consensus cannot be reached, we can take a vote > or let our leader decide, but this has never happened in the nine years > I've been a dev. Hi Gaetan, Thanks for your mail. I remember now that you have told me this some months ago. This leads to a question: Why are these types of dicussions not public? > I've been a dev. To the best of my knowledge, we're all very happy with > this system and do not want to change it. Who do you mean with 'we'? Are you sure you speak for all devs and TUs here? > Second, our current organizational structure has served us well for many > years. What problem are you trying to solve by overhauling it? What > piece of evidence do you have that your suggestions will fix those > problems? I'm certainly going to support imposing more bureaucracy just > for the sake of bureaucracy. Again, if a certain system works for TUs, > I'm glad and I'm certainly not going to impose my views on how TUs work; > after all, that's why the TUs were made a self-governing body. Well, that's point. I don't really think the current system works as it could be. Why being happy with the current state of organisation if we could achieve much more with a more simplified and more contributor friendly model? And this 'self-governing body' is exactly what I don't like. It increases this 'we and them' like thinking. Furthermore my suggestions are not the best solution, it was just a start for discussing our current structure. If you and the others see no point in changing the current structure this is totally fine, I just think it's important to rethink processes from time over time. > > Cheers. > > -- > Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
On Sun, Jun 02, 2019 at 01:07:12PM +1000, Allan McRae wrote: > On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote: > > 1. Simplified repositories > > > > Currently we have [core], [extra] and [community]. These three > > repositories are there, because they have grown to this structure over > > time. At the moment I don't see any real meaning for the split of [core] > > and [extra]. So one suggestion would be to either: > > - merge [extra] and [core] > > I stopped reading here. If you don't understand the difference between > [core] and [extra], you should ask. Particularly before proposing the > removal of [core]. > > Allan Hi Allan, I didn't propose the removal of [core], I proposed a discussion around the current repository and organisation structure. Merging [core] and [extra] is just one of many ideas. If you have something to say, please do so and don't keep your secret. I would be glad if you could share it. chris signature.asc Description: PGP signature
[arch-dev-public] Proposal for a new organisation structure
Hello everybody, DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. inspired by the last thread about moving proprietary software to community, our general problem of getting more people involved in Arch Linux and the (for me) chaotic organisation structure and hierarchy I would like to propose a discussion about changes. Please don't see this thread as an attack on your current position or whatever. I would like to propose a more democratic, simplified and more contribution friendly approach for our current hierarchy and organisation structure. At the moment we have the following three Groups (If I miss something feel free to correct me): - Devs - Trusted Users - Support Staff These three groups have the following 'features' and tasks: - Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events. - How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear. - Trusted Users: - Tasks: The trusted users care about the [community] repository, somehow some TUs have more tasks like: security team involvement, wiki administration, infrastructure administration, maintainership of software projects and other infrastructure projects like docker images, reproducible builds etc. Furthermore they care mostly about the package quality in the AUR (eg. answering submitted requests...) - How to be a trusted user?: It's well documented, we have rules for misbehavior, rules for applying, guidelines for moving packages into community and more. - Support Staff: - Tasks: They do various tasks like infrastructure administration, wiki administration, bug wrangling, software contribution, forum moderators, security team, but they have no access to any repository. - How to be a support staff: It's unclear, mostly a new contributor just knows the right people and does the right thing at the right time and get somehow acknowledged by developers or TUs for their work. Ok, I hope this gives a good overview over all three groups. Besides these groups, we have also people in more than of these groups. Anthraxx is for example listed as (dev,tu and support staff) on our website, I am listed as (tu and support staff) and so on. So what is my actual proposal. Well my proposal is to simplify the whole organisational structure, tear down bureaucracy, tear down 'walls' and unify the community and make it easier for 'outsiders' to contribute to the project we all love. Therefore I would like to propose a discussion around the following things: 1. Simplified repositories Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules). 2. Repository access At the moment a TU can access all packages inside of the [community] repository. Therefore they are able to modify packages in a good or bad manner. This can have nice effects and bad effects, how the past has shown to use, such as: - rapid updates in case of security vulnerabilities (good effect) - updates of packages, because somebody thought it needs an update, but the real reason for the delay was a bug inside of the new version of a software (bad effect) 3. Organisation structure Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package). 4. More transparency At the moment the recruiting process for developers is pretty unclear, as well as
Re: [arch-dev-public] Spring cleaning (take 2)
On Wed, Mar 27, 2019 at 05:19:34PM +0100, Public mailing list for Arch Linux
development wrote:
> Following up on xyproto's [community] cleanup, here is a list of unrequired
> orphans in [extra] which could be removed (minus the aspell/hunspell dicts).
> Please adopt them if you want to keep them (some of them are clearly
> maintained, eg. vulkan stuff). If you ∈{TU's}\{devs} and want to maintain
> something, reply and I will move it to [community]. Will start dropping
> stuff in a week.
>
> alsaplayer
> artwiz-fonts
> bluefish
> bluez-firmware
> bootchart
> di
> enlightenment16
> epplet-base
> fetchmail
> fonts-tlwg
> foobillard++
> fvwm-crystal
> fyre
> geeqie
> glsof
> gnome-alsamixer
> icewm
> idnkit
> linux_logo
> lua-luajson
> sbsms
> scim-anthy
> scim-hangul
> scim-m17n
> scim-pinyin
> scim-tables
> scim-uim
> streamripper
> thinkfinger
> ttf-arphic-ukai
> ttf-arphic-uming
> ttf-baekmuk
> ttf-cheapskate
> ttf-freebanglafont
> ttf-hannom
> ttf-khmer
> ttf-mph-2b-damase
> ttf-sazanami
> ttf-tibetan-machine
> ttf-ubraille
> vulkan-extra-layers
> vulkan-trace
> wpa_actiond
> xbill
> xfig
> xmahjongg
> xsnow
Hi,
I would adopt:
ttf-baekmuk
ttf-hannom
ttf-khmer
ttf-sazanami
ttf-tibetan-machine
Best wishes,
chris
signature.asc
Description: PGP signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On Mon, Mar 25, 2019 at 12:46:15AM +0100, Public mailing list for Arch Linux development wrote: > On Sun, Mar 24, 2019 at 04:39:54PM -0700, Andrew Gregory via arch-dev-public > wrote: > > I don't consider hoping that libarchive doesn't need a rebuild in the > > near future a great strategy. That being said, this is really > > a question of how long of a period we need between libarchive v3.3.3 > > and us making the switch. I'm not a packager, so I don't have much of > > an opinion on that. > > Well, we pride ourselves with having competent users. I think waiting a year > is > conservative and safe. However, personally I think we can wait for the next > pacman release and write an announcment. Then we give everyone a month to > update > and we can have a smooth transition. Assuming of course that everyone is > on-board with this change. > > I would like to get some opinions from packaging devs with experiences. I agree with this. Arch Linux's unique 'selling' point is that we treat our users as competent persons, who don't need a special care. They are able to read announcements, react on problems and get help in one of our many community channels. I think we should keep this transition as short as possible. Everytime when I tried to propose 'enterprise' features, I got told, that Arch Linux is just a 'hobby project' and we don't need so much reliability. So why should we decide different here? chris signature.asc Description: PGP signature
Re: [arch-dev-public] Co-maintainers and less time for packaging
On Wed, Mar 20, 2019 at 02:02:08PM +0100, Public mailing list for Arch Linux development wrote: > Yo! > > As some might be aware, I'm finishing up a master thesis that is due 1st of > June. Because of this my time is going to be limited closer to the delivery > date. To try relieve some stress I'm giving a heads up that the time spent on > packaging is going to be strained going forward. > > Since we have been trying to focus on co-maintainers for each package, I have > collected a list of packages where I am the sole maintainer. Feel free to > adopt > any package on the list :) I can probably share nvchecker setup for most of > them. > ... Hi Morten, I have co-adopted restic and gopass, because I use both of them heavily. Best regards, chris / shibumi signature.asc Description: PGP signature
Re: [arch-dev-public] TU application process
On Tue, Nov 06, 2018 at 08:37:42PM +1000, Allan McRae wrote: > On 6/11/18 8:15 pm, Bruno Pagani wrote: > > Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit : > >> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: > >>> On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: > >>>> Hello everybody, > >>>> > >>>> First of all, the following mail has nothing to do with the last two TU > >>>> applications, it's a general view on the current TU application process. > >>>> > >>>> I would like to propose a new process for TU applications due to several > >>>> reasons: > >>>> > >>> Read the TU bylaws. It has specific instructions of where proposals > >>> must be posted (hint: not here...). > >>> > >>> A > >> Hi Allan, > >> > >> This mail wasn't meant as proposal. It's just a general discussion about > >> this topic and people said in the TU IRC channel yesterday, that > >> arch-dev-public would be the > >> right mailinglist for such discussion. > >> > >> chris > > Specifically, we are also interested in the input of devs, not just TUs. > > Strange, given TUs are set-up to be an independently governed group from > developers... But because you asked my opinion, I think a TU council is > a really, really, really bad idea. No need to set some TUs above > others. We have never had a formal hierarchy in the developers (apart > from our glorious leader), and are instead run by those who step up to > lead what needs done. I believe that this is what makes Arch work, and > governance would be detrimental to the distribution as a whole. > > Personally, I'd get rid of all quorum for electing a TU, and make > inactive TUs be measured purely on the basis of package updating. Most > TU application discussions are inane beyond the customary package > review. And when someone applies and their packages are very bad, their > sponsor should be held in shame. > > Finally, I don't want to hear what the minions are up to! Get back to > your own mailing list. :) > > A Ok, but nevertheless thanks for your opinion. I will move this to aur-general now. chris signature.asc Description: PGP signature
Re: [arch-dev-public] TU application process
On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: > On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: > > Hello everybody, > > > > First of all, the following mail has nothing to do with the last two TU > > applications, it's a general view on the current TU application process. > > > > I would like to propose a new process for TU applications due to several > > reasons: > > > > Read the TU bylaws. It has specific instructions of where proposals > must be posted (hint: not here...). > > A Hi Allan, This mail wasn't meant as proposal. It's just a general discussion about this topic and people said in the TU IRC channel yesterday, that arch-dev-public would be the right mailinglist for such discussion. chris signature.asc Description: PGP signature
[arch-dev-public] TU application process
Hello everybody, First of all, the following mail has nothing to do with the last two TU applications, it's a general view on the current TU application process. I would like to propose a new process for TU applications due to several reasons: 1. I have the feeling that most sponsors are not aware of the responsibility of sponsoring a new TU candidate. There is more to do than just approving their application. Candidates should get advice for and after the application process. This includes: * learning how to sign mails * getting feedback for their PKGBUILDs from their sponsoree * getting advice for building packages correctly via makechrootpkg wrappers * getting help for the post-application-process, when the candidate has been accepted. * directing the new candidates to our IRC channels or mailinglist for community intergration. 2. I have the feeling that most TUs only vote, because of our new stricter bylaws. 3. I miss more TU contribution in TU application processes as well. I guess the reasons for the points above are missing time or missing mood for actively participating in the discussion. Therefore I would like to suggest some modifications to our TU application process. Here are some ideas from a discussion we had last night in the TU IRC channel: 1. Establishing a TU council, that get elected a certain time slot. The members of this council are responsible for accepting or rejecting a TU. Every TU can still sponsor or suggest a candidate, but the voting process will be done in this council only. The council should consist out of very active TUs and devs, who are known for a good package quality. 2. Establishing a 2-sponsors-rule instead of the current policy of one sponsor. 3. Best regards from Germany chris / shibumi signature.asc Description: PGP signature
Re: [arch-dev-public] /r/linux AMA
On Thu, Aug 09, 2018 at 06:41:43PM +0200, Public mailing list for Arch Linux development wrote: > * Reddit username. > * What you do. > * What Monday fits for you? Reddit username: sh1bumi What you do: Trusted User, Automated Vagrant image builds, Security Team work [sadly pretty inactive the last weeks :( ] What Monday fits you: Every monday signature.asc Description: PGP signature
[arch-dev-public] Arch Linux Cloud Images (virtualbox and Qemu)
Hello everybody, Some months ago Bartlomiej had the awesome idea to generate qemu and virtualbox images as well. Afterwards we had a small discussion about this topic in #archlinux-projects. I would like to refresh this discussion and move it to this mail thread. So, our vagrant boxes are building automatically and without issues for a few months now. I could just generate virtualbox and qemu images as side products monthly, but I have no idea how we would release them. Another big topic is security. The vagrant images are at the moment not signed and seems like vagrantcloud doesn't support this either. This doesn't mean that we shouldn't sign our qemu or virtualbox images. We could just generate an automated cloud image signing key (only for this purpose) of course and automatically sign the images with that key. Problem with this is: If our build server ever get pwned the person will have these keys for signing cloud images as well. Any opinion about this? In my humble opinion I would be fine with a signing key that follows only this particular purpose. Another idea would be to move the whole production process to a physical server behind a firewall that is physical accessible by one or more Arch Linux Developers. I really would like to push this forward. Any comments? Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
On Mon, Jan 29, 2018 at 10:00:28PM +0100, Public mailing list for Arch Linux development wrote: > So deadline is 2018-02-7 > > > -- Chris Hello everybody, sorry for the delay. I thought about this a little bit longer and I came to the conclusion that this project will not work without the full support of all developers. So I guess, I will inform Microsoft that we won't participate in their programm. Thanks for the nice and open discussion. -- chris signature.asc Description: PGP signature
Re: [arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
On Mon, Jan 29, 2018 at 03:09:16PM -0600, Public mailing list for Arch Linux development wrote: > On Mon, 29 Jan 2018 22:00:28 +0100 > Christian Rebischke via arch-dev-public <arch-dev-public@archlinux.org> wrote: > > > Hello everybody, > > I would like to start a discussion about Windows Subsystem Linux and > > Arch linux. You all might know that Microsoft has increased their > > participation in open source software a lot since Satya Nadella is CEO > > of Microsoft. > > > > They even implemented a subsystem on Windows 10 for executing natively > > ELF binaries on Windows. This system is based on docker images and some > > nice guys from Microsoft have asked Allan and me if Arch Linux would be > > interested to participate in this project. > > > > The steps for getting into the project are: > > > > * Signup in the Microsoft Appstore (we would get a free voucher if we > > want to participate) as Organization (we need the ok from one of our > > trademark holders for this step) > > * modifying our docker container a little bit > > * pushing it into the microsoft appstore > > > > So what do you think? Should we participate in that project? > > > > Here are some pros and contras: > > > > pro: > > - CentOS and Ubuntu are there too > > - Would be a nice chance to increase the awareness about Arch Linux > > - might get people to change from Windows to Arch Linux (or linux in > > general) > > - Nice way to test our docker image in production > > - People who are forced to work on windows at work can use Arch > > Linux at work as well > > - More bugreports / feedback / forum activity? > > > > contras: > > - Microsoft is Microsoft (I think I don't need to explain) > > - More Newbies? > > - Somebody would need to maintain it (I would do it) > > - If Arch Linux partnerships with Microsoft could lead into bad image? > > > > > > I would like to hear as much feedback as possible. So don't be shy :) > > I want to give feedback to the microsoft guys in round about 1 week. > > I guess that should be enough to dicuss this topic. > > > > So deadline is 2018-02-7 > > > > > > -- Chris > > This has come up before, my personal preference is that if you want Arch is > WSL, go ahead and install Arch in WSL. It's not difficult by just using the > bootstrap image. IMO, this would be similar to us supporting Manjaro, > Antergos, > or any other automatic, pre-configured and setup system. The difference would be "it's official". There are Arch Linux WSL containers at the moment btw: https://github.com/alwsl/alwsl But it's nothing official. signature.asc Description: PGP signature
[arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
Hello everybody, I would like to start a discussion about Windows Subsystem Linux and Arch linux. You all might know that Microsoft has increased their participation in open source software a lot since Satya Nadella is CEO of Microsoft. They even implemented a subsystem on Windows 10 for executing natively ELF binaries on Windows. This system is based on docker images and some nice guys from Microsoft have asked Allan and me if Arch Linux would be interested to participate in this project. The steps for getting into the project are: * Signup in the Microsoft Appstore (we would get a free voucher if we want to participate) as Organization (we need the ok from one of our trademark holders for this step) * modifying our docker container a little bit * pushing it into the microsoft appstore So what do you think? Should we participate in that project? Here are some pros and contras: pro: - CentOS and Ubuntu are there too - Would be a nice chance to increase the awareness about Arch Linux - might get people to change from Windows to Arch Linux (or linux in general) - Nice way to test our docker image in production - People who are forced to work on windows at work can use Arch Linux at work as well - More bugreports / feedback / forum activity? contras: - Microsoft is Microsoft (I think I don't need to explain) - More Newbies? - Somebody would need to maintain it (I would do it) - If Arch Linux partnerships with Microsoft could lead into bad image? I would like to hear as much feedback as possible. So don't be shy :) I want to give feedback to the microsoft guys in round about 1 week. I guess that should be enough to dicuss this topic. So deadline is 2018-02-7 -- Chris signature.asc Description: PGP signature
Re: [arch-dev-public] PSA: third-party gems have been split from 'ruby' package
On Fri, Jan 26, 2018 at 04:36:32PM -0800, Public mailing list for Arch Linux development wrote: > Hello folks > > There been a packaging issue with 'ruby' package that annoyed me for a > while. The problem comes from the fact that ruby-lang.org source > tarballs contain ruby sources itself *and* some third party packages > from rubygems.org. The third-party gems shipped by 'ruby' tarball are: > minitest, net-telnet, did_you_mean, power_assert, rake, test-unit, > xmlrpc, rdoc. Currently we repack these gems and ship it as a part of > ruby Arch package. > > Because gems are bundled with ruby package we have no way to update > gems separately. All we can do is to wait until ruby developers update > their bundle and release it. > > The plan is to split these gems from 'ruby' package and install it > independently from what ruby developers bundle. Upcoming ruby changes > do that - ruby-2.5.0-4 will not include any of the third-party gems > mentioned above. > > Two popular packages - rake and rdoc will get Arch packages (ruby-rake > and ruby-rdoc respectively). Other gems need to be installed either > from AUR or from gem. Hello Anatol, Good decision! I have rebuild asciidoctor with ruby-rdoc as makedependency. Shall I move it to testing and you move all packages in one turn over to the stable repositories? Will you create a todo for it? Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On Tue, Jan 23, 2018 at 10:58:48AM +0100, Public mailing list for Arch Linux development wrote: > On 21.01.2018 20:50, Christian Rebischke via arch-dev-public wrote: > > I would definitly > > prefer to have the vagrant boxes around the same date as we release our > > ISO images. > > How about letting it run every day and adding a quick check to the > script that only starts the build when the iso is available and no image > has been built yet? > > Florian > Isn't this more like a workaround? I would really appreciate automated ISO image builds or at least the option that more than one person is able to generate these images. Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On Sun, Jan 21, 2018 at 07:41:53PM +0100, Public mailing list for Arch Linux development wrote: > It would be probably seen as more "official" if it was mentioned on our > website. Absolutly! I will see what I can do to bring that on our website. > > My first goal has been to add some hypervisors, but due to > > the fact that we have only libvirt and virtualbox in our repositories I > > have dismissed this plan. The automated build process works fine so far > > (except some issues with qemu[2] and the dependency on punctual iso > > releases on soyuz. The latter should we definitly fix. Currently the iso > > images are build manually. Can we automate this somehow? I really rely > > on punctual releases otherwise the automated build will fail and > > somebody needs to trigger the build again manually. Happened about 1-2 > > times..) > > This is something that would require a virtually offline box to be fully > automated. For the time being, it sounds better to upgrade your vagrant > image after first week of the month. Actually I do this already. The systemd timer for the automated builds is set on the 5th of each month (round about a week). Normally the ISO was there on 1st or 2nd each month, but in the last months its more like 6th or 9th. I could move that timer on 14th, but I would definitly prefer to have the vagrant boxes around the same date as we release our ISO images. > > Also, any plans to expand the scope to support OpenStack, AWS and GCE? > At the moment the scope sounds rather limited. It's possible to build images for OpenStack, AWS and GCE, but as far as I understand the docs for it we would need an OpenStack cloud for OpenStack images, an AWS account for generating Amazon EC2 Images and a Google Account for generating GCE Images[1], because the packer connects to these services to generate the image. > Can you actually give more details how it's going to look like? Sangy worked on this. He explained it one day, but It's already some months ago. I hope he will attend our discussion here and give us a short summary about that process. signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On Sun, Jan 21, 2018 at 03:23:44PM +0100, Jelle van der Waa wrote: > I'm all for automatic builds, and the improvement where multiple people > know how the ISO's are build & released. How would we however sign these > builds? And is the bootstrap image also generated in the same manner? Well, we have two options: Option 1: More people can build ISOs and more people can sign the ISO. Option 2: We automate the process and sign the ISO on our server with a new public key. Thats how nixOS or voidlinux do this. No idea about the bootstrap image. Is there a big difference between the bootstrap image and `pacstrap` in some random directory? > I or others can grant write access to the repository, see the owners on > the Github organization. I would however first want to ask pierres about > it since he irregurarly is on IRC. > Are these docker builds going to be automated as well btw? Oh and > testing images :-) I would love to automate that as well, but I don't know a good process for it yet. My first thought was that we automate docker via packer as well, but unfortunately packer doesn't support docker builds. It shouldn't be that difficult to automate it with some bash magic.. > This would be nice, how do we share the credentials to the docker login > though? Or can we make multiple people owners? Just register at dockerhub and I can add you to the Arch Linux Group. (this applies to every other developer as well. If you want access just register an account and message me) signature.asc Description: PGP signature
[arch-dev-public] Arch Linux Docker / Vagrant: Current situation
Hello Everybody, It's now over a half year ago that I've started working together with sangy and pierre on our vagrant and docker images. I would like to give you a short update on this topic. The Arch Linux Vagrant images are currently be build for libvirt and virtualbox. We have over 3800 downloads at the moment and slowly catching up to the community based arch linux vagrant images.[1] My first goal has been to add some hypervisors, but due to the fact that we have only libvirt and virtualbox in our repositories I have dismissed this plan. The automated build process works fine so far (except some issues with qemu[2] and the dependency on punctual iso releases on soyuz. The latter should we definitly fix. Currently the iso images are build manually. Can we automate this somehow? I really rely on punctual releases otherwise the automated build will fail and somebody needs to trigger the build again manually. Happened about 1-2 times..) The other topic is the docker image. Has anybody of you contact to pierre? He doesn't answer my mails and he is the only one with access to the repository on github. Sangy/Santiago[3] was so nice to speak with the docker guys. They said they would approve our docker image and we could move it to the other official images[4]. But for this we need to do some changes on our docker repository on github. (As long I understood sangy correct it would be just some new branches). best regards, chris / shibumi [1] https://app.vagrantup.com/archlinux/boxes/archlinux [2] https://github.com/hashicorp/packer/issues/5769 [3] https://www.archlinux.org/people/support-staff/#sangy [4] https://hub.docker.com/explore/ signature.asc Description: PGP signature
