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

[arch-dev-public] rsync & bundled zlib
by Christian Hesse 16 Jan '20

16 Jan '20

Hello everybody, to date we ship rsync with bundled zlib to keep compatibility with rsync up to version 3.1.0 and it's old-style --compress option. This is no longer required with rsync 3.1.1, which was released on 2014-06-22 - nearly six years ago! The bundled zlib carries some security issues, so time to act - one way or another. Even old-stable Debian Jessie [0] has rsync version 3.1.1. So any concern to finally drop bundled zlib and use system zlib? I would suggest to post a news item, feel free to give thoughts and feedback. --- >8 --- rsync compatibility Our `rsync` package was shipped with bundled `zlib` to provide compatibility with old-style `--compress` option up to version 3.1.0. Version 3.1.1 was released on 2014-06-22 and is shipped by all major distributions now. So we decided to finally drop the bundled library and ship a package with system `zlib`. Go and blame those running old versions if you encounter errors with `rsync 3.1.3-3`. --- >8 --- [0] https://packages.debian.org/de/jessie/rsync -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

4 5

[arch-dev-public] Guidelines for news posting
by Sven-Hendrik Haase 16 Jan '20

16 Jan '20

Hi all, in light of recent events, we had a little get-together in #archlinux-staff to hack on an initial suggestion on guidelines for news posting. If we can agree on these, they should be added on the news posting page on archweb (and perhaps somewhere on the wiki). The draft we came up with is this: Every news post needs to have a corresponding draft submitted to arch-dev-public and wait for feedback for at least 24 hours unless: 1. it is urgent (and would be too late after 24 hours) 2. it is a simple --overwrite rule, or 3. there are strong reasons for the team member posting the draft to believe that it should not be visible to the public before it is announced. In this third case, the draft should be submitted to the staff(a)lists.archlinux.org ML instead. Happy to hear about feedback. Cheers, Sven

2 3

[arch-dev-public] Todos for language specific rebuilds
by Christian Rebischke 13 Jan '20

13 Jan '20

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

6 7

Re: [arch-dev-public] Todos for language specific rebuilds
by Anatol Pomozov 12 Jan '20

