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

[arch-dev-public] Replacing bzr with breezy
by Maxime Gauduin 04 Feb '20

04 Feb '20

Hi folks, As you may know bzr is python2 only, and most distros [0] [1] are switching over to a drop-in replacement fork named breezy [2]. The latest version just added python 3.8 support, so I pushed a package to [extra] [3]. I propose we add a symlink from bzr to brz in the breezy package, and conflict with/replace the bzr package so we can drop bzr, bzr- fastimport and python2-fastimport (fastimport is built in breezy) and leave in a world with three less python2 packages. Any objection? [0] https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883146 [2] https://www.breezy-vcs.org/ [3] https://www.archlinux.org/packages/extra/x86_64/breezy/ Cheers, -- Maxime

2 2

[arch-dev-public] mailman3/hyperkitty/postorius in the repos now
by David Runge 03 Feb '20

03 Feb '20

Hey all! I'm just on my way home from FOSDEM - train time, mail time ;-) I've spent the last weeks bringing the mailman3 ecosystem(!) to [community] and [community-testing] (~56 packages). Today I've added wiki pages for mailman3 [1] (it will replace the current mailman page once it's done by moving that to be 'mailman2' and eventually deleting it), hyperkitty [2] and postorius [3]. I've done initial integration tests with mailman3, hyperkitty and postorius and they "should just work"(TM). Before moving all the stuff to [community] and replacing the wiki page, it would be great to get some further integration testing with actual mail servers (note the expansion macro [4] in the mailman article) and importing of mailman2 data [5] [6] going. Any help is very much appreciated, as the switch requires quite the data migration and configuration changes for e.g. our own lists (the archives of some of them are pretty large). Additionally, the hosting aspects of both Hyperkitty and Postorius need some expansion as well (e.g. for Apache setups and for proper subdomain setups). Everyone, feel invited to install and test the applications and propose fixes and expansions to the documentation (or packages) as needed. Best, David [1] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman [2] https://wiki.archlinux.org/index.php/Hyperkitty [3] https://wiki.archlinux.org/index.php/Postorius [4] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Integrate_with… [5] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Migrate_from_m… [6] https://wiki.archlinux.org/index.php/Hyperkitty#Importing_mailman2_archives -- https://sleepmap.de

3 3

[arch-dev-public] Absent until next week
by Eli Schwartz 27 Jan '20

27 Jan '20

Due to a family wedding, I will be gone for a week, until late Monday Feb. 3 or Tuesday Feb. 4. I won't have internet other than limited mobile data, but can still be contacted via email/IRC, which I shall check semi-regularly. Sorry for the late notice. :) Feel free to update anything that needs updating while I'm gone. -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Package openvpn in [core]?
by Christian Hesse 27 Jan '20

27 Jan '20

Hello everybody, currently the package openvpn is located in our [core] repository and it's like that since the beginning of time. [0] Following a discussion on IRC and our definition for official repositories [1] we think there is no reason to have it there. Thus I would like to move it (and its dependency pkcs11-helper) to [extra]. If you have any concern please raise your hand now! [0] https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/openvpn&… [1] https://wiki.archlinux.org/index.php/Official_repositories#core -- 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);}

3 3

[arch-dev-public] FOSDEM Dinner 2020
by Morten Linderud 21 Jan '20

21 Jan '20

Yo! Last year at FOSDEM we held a dinner with 15 people, some members from the Arch team and some users that wanted to join. It was a great event and people had a nice dinner with some nice chats afterwards on various pubs. For this year I plan to do the same with some changes. First of all, we are going to be holding it on saturday around 18:00 - 19:00 as opposed to friday. This is to ensure people are able to arrive friday evening, AND keep their phones after their dinner. I'm still looking for mine :/ To make it managable I'll cap the attendees to around 15 people. Priority for members of the Arch team (developers, trusted users and support staff). Any free spots after this can be taken by anyone interested :). Send an email *offlist* so I have some ability to keep track and inform you about further booking details. The users requesting spots will get a headsup the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions :) --- I have again CC'ed arch-dev-public since I don't actually know how many people watch arch-events (hinthint subscribe!). Sorry for the noise, and please do tell me if we are better off not cross-posting emails like these :) -- Morten Linderud PGP: 9C02FF419FECBE16

2 3

[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