March 2018 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] Improving overall experience for contributors
by Bartłomiej Piotrowski 06 Feb '19

06 Feb '19

Hi all, Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect. One of the problems I keep hearing about is that there is no clear place where potential contributors could start. Sure, some things seem obvious to us: take care of some wiki article or adopt orphan AUR packages. It isn't actually that easy. Not everyone is interested in editing or maintaining random packages, and while there is plenty to do, how someone new could know it? We could use help not only with existing projects like archweb, pyalpm or namcap, but also with development of new code (for example a maintainable rebuild automation) and infrastructure side (which is in fact too generic term that could be better described). I am totally in love with What can I do for Mozilla?[1] which is open source, so why not steal this wonderful idea? But it also means we need a way to communicate with people interested in helping us: at least an IRC channel and new mailing list. Another thing that I heard in last few months isthat it is actually hard for potential TU candidates to find a sponsor. While I believe it is perfectly fine to e-mail few potential sponsors to ask for opinion, throwing random messages at people doesn't sound really appealing. In my humble opinion, we should rethink the way we recruit people and probably introduce fine-grained permissions to dbscripts that would allow to limit new maintainers to limited set of packages. We should also lower our expectations towards candidates. At least once we rejected one for some stupid reason (no fingerpointing here, I'm not saint either), leaving packages they wanted to adopt virtually orphan. It's better to help amn inexperienced packager gain experience than voting no, really; to be brutally honest, quite a lot of packaging work we are handling doesn't have much in common with rocket science. I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time. Your thoughts? Bartłomiej [1] https://whatcanidoformozilla.org/

8 11

[arch-dev-public] linux-manpages
by Andreas Radke 19 Apr '18

19 Apr '18

In the past we have packaged man9 section of kernel docs. Upstream removed the man pages section in 4.14 release. There are now different types of kernel docs available (make help output): Documentation targets: Linux kernel internal documentation in different formats from ReST: htmldocs - HTML latexdocs - LaTeX pdfdocs - PDF epubdocs - EPUB xmldocs - XML linkcheckdocs - check for broken external links (will connect to external hosts) refcheckdocs - check for references to non-existing files under Documentation cleandocs - clean all generated files make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2 valid values for SPHINXDIRS are: crypto networking input media core-api userspace-api process driver-api sh admin-guide doc-guide filesystems dev-tools kernel-hacking sound gpu make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build2 configuration. This is e.g. useful to build with nit-picking config. Default location for the generated documents is Documentation/output The recent docs are available online here: https://www.kernel.org/doc/html/latest/# Should we keep packaging this at all or drop it? Is there anybody who want to take this package over? I'm not interested in packaging this though maintenance work is low. -Andy

1 1

[arch-dev-public] Boost looking for new maintainer
by Bartłomiej Piotrowski 16 Apr '18

16 Apr '18

Hi team, As I'm absolutely the worst with C++, none of my packages depend on boost and I've spent enough nights terrified of its build system quirks, I'll be orphaning it soon. Feel free to adopt it in archweb. Bartłomiej

4 4

[arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
by Antonio Rojas 12 Apr '18

12 Apr '18

Hi, Currently most of our packages which use the cmake build system are built with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to upstream) set of C(XX)FLAGS defaults which are appended to and override our default C(XX)FLAGS. So, for instance, our cmake packages are being built with -O3 instead of our default -O2. Besides the inconsistency that this brings to our binaries, IMO it's not a good idea to override our default C(XX)FLAGS unless there's a good reason to. This will also cause issues once we start building debug packages by default (-DCMAKE_BUILD_TYPE=Release also adds DNDEBUG). Therefore I'm proposing to drop -DCMAKE_BUILD_TYPE from all our cmake packages, building them with our default C(XX)FLAGS as all other packages. Comments?

8 19

[arch-dev-public] New build server in Singapore
by Bartłomiej Piotrowski 04 Apr '18

04 Apr '18

Hi all, for those of you that are living closer to Asia than Europe, there is new build server available, located in Singapore. It is considerably less beefy than soyuz, but should be okay for regular builds. All packagers should be able to ssh into it with username and the key used on other servers. The address is sgp.pkgbuild.com. You can compare fingerprints below: SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519) SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA) SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA) It also hosts a mirror available at https://sgp.mirror.pkgbuild.com Enjoy, Bartłomiej