12 Jan '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On 2020-01-12 at 00:04, arch-dev-public(a)archlinux.org wrote: > On 1/10/20 4:42 PM, Christian Rebischke via arch-dev-public 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: > > > > * More people help rebuilding the packages.' > > What help is needed? If this is just about having more people sed the > pkgrel variable with "$pkgrel + 1", then try to build it, more people > doesn't actually help. We have automated rebuilders which are very > capable in this regard. > > > * Every maintainer gets informed about the rebuild. > > I agree with you that this is indeed a problem, and I would like to > propose a pretty simple solution. Let's post on arch-dev-public to give > people a heads-up. > > This means even if your package failed to be detected for rebuilding and > would never appear on any TODO, you as a maintainer know that it > happened and can manually rebuild your package. > > > * Maintainers have the possibility to test the packages. > > At least for the python rebuilds, the process of rebuilding the > ecosystem is long and painfully drawn out, *because* packages with > failing testsuites cannot be rebuilt automatically and go onto a TODO > list of broken packages. > > Given this thread started because we just rebuilt ruby, can I assume > that PKGBUILDs for ruby packages are in the general habit of not > containing check() functions for running unittests? Either because > upstream does not have unittests or because they are not being run? > > If packages have upstream unittests but don't run them, then the > maintainer of the package has been derelict in his or her duty. > > If packages do NOT have upstream unittests, then this is unfortunate, > and I don't currently have an answer for what we should do. :( > > > 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). > > It's a website submission form that expects you to write some > explanatory message, then fill in a newline-separated list of pkgnames. > Any rebuilder must by definition have the latter, even if that rebuilder > is "I scrolled through archweb and did it all manually by flipping back > and forth between my terminal and my browser". > > No "tool for creating todos" need exist. Ask instead about tools for > enumerating language dependencies. > > ... > > For python, it's pretty simple. > > pkgfile -d '/usr/lib/python3.8/' > > For ruby, it's also pretty simple: > > pkgfile -d '/usr/lib/ruby/' Here are the instructions that I used to find the ruby packages https://gist.github.com/anatol/670a2768a97789d6a96b33010b7fedca -----BEGIN PGP SIGNATURE----- Version: FlowCrypt 7.4.2 Gmail Encryption Comment: Seamlessly send and receive encrypted email wsFcBAEBCgAGBQJeGmgKAAoJELAoVO11Pg8fwTsQAJtOyNvia5wXkkTsdjrQ LLkLRw2EF79mMbJa+zN6/H7m/lJAIdZKXFjWmhar3lt+52d0J+7+WHPrqHH0 151hpuJ6SJpceGDkzbfIST9/i+++HcUB6a9vDcJPEx8RqYQFMPH/4JxGndCR Dg7bi2f9PzmYsv9KkZ6JsJ13Z/jRfiVozGf0J9b+xi79Z5Y5RMM91Q2hp8gR 6HFRw+S8+0j5P+1MlDlSSjPmflvC3wsYDRqcDZuaXtArmqb1BiGAK6s6d4aQ L11LQSdP8clgYfGPJpk4U37SDSyrkTaBM5yWQLPaKVB7DY2Z81OGd3Z34tMj QWsh/LZjgqtEOl+WkGcF2ykSa+mjpdyxrttotDh6Mwwa+7YFNxWMQiSO8Hmd Z1iI3SCzIhQ33t/3raE0MDSJM8nEQwwrkyI2nr0C2BFUEIwMkiRkcLr3KDwf MQI3Q9X3A0Fo5xwzWcEEjbJjwjGz9fzPcDh0JeOUs/e9Ck1TL/n4qwqhPeUr kJFrrzEAD6YcXCTdbudHFnbmrdDd0wdTpb2SAYZuKWhYusEMWn1oxDK6TnLe 5ufVTXP9uQyG5xoEUX95L4S0GAGqJ6jU9dY+B1TTfRZg+bG6nq+FdpverzHB WVN9opo7WqL8sE1fifViBbWo20KV0BCv3vUyFFBYkCLVcoIWgeeLHFZUegmr p/nl =4pkk -----END PGP SIGNATURE-----

1 0

[arch-dev-public] Adding a "posix" metapackage
by Eli Schwartz 09 Jan '20

09 Jan '20

