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

[arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 23 Feb '20

23 Feb '20

I don't run nvidia-390xx on any of my devices. I would appreciate it if somebody could take those drivers. I will continue maintaining the mainline nvidia package.

2 1

[arch-dev-public] Python 2 modules
by Allan McRae 17 Dec '19

17 Dec '19

Hi all, Python 2 reaches End of Life on 2020-01-01. We currently have >950 python2 modules in the repos. A lot of these are not used by any other package in the repositories. I think we should work towards removing them. Leaving only python2 modules that are really required by other software, highlights what needs worked on to port to python3. Note Fedora is doing a similar removal for F30: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal What are opinions on this? Should I make a TODO list? Below is a list of python2 modules that are a dependency for any other package. I did not check makedepends and I did not check recursively to build this list. python2-acme python2-antlr2 python2-anyjson python2-anytree python2-apache-libcloud python2-apispec python2-argcomplete python2-argon2_cffi python2-argparse python2-args python2-arrow python2-aspectlib python2-astor python2-atspi python2-aubio python2-audit python2-augeas python2-autobahn python2-autopep8 python2-backports.lzma python2-basemap python2-betamax-matchers python2-betamax-serializers python2-binary-memcached python2-biopython python2-bitvector python2-blist python2-blosc python2-bluepy python2-bottle python2-bottleneck python2-braintree python2-breathe python2-bsddb python2-btchip python2-btrees python2-cached-property python2-caja python2-cchardet python2-celery python2-chai python2-chameleon python2-characteristic python2-cjkwrap python2-click-log python2-click-threading python2-cloudflare python2-cmarkgfm python2-colander python2-colorclass python2-configargparse python2-construct python2-couchdb python2-cram python2-crayons python2-cryptography-vectors python2-cson python2-cssselect2 python2-cssutils python2-cx_freeze python2-d2to1 python2-daemon python2-daemonize python2-datrie python2-ddt python2-digitalocean python2-discid python2-distutils-extra python2-django python2-dnslib python2-dockerpty python2-docopt python2-docs python2-doublex-expects python2-dpcontracts python2-dropbox python2-editdistance python2-egenix-mx-base python2-elasticsearch-curator python2-email-validator python2-envisage python2-eric python2-ethtool python2-evdev python2-exam python2-exiv2 python2-eyed3 python2-factory-boy python2-fastpbkdf2 python2-faulthandler python2-flake8-blind-except python2-flake8-debugger python2-flaky python2-flask-gravatar python2-flask-htmlmin python2-flask-jwt python2-flask-mail python2-flask-migrate python2-flask-paranoid python2-flask-restful python2-flask-security python2-flask-socketio python2-flask-talisman python2-flask-wtf python2-flexmock python2-flickrapi python2-flup python2-fonttools python2-foolscap python2-fpconst python2-freezegun python2-fs python2-funcy python2-furl python2-fxa python2-gasp python2-gcp-devrel-py-tools python2-gdal python2-gdata python2-genshi python2-genty python2-geoip python2-gevent-websocket python2-gflags python2-gitpython python2-gnupg python2-gnupginterface python2-gnuplot python2-gpgme python2-grequests python2-gtkspellcheck python2-gudev python2-h2 python2-h5py python2-h5py-openmpi python2-hacking python2-harparser python2-helper python2-hexdump python2-hglib python2-httpretty python2-hunter python2-hypothesis python2-i3-py python2-ibm-db-sa python2-icalendar python2-igraph python2-importlib_resources python2-inet_diag python2-invoke python2-iocapture python2-ipdb python2-irc python2-isomd5sum python2-iwlib python2-jieba python2-js2py python2-jsbeautifier python2-json-logger python2-jsonrpclib-pelix python2-kaitaistruct python2-kajiki python2-kaptan python2-keybinder2 python2-keyrings-alt python2-keyutils python2-kitchen python2-kivy python2-klein python2-langdetect python2-language-server python2-lark-parser python2-levenshtein python2-libappindicator python2-libarchive-c python2-libforensic1394 python2-librabbitmq python2-libtmux python2-linux-procfs python2-llfuse python2-logbook python2-logilab-common python2-lttngust python2-m2r python2-magic python2-mamba python2-manhole python2-manuel python2-marisa python2-marshmallow python2-memcached python2-mimerender python2-mockito python2-mongoengine python2-mongomock python2-mpd2 python2-munkres python2-musicbrainz2 python2-mygpoclient python2-mysql-connector python2-nbxmpp python2-ndg-httpsclient python2-neovim python2-netcdf4 python2-netcdf4-openmpi python2-nine python2-nltk python2-nose2 python2-nose-cover3 python2-nose-exclude python2-nose-fixes python2-nose-randomly python2-nose-show-skipped python2-nosexcover python2-oauth2client python2-objgraph python2-olefile python2-openapi-spec-validator python2-openpyxl python2-openstackclient python2-oslo-concurrency python2-oslo-log python2-oslosphinx python2-oslotest python2-ovirt-engine-sdk python2-owslib python2-pacparser python2-pam python2-pandas-datareader python2-pandocfilters python2-parse python2-parsedatetime python2-parsel python2-paste python2-pastedeploy python2-pbkdf2 python2-pdoc python2-peewee python2-perf python2-periphery python2-phonenumbers python2-piexif python2-pifpaf python2-pigar python2-pint python2-pipenv python2-pkgconfig python2-planout python2-plop python2-pmw python2-podcastparser python2-polib python2-poppler python2-positional python2-poster python2-prance python2-prctl python2-pretend python2-priority python2-process-tests python2-profilestats python2-progressbar python2-prometheus_client python2-psycopg2 python2-ptrace python2-pudb python2-pyaes python2-pyalsa python2-pyamf python2-pyaml python2-pyaudio python2-pybluez python2-pychm python2-pycontracts python2-pycosat python2-pycountry python2-pycuda python2-pydbus python2-pydns python2-pydocstyle python2-pydot python2-pyelftools python2-pyftpdlib python2-pygal python2-pygeoip python2-pygit2 python2-pygithub python2-pyglet python2-pygpgme python2-pygraphviz python2-pyicu python2-pyliblo python2-pylibmc python2-pylons-sphinx-themes python2-pymediainfo python2-pynamecheap python2-pynormaliz python2-pyodbc python2-pyopencl python2-pyotp python2-pyqtwebengine python2-pyquery python2-pyro python2-pyrss2gen python2-pyrtf python2-pysaml2 python2-pysendfile python2-pyserial python2-pysimplesoap python2-pysmbc python2-pysnmp python2-pysrt python2-pystemmer python2-pyswip python2-pytables python2-pytddmon python2-pytest-benchmark python2-pytest-cov python2-pytest-django python2-pytest-expect python2-pytest-flake8 python2-pytest-httpbin python2-pytest-isort python2-pytest-localserver python2-pytest-mock python2-pytest-randomly python2-pytest-relaxed python2-pytest-rerunfailures python2-pytest-runner python2-pytest-sugar python2-pytest-timeout python2-pytest-twisted python2-pytest-virtualenv python2-pytest-xdist python2-pytest-xprocess python2-pythondialog python2-pyudev python2-pyusb python2-pywinrm python2-pyxrootd python2-qiniu python2-qpid-proton python2-qrcode python2-qrencode python2-queuelib python2-rangehttpserver python2-rawkit python2-rdflib python2-recommonmark python2-redis python2-rednose python2-repoze.profile python2-requests-credssp python2-requests-file python2-requests-ftp python2-requests-hawk python2-requests-kerberos python2-requests-mock python2-requests-ntlm python2-responses python2-restkit python2-rethinkdb python2-ropper python2-rply python2-rst2pdf python2-salsa20 python2-scapy python2-schedutils python2-scikit-learn python2-scour python2-scripttest python2-scrypt python2-seaborn python2-selenium python2-semantic-version python2-send2trash python2-serpent python2-service_identity python2-setuptools-git python2-setuptools-markdown python2-setuptools-scm python2-shapely python2-signedjson python2-simplebayes python2-snakefood python2-soappy python2-socketio python2-sortedcontainers python2-sparqlwrapper python2-sphinxcontrib-bibtex python2-sphinxcontrib-newsfeed python2-sphinx-testing python2-split python2-sshtunnel python2-statsmodels python2-stopit python2-structlog python2-subunit2sql python2-suds python2-sure python2-swiftclient python2-sword python2-sybil python2-tabulate python2-tagpy python2-tarantool python2-tblib python2-tenacity python2-terminado python2-terminaltables python2-testfixtures python2-testrepository python2-testresources python2-texttable python2-tftpy python2-tlsh python2-toposort python2-tox python2-traitsui python2-transaction python2-treq python2-trustme python2-tweepy python2-twine python2-typogrify python2-ukpostcodeparser python2-uncertainties python2-unicorn python2-unittest-mixins python2-unittest-xml-reporting python2-urwidtrees python2-vcrpy python2-vcversioner python2-venusian python2-vobject python2-webcolors python2-webpy python2-whatever python2-whelk python2-whitenoise python2-wikipedia python2-wsaccel python2-wsgi-intercept python2-wsgiproxy2 python2-wsproto python2-xapp python2-xlrd python2-xlsxwriter python2-xlwt python2-xpybutil python2-yapf python2-yara python2-z3 python2-zbar python2-zconfig python2-zope-annotation python2-zope-configuration python2-zope-copy python2-zope-security python2-zope-testing python2-zope.testing python2-zope-testrunner

5 6

[arch-dev-public] Proposal: minimal base system
by Levente Polyak 18 Mar '19

18 Mar '19

# Proposal There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. The current way of defining a minimal system via a group is non-optimal for the following reasons: - A group can’t enforce installation of packages when being extended or modified - The current base group contains lots of unneeded packages - Manually getting rid of some of the packages may result in broken deps To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade. Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all. This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system. The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime Possible candidates for the virtual package: #### Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils #### Distro requirements: - licenses - pacman - systemd #### Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz #### Some networking tools - iputils - iproute2 ## Alternative Another approach would be, assuming we want to properly support tiny containers, to reduce the above list even further to a bare minimum of running pacman and not omit any further 1st level runtime dependencies in our packages. ## Short summary Required: - Use a virtual package instead of a group for the bare minimum Option 1: - Define a base-system virtual package as a required set of packages containing something like a POSIX interactive runtime environment Option 2: - Reduce the set even further to aid tiny containers and don't omit any other 1st level runtime dependency in packages - We could additionally still have a smaller set for a POSIX interactive runtime environment for convenience PS: Please focus on the abstract before bikeshedding whether single packages should or should not be added cheers, Levente

11 31

[arch-dev-public] Edit /etc/php/php.ini config file in chroot
by NicoHood 12 Feb '19

12 Feb '19

Hi, I am using devtools to create a package with php scripts. It uses composer to build the package. I get the error: The requested PHP extension ext-iconv * is missing from your system. Install or enable PHP's iconv extension. This can be solved by editing the config file and add: extension=iconv The config file is only accessible by root. How do I edit this config file within the PKGBUILD if its build by devtools? Any idea? ~Nico

3 2

[arch-dev-public] Archweb migration
by Jelle van der Waa 08 Feb '19

08 Feb '19

Hi All, Tommorow night (CET) I will update archweb (archlinux.org) to Python 3. We've already tested it on a staging server and it seems to work well so tommorow I'll update it on our main server. This will mean that archlinux.org will be unavailabe for ~ 30 minutes since the upgrade requires some manual work with removing and creating a new virtualenv. -- Jelle van der Waa

1 1

[arch-dev-public] Improving overall experience for contributors follow up
by Jelle van der Waa 06 Feb '19

06 Feb '19

Hi, I still believe we should take some initiative on thse issues. What we have so far is: - Getting involved page, not sure where it's linked from? Only findable on the wiki. [1] Which links to a nice list of projects with an already dedicated irc channel and mailing lists. (I was not even aware of #archlinux-projects). But does anyone ever find this page? I think we should at least link it from archlinux.org. - The mozilla idea, I'm up for it? Should we host it under whatcanidofor.archlinux.org? Note that this also requires some effort from the team's side. We should however keep our bugtracker tidy and maybe label "new contributor" tickets since this is quite crucial to get new people in. I however have also some thoughts on things which these days have no tickets, but could be worked on for example: - revamping the Ruby guidelines. They should be as nice as the Python ones - Hardening our custom systemd services and creating bugs with patches, for example grafana has hardening applied now. [5] - Man pages for more devtools binaries. I'm quite sure others others have such projects on their mind which are not publicly findable yet. (sogrep to devtools for example) [1] https://wiki.archlinux.org/index.php/Getting_involved [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Projects [3] https://github.com/archlinux/archweb/issues [4] https://github.com/archlinux/pyalpm/issues [5] https://git.archlinux.org/svntogit/community.git/tree/trunk/grafana.ser= vice?h=3Dpackages/grafana P.S. sorry for splitting up into a new thread, but it seems replying makes spamassasian mark my reply to the thread as spam. -- Jelle van der Waa

3 2

[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