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

[arch-dev-public] Gone until July 8th
by David Runge 17 Jun '18

17 Jun '18

Hey all, I'm going to be "not so available" over the coming weeks due to my wedding (leaving on Thursday and back July 8th). Feel free to update packages, that are long out-of-date ('none' [1] [2] currently). Best, David [1] Latest khal is currently only adding a version pinning for python-dateutil, which would require patching the setup.py (didn't have time to do that yet and try to get more information out of upstream... very slow-moving process). [2] zita-convolver 4.0.0 introduces API changes, which break its dependants and will require introducing the library in two versions (will do that after I come back), for older and newer applications in [community] to build. -- https://sleepmap.de

1 0

[arch-dev-public] TexLive 2018 move in [extra] today
by Rémy Oudompheng 16 Jun '18

16 Jun '18

Hello, I will move Texlive 2018 packages to [extra] today, along with zathura and qpdfview which were rebuilt for libsynctex. Rémy.

1 0

[arch-dev-public] Archive cleanup (2013, 2014, 2015)
by Florian Pritz 14 Jun '18

14 Jun '18

Hi, So far we haven't ever cleaned up the archive (https://archive.archlinux.org/) but it's getting too big and I don't think we have any use for packages from years ago. Next week I will remove the years 2013, 2014 and 2015. Florian

3 10

[arch-dev-public] Alioth retirement and tarball archive
by Baptiste Jonglez 07 Jun '18

07 Jun '18

Hi, There is some good news about the retirement of Alioth [1]: the Debian people have finally decided to keep an archive of all the tarballs! They are available at [2]. I've updated the TODO description: with this archive and the new gitlab for -git projects, it should cover all of our packages that depended on Alioth. Baptiste [1] https://www.archlinux.org/todo/alioth-retirement/ [2] https://alioth-archive.debian.org/releases/

1 0

[arch-dev-public] Moving gcc7 into [community] for CUDA
by Sven-Hendrik Haase 29 May '18

29 May '18

Hey, I would like to move gcc7 (based on the latest version 7 commit of gcc [0]) into [community] because of cuda 9.2 and in return drop gcc54. I tried to make it work with current gcc but to no avail. In earlier releases of cuda the incompatibilities could be patched with header hacks but not this time. I tested the whole setup with cuda 9.2 locally and it seems to work fine. I just want to get somebody's ok on this as apparently not everyone is stoked about having yet another old version of gcc in there for some time. Sven [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gcc…

4 6

[arch-dev-public] Replacing pkg-config with pkgconf
by Jan Alexander Steffens 24 May '18

24 May '18

I want to replace pkg-config with pkgconf, an implementation that's actively maintained. https://github.com/pkgconf/pkgconf/ pkgconf is reportedly both faster and has saner behavior. For example, right now `pkg-config --exists OpenEXR` fails if glu is not installed, since OpenEXR has a "private" dependency on glu. However, `pkg-config --libs OpenEXR` works since pkg-config ignores private dependencies here. Private dependencies are relevant for static linking, analogous to a shared library's DT_NEEDED tags. `pkg-config --static --libs OpenEXR` lists the libraries necessary to statically link OpenEXR. pkgconf is more consistent and follows private dependencies only if --static is given, regardless of whether --libs or --exists is used. pkgconf is in use by at least FreeBSD, NetBSD, Fedora and Mageia; so we wouldn't be the first ones making the switch. There's already a package in [community] owned by demize. I would make some adjustments before releasing it to [testing]. Any objections?

2 1

[arch-dev-public] HEADS UP: Qt 5.11 in [testing]
by Antonio Rojas 22 May '18

22 May '18

As usual, due to Qt's ABI versioning, everything compiled against Qt 5.11 will get a runtime dependency on it, so it will have to stay in testing until Qt itself moves. Keep it in mind if you plan to build Qt stuff against testing or staging. Other changes of interest for packagers: - qdoc now relies on the clang code parser to generate docs. Since qt5-tools contains many other unrelated stuff I've only made it an optdepend. If your package uses qdoc to generate docs you'll need to explicitely add clang as a makedepend. - there's been a huge header cleanup in Qt modules. Expect build failures for applications that rely on transitive includes instead of declaring all required headers. Those need to be fixed upstream by explicitely adding the missing includes.

1 0

[arch-dev-public] New build server in the US?
by Baptiste Jonglez 19 May '18

19 May '18

Hi, OSUOSL [1] in the US has several "new" refurb servers with dual Xeon E5-2660. Each machine has a total of 16 cores / 32 threads and 140 GB RAM, so that would make nice build machines. Would this be useful to the dev community? Soyuz is a bit overloaded at times, and people in the US/Canada might appreciate the lower latency. The hosting conditions are described here: http://osuosl.org/services/hosting/ Regarding money, OSUOSL works through donation: if we ask for a server and we have money, it would be nice to support them financially. I honestly have no idea about Arch's financial situation, or how soyuz is paid for in practice. Let's discuss this! Baptiste [1] http://osuosl.org

5 5

[arch-dev-public] dropping js38
by Eli Schwartz 24 Apr '18

24 Apr '18

The last package to depend on js38 was cjs, and with the completion of the cinnamon 3.8 rollout this too is ported to js52. There's no reason to continue to keep this in the repos AFAICT. ... On the topic of the various js* packages, we've had to rebuild some packages which used the /usr/bin/js tool when moving to js52. Having to patch the package to hardcode a specific version of js seems a bit awkward, perhaps we should move the js command from the js185 package (while we wait for *its* last user to be fixed) to a renamed js52 ==> js package, which would provide js52 for packages which link against a specific version instead of using the CLI? This would more closely match how we handle things like python, ruby, nodejs. -- Eli Schwartz -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Caution when moving packages built against glibc 2.27
by Evangelos Foutras 24 Apr '18

24 Apr '18

Care should be taken when building against glibc 2.27 (which is currently in [staging]). In particular: - While glibc 2.27 is in [staging], new rebuilds should not be started. - After glibc 2.27 migrates to [testing], packages built against it should remain in [testing] until glibc 2.27 lands in [core]. The above considerations must be taken into account because packages built against glibc 2.27 might depend on versioned symbols that are not found in glibc 2.26 and thus will not work. [1] [1] https://bugs.archlinux.org/task/58216

1 1