3 4

[arch-dev-public] Offline for the next week or so
by Eli Schwartz 30 Mar '18

30 Mar '18

It's the Passover holiday season again... I'll be a combination of offline and difficult to reach for the next week, week and a half. -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] freecad maintainer wanted
by Florian Pritz 22 Mar '18

22 Mar '18

Hi, Since I no longer use freecad myself I am not very interested in continuing to maintain it. If nobody steps up, I will move it to AUR in about a week. Some notes: - The current release is over a year old, a new one should come soonish. - There is an open bug[1] that leads me to believe that freecad might use a bundeled version of coin3d which contains a bundeled version of expat that is very old and may also contain security vulnerabilities. - I haven't yet managed to build freecad from git master with qt5 support. Looks like it needs pyside2 for this, but that doesn't have a stable release and we don't pacakge random commits from a git branch. - freecad 0.16 (current version) blocks opencascade from being updated to >= 7.0. 0.17 should be compatible at least with 7.0, possibly with 7.1. [1] https://bugs.archlinux.org/task/57843 Florian

1 1

[arch-dev-public] LLVM 6.0 rebuild
by Anatol Pomozov 16 Mar '18

16 Mar '18

On Fri, Mar 16, 2018 at 6:20 AM, Arch Website Notification <nobody(a)archlinux.org> wrote: > The todo list "LLVM 6.0" has had the following packages added to it for which you are a maintainer: > > > * community/crystal (x86_64) - https://www.archlinux.org/packages/community/x86_64/crystal/ > > Todo list information: > Name: LLVM 6.0 > URL: https://www.archlinux.org/todo/llvm-60/ > Creator: Evangelos Foutras > Description: > libLLVM-5.0.so -> libLLVM-6.0.so > libclang.so.5 -> libclang.so.6 > > In addition to the above soname changes, our clang package no longer ships > static libraries. Instead, those are built as individual shared libraries > (using CMake's BUILD_SHARED_LIBS flag). > > ** I'll add LLVM 5 packages once it's clear they are needed for software that > hasn't been ported to LLVM 6 yet. Feel free to ping me on IRC for this. ** Hello Evangelos I tried to rebuilt Crystal package with LLVM and hit a compilation issue ./bin/crystal build --release --no-debug -D i_know_what_im_doing -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib _main.o: In function `*Crystal::Compiler#pass_manager_builder:LLVM::PassManagerBuilder': main_module:(.text+0x52dc08): undefined reference to `LLVMInitializeInstCombine' collect2: error: ld returned 1 exit status That described here https://github.com/crystal-lang/crystal/issues/5556 and it turns out to be a LLVM bug https://bugs.llvm.org/show_bug.cgi?id=35947. This LLVM bug is fixed in HEAD (https://reviews.llvm.org/D44140) and should be released in 6.0.1. Or maybe we can pull it to the Arch package?

2 1

[arch-dev-public] Arch Linux Docker / Vagrant: Current situation
by Christian Rebischke 12 Mar '18

12 Mar '18

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/

7 19

[arch-dev-public] LLVM 6 and splitting up {clang, lld, lldb, compiler-rt} into separate PKGBUILDs
by Evangelos Foutras 09 Mar '18

09 Mar '18

I pushed llvm 6.0.0-1 to [staging] without the rest of the packages mentioned in the subject. I am planning to add them back as individual packages in the following days. This separation will bring faster builds when one of these components needs patching. It also allows building clang with shared libraries and merging the extra-tools package into it (thus fixing https://bugs.archlinux.org/tas k/50865). Once everything is in [staging], I'll create a TODO list for rebuilds as usual.

1 0