July 2017 - 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] Away until 18 Aug
by Antonio Rojas 29 Jul '17

29 Jul '17

It's vacation time. Will have intermittent internet access but no signing key. Feel free to fix/update anything, just make sure not to break Sage if you touch any of its dependencies.

1 0

[arch-dev-public] Hey everyone,
by Sven-Hendrik Haase 26 Jul '17

26 Jul '17

I'll be on vacation for 2 weeks starting today. Feel free to update my packages. Sven

1 0

[arch-dev-public] TeXLive 2017 packages are now available in [testing]
by Rémy Oudompheng 17 Jul '17

17 Jul '17

Hello, TexLive 2017 has been released at the beginning of the month and is now packaged in [testing]. No particular issue is expected when upgrading to this release. Note that a few packages disappear in this release, following upstream changes in structure: * texlive-genericextra (merged in texlive-core) * texlive-htmlxml (merged in texlive-core and formatsextra) * texlive-plainextra (merged in texlive-core) Pacman hooks for TeXLive, which were in texlive-bin, are now in texlive-core, which should fix bugs like FS50238, FS20423 and FS51918. I expect to move them to [extra] early July. Happy TeXing, Regards, Rémy.

2 3

Re: [arch-dev-public] Changing compilation flags
by Evangelos Foutras 08 Jul '17

08 Jul '17

On 7 July 2017 at 19:17, Jordan Glover <Golden_Miller83(a)protonmail.ch> wrote: > I'm surprised as it seemed to me that Daniel took it for granted that > patch like that will get accepted. Anyway it's hard for an outsider to > successfully submit anything to big upstream project. I hope you'll be more > lucky if/when you decide to upstream your pie/ssp patches. > The SSP/PIE patch is a bit of a hack and is specific to Arch and the architectures we support. As mentioned in the commit message, it's a temporary fix until upstream makes those parameters configurable at compile-time (or a better solution is found). This means it's not upstreamable. > It would be nice if makepkg have some conditionals i.e. : > > if cc=clang then > cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack > -fsanitize=cfi -fvisibility=hidden > > if cc=gcc then > cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check > There are multiple ways the compiler can be selected; two of them are: 1) exporting CC/CXX in the PKGBUILD and 2) the project's configure script picking one of the available compilers. makepkg can't realistically know which compiler is going to be used and thus must have only one set of flags that is supported by both GCC and Clang. On 7 July 2017 at 19:17, Jordan Glover <Golden_Miller83(a)protonmail.ch> wrote: > I'm surprised as it seemed to me that Daniel took it for granted that > patch like that will get accepted. Anyway it's hard for an outsider to > successfully submit anything to big upstream project. I hope you'll be more > lucky if/when you decide to upstream your pie/ssp patches. > > It would be nice if makepkg have some conditionals i.e. : > > if cc=clang then > cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack > -fsanitize=cfi -fvisibility=hidden > > if cc=gcc then > cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check > > -------- Original Message -------- > Subject: Re: [arch-dev-public] Changing compilation flags > From: evangelos(a)foutrelis.com > To: Jordan Glover <Golden_Miller83(a)protonmail.ch> > arch-general(a)archlinux.org <arch-general(a)archlinux.org>, Daniel Micay < > danielmicay(a)gmail.com>, Public mailing list for Arch Linux development < > arch-dev-public(a)archlinux.org>, joerg(a)netbsd.org > > Thanks for trying to push the change upstream. I"m sorry they weren"t > very receptive of it; your responses were on point and further > clarified our intended use case. > > I"m not sure what Joerg meant by saying "Arch Linux can"t do > compiler-specific flag definitions". He could be thinking of a regular > project that can check for supported compiler flags, but AFAIK that > concept is not readily transferable to distro-wide flags. (Even if it > was, it would also apply to stack-check and friends so it"s a weak > argument in my opinion.) > > At the end of the day, it"s not an issue to carry this patch > downstream in Arch. :-) > > >

1 0

[arch-dev-public] New Bug Wrangler: Eli Schwartz
by Florian Pritz 07 Jul '17

07 Jul '17

Hi, Eli Schwartz has just joined Doug as a bug wrangler and will help us deal with bugs even better. Welcome Eli! Florian

2 1

Re: [arch-dev-public] Changing compilation flags
by Evangelos Foutras 07 Jul '17

07 Jul '17

On 7 July 2017 at 16:39, Jordan Glover <Golden_Miller83(a)protonmail.ch> wrote: > FYI clang devs don't want to take 1 line patch adding another no-op flag > upstream. > https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html Thanks for trying to push the change upstream. I'm sorry they weren't very receptive of it; your responses were on point and further clarified our intended use case. I'm not sure what Joerg meant by saying "Arch Linux can't do compiler-specific flag definitions". He could be thinking of a regular project that can check for supported compiler flags, but AFAIK that concept is not readily transferable to distro-wide flags. (Even if it was, it would also apply to stack-check and friends so it's a weak argument in my opinion.) At the end of the day, it's not an issue to carry this patch downstream in Arch. :-)

1 0

[arch-dev-public] Outdated orphans
by Antonio Rojas 06 Jul '17

06 Jul '17

The following packages are orphan and outdated, some of them for months or even years, and some have been broken for a while (FS#54615). If you're interested, please adopt them and fix them, otherwise they should be removed so they can be properly maintained in AUR - xen (xenstore, xe-guest-utilities, python2-xenstore) - openvas (-cli,-libraries,-manager,greenbone) - ironpython - gdc (we already ship 2 other D compilers also unmaintained, do we need 3? - taskjuggler3 - xbase - xmind - ypbind,ypserv,yp-tools (dep of archboot, is it useful?)

2 2

[arch-dev-public] switching to systemd-stable
by Dave Reisner 06 Jul '17

06 Jul '17

Hey all, This should be pretty much a no-brainer, but wanted to be sure I wasn't missing anything. Systemd upstream publishes a "systemd-stable" repo [1] which branches at each tag and cherry-picks backports. I'd like to switch our systemd package to this repo to avoid some of the duplication of work that Jan, Christian and myself have done in the past. The repo sees a bunch more activity than what our own backporting strategy has been, and I see that as a positive. One potentially bikeshed-worthy question is versioning. Do we count commits and modify the pkgver every time we build from the repo, e.g. 233.23-1 (meaning pkgrel=1 of a v233 build containing 23 backports), or do we simply keep the base pkgver true to upstream and increment pkgrel every time we release, e.g. 233-5 (meaning pkgrel=5 of some build of the v233 stable branch). Regards, Dave [1] https://github.com/systemd/systemd-stable

8 11

[arch-dev-public] Changing compilation flags
by Allan McRae 05 Jul '17

05 Jul '17

Hi all, The results from the test-sec-flags [1] suite are in. Many thanks to those that wrote this and those that submitted results. I'm not going to list the summaries here, but the results show that at worst enabling a bunch of security flags in our packages will have a <1% impact on performance (and more likely a fraction of a percent). That means we will add all of these to our default CFLAGS/LDFLAGS etc. The changes are: 1) building gcc to enable PIE by default 2) add -z,now to LDFLAGS 3) and -fno-plt and -fstack-check to our CFLAGS Adding PIE means that programs get loaded at a random address, preventing an attacker from manipulating global data or hijacking control by reusing code. Without this, ASLR is ineffective. Enabling this by default in our compiler (there is a configure flag) means we will need to rebuild all packages with static libraries (which should be a fairly limited set). Adding -z,now to LDFLAGS disables lazy loading. This means all function symbols are loaded at startup (with minor performance hit), but that means our RELRO support will make everything ro instead of some of the things. Doing this enables us to use -fno-plt in our CFLAGS, which is a run-time optimisation allowing faster use of libraries. Adding -fstack-check to our CFLAGS guarantees stack overflows aren't exploitable. Note that any of these flags can be disabled in a PKGBUILD if really needed... But if that is the case, bug reports should be filed. Given an assumed lack of objection, I will enable the build flags in our pacman.conf and rebuild gcc to enable pie and put them in [staging] at the end of this week (what better way to celebrate Halloween). We will need a new devtools release then too. Then the packages with static libraries will need rebuilt. After that, I would like to see [core] completely rebuilt, and audited to ensure our CFLAGS/LDFLAGS are actually being used in the build. Cheers, Allan [1] https://www.archlinux.org/news/test-sec-flags-call-for-assistance/

6 26