After a bit of research work and making sure one or two things have been properly packaged, I've developed a PKGBUILD which ensures that a system has the POSIX shell and utilities (XCU) section installed. I believe this is an interesting thing to track, and people will want to know they have it installed... in aid of this, I've gotten two major holdouts packaged a while back -- pax (thanks to dbermond) and ncompress. I'd like to add this package to community, although given it's never been in the AUR before, it's never had AUR votes... One of the advantages of having this metapackage is that someone can, while installing arch, `pacman -S posix-user-portability` and get essentially everything one would expect to have available on a unix-like platform, most notably, the interesting parts of the base group that no longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed. I've only included XCU for now, because the system interfaces and headers are a bit out of scope for me to package and replace in the event that they'd be missing anything... and also because I'm mainly interested in the POSIX toolset itself. That being said, I'd certainly be open to suggested improvements, should anyone have recommendations for expanding the scope. Thoughts? For reference, here is my PKGBUILD: https://paste.xinu.at/m-XoggqFGE/ And reproduced here: # Maintainer: Eli Schwartz <eschwartz(a)archlinux.org> # The list of utilities can be found at # https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html # Not all utilities are required: if the synopsis is boxed up and annotated # with a code, it is only needed for that code. Examples: user portability, # XSI, Software Development, C Development. Some of these groups were # implemented here too, though almost certainly the only important ones are UP # and XSI. pkgbase=posix pkgname=('posix' 'posix-xsi' 'posix-user-portability' 'posix-c-development' 'posix-software-development') pkgver=2017 pkgrel=1 pkgdesc="metapackage providing the POSIX shell and utilities (XCU)" arch=('any') url="https://pubs.opengroup.org/onlinepubs/9699919799/" depends=('at' # at batch 'awk' 'coreutils' # basename cat chgrp chmod chown cksum comm cp csplit cut date dd df dirname # du echo env expand expr false fold head id join ln logname ls mkdir mkfifo # mv nice nohup od paste pathchk pr printf pwd rm rmdir sleep sort split stty # tail tee test touch tr true tsort tty uname unexpand uniq unlink wc who 'bc' 'diffutils' # cmp diff 'cronie' # crontab 'ed' 'file' 'findutils' # find xargs 'glibc' # gencat getconf iconv locale localedef 'grep' 'util-linux' # kill logger mesg newgrp renice write 'cups' # lp -- sorry! 'm4' 's-nail' # mailx 'man-db' # man 'patch' 'pax' 'procps-ng' # ps 'sed' 'sh' 'binutils' # strings 'ncurses' # tabs tput # 'time' # is a shell builtin too 'sharutils' # uudecode uuencode ) package_posix() { : } package_posix-xsi() { pkgdesc+=": X/Open System Interfaces" depends=('posix' 'util-linux' # cal ipcrm ipcs kill 'ncompress' # compress 'coreutils' # df link nl od 'psmisc' # fuser 'procps-ng' # ps 'ncurses' # tabs 'gzip' # uncompress (but not compress...) zcat 'uucp' # uucp uustat uux # missing: cflow cxref # missing SCCS: admin delta get prs rmdel sact sccs unget val what ) install=xsi.install } package_posix-user-portability() { pkgdesc+=": User Portability Utilities" depends=('posix' 'vi' # ex vi 'util-linux' # more 'inetutils' # talk ) } package_posix-c-development() { pkgdesc+=": C-Language Development Utilities" depends=('posix' 'gcc' # c99 'flex' # lex 'bison' # yacc ) } package_posix-software-development() { pkgdesc+=": Software Development" depends=('posix' 'binutils' # ar nm strip 'ctags' 'make' ) } # xsi.install post_install() { cat << '__EOF__' warning: XSI compliance is not 100% complete, not all tools are packaged. - The SCCS development tools are not available, but may be obtained from the AUR in the event you believe anyone still uses it. - The cflow package can likewise be obtained from the AUR. - A cxref package may need to be created, if there are interested parties. __EOF__ } -- Eli Schwartz Bug Wrangler and Trusted User

5 10

[arch-dev-public] Killing Python 2 (v2)
by Jelle van der Waa 07 Jan '20

07 Jan '20

Hi All, 2020 happened and Python 2 is very much still alive, even worse there will be an update in April. However we should actively strive to get rid of Python 2 before it. Some upstreams are (still) working on porting to Python 3 such as Kodi, inkscape, mercurial and many more but for packages with dead upstreams and being unrequired I propose we remove them. For packages still providing python2 functionality such as vim and others I propose we remove python2 support to actively to discourage people using it. Dropping non-ported python2 packages: * rox - python2, dead and GTK2 * wifite - upstream dead * shedskin - python2 specific, won't be updated * jmc - dead upstream * pydb - python debugger (python2 specific) * pyrex - dead upstream * mcomix - dead upstream * singularity - dead upstream * pathological - dead upstream * armagetronad - dead upstream, optional dep can be removed * ming - no python2 compatibility * ipcheck - dead upstream * mediaproxy - dead upstream * wicd/wicd-gtk - dead upstream, better alternatives available * sgmltools-lite - dead upstream # Remove python2 support * pycharm-community-edition - remove python2 support * vim - remove python2 support * graphviz - remove python2 bindings or update to python3 * notmuch - switch to python3 bindings * libproxy - remove python2 bindings * many others! Greetings, Jelle van der Waa

8 12

Re: [arch-dev-public] Restricting ability to post news items
by Gaetan Bisson 06 Jan '20

06 Jan '20

[2020-01-06 16:48:48 -0300] Giancarlo Razzolini: > I'm moving this to staff@, please stop replying on a-d-p. Doing dirty laundry > in public is not necessary. And I'm moving this back to arch-dev-public because most staff aren't concerned with posting news items. Besides, there's nothing secret about this and I don't believe in hiding policy discussions out of the public eye. > For making that argument, you must first demonstrate that the news *wasn't* > used responsibly or there was any abuse of any kind. My reply was only to your suggestion that "everything should be written down". For clarity, let me recall how the conversation went: - Allan: Do we really need to write down everything? - Giancarlo: Yes, we do. - Me: No, we don't. As you can see I expressed no opinion on whether the latest news item was responsible. But since you ask, I think that question is moot since it's already been posted. However I deeply deplore that it was not discussed beforehand on arch-dev-public first. > Also, you're implying that this particular news entry wasn't thought through, > when in fact I can preset mounts of evidence to the contrary. Just a look at the > logs for #archlinux-tu for the 3th and 4th will tell you that. I don't have access to #archlinux-tu. Even if I did, I would not have been constantly monitoring the channel during the 3th and the 4th. What I don't understand is why you don't advocate the use of a medium of communication that encompasses both devs and TUs and allows people in different timezones or with different schedules to contribute. > If we are going to start *punishing* people, you damn right we *need* > guidelines for it. I strongly disagree. We don't need rules and we don't need punishments. We just entrust staff members with powers and expect them to use said powers responsibly. If they don't, we discuss on a case-by-case basis whether to strip them of the power they abused. Cheers. -- Gaetan

1 0

[arch-dev-public] Restricting ability to post news items
by Allan McRae 06 Jan '20

06 Jan '20

Hi all, Following the roll out of the base metapackage, and its poorly written news post, we agreed that all new posts should have a draft posted to arch-dev-public. There was a potential exclusion for trivial --overwrite posts [1]. This was followed for the Xorg update. It was not followed for the zstd update. Given people have shown an inability to follow simple instructions, I am proposing a restriction on the ability to make news posts. This can either be a bulk restriction now, or just removing anybody who does not follow the rule from ever making a news post again. Allan [1] and why have we had so many missing library symlinks lately... surely checkpkg detects all the missing symlinks compared to previous packages.

7 11

[arch-dev-public] cleanup dead Xorg packages
by Andreas Radke 06 Jan '20

06 Jan '20

I've created a bug[1] to follow a long overdue Xorg cleanup to drop legacy and dead code from our packages. This will require fixing makedepends in a 2nd step. I will do the most work over the next days/weeks. This all didn't fit well into a single ToDo list. If you find more really dead Xorg packages add it please to the bug tracker with a link to its removal. Use the mailing list for further discussion if needed when you think a certain feature isn't widely used and should be dropped as well. -Andy [1] https://bugs.archlinux.org/task/64892

10 17

Re: [arch-dev-public] Killing Python 2 (v2)
by Giancarlo Razzolini 02 Jan '20

02 Jan '20

Em janeiro 2, 2020 14:10 Brett Cornwall escreveu: > On 2020-01-02 13:43, Giancarlo Razzolini via arch-dev-public wrote: > > Er, the first end-of-life was five years ago and was then extended to > 2020 to help accommodate the transition. I think a five-year grace > period was long enough already... > While I agree with that, it doesn't change the fact that having python2 lint and syntax checking tools will *still* be helpful in the foreseeable future. There are lots of reasons, educational ones, proprietary legacy code ones, etc. Let's not throw the baby out with the water. Just saying, if there's an opportunity to keep linters and syntax checkers/highlighters that don't necessarily require python2, it's not doing any *real* harm, provided they still are maintained projects. Will we eventually remove those as well? Sure. But the ability to read python2 code properly is independent of the ability to *run* python2 code. They are separate things. Regards, Giancarlo Razzolini

1 0