Re: [arch-dev-public] Add active Python versions to the repos
Am Sat, 21 Nov 2020 14:34:24 + schrieb Filipe Laíns via arch-dev-public : > Does anyone have any big issue with this? What are your thoughts? > > [1] https://www.python.org/downloads/ > > Cheers, > Filipe Laíns -1 Arch is yours. Whoever needs more and older releases on the system - just do it yourself! In the past we said "use abs and AUR - Arch is the base to make it your own". I don't want to see users raising bugs that something doesn't work with an older version of python. And I don't want to see these requests pop up every now and then to add even more stuff in different versions. It's sad enough we still have python2 and gtk2 around. To have gcc9 around and other duplicates is not what I want to see growing in Arch. I don't want to see our distribution transformed into another Debian. -Andy pgp6EiOKQF09B.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] [xorg-server] from testing repo may need manual intervention
We've started to build xorg-server packages form stable git branch again to pull pending bug fixes and an uncertain release date. A minor git package version numbering issue may prevent automatic future updates. In case you have already installed version 1.20.9+21+g5c400cae1-1 from testing repo today please run pacman -Syuu to receive a fixed version 1.20.9.r21.g5c400cae1-2. -Andy pgpXFFqCuEADX.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Autumn extra cleaning
Am Mon, 5 Oct 2020 07:16:14 +0200 schrieb Sven-Hendrik Haase via arch-dev-public : > Hey everyone, > > It was suggested as part of this year's spring cleanup of [community] > that we should be have a cleanup in [core]/[extra] and move packages > downwards into [community]. > > This round only concerns [extra] packages. > > Devs that want the packages in [extra], please adopt packages, and TUs > can notify which packages they are interested to maintain in > [community] > > Orphaned packages in [extra]: > > geeqie Adopted. > xorg-font-util > xorg-xfontsel > xorg-xlsfonts Adopted. -Andy pgp4umw7ZQSPr.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] help wanted / IPP based printing/scanning
There's some major effort going on to move from driver based scanning and printing to driverless scanning and printing both based on IPP specifications offered by newer devices. While IPP based printing is already there for some time and usable with cups+cups-filters [1] there's more work going on recently for IPP based scanning lately. There are a few projects we should probably support and add to our repos. I'm thinking about adding Sane-airscan [2][3] to extra. There's also a new ipp-usb proxy to allow IPP protocol access with USB connected printers and scanner as well [4][5]. I've prepared a simple package here of this one. Sadly my own printer is has a broken IPP implementation and thus can't be used with driverless printing [6]. My scanner is an old extra devices with plain usb connection. Both devices keep working well and I have no plan to replace them. So I cannot test anything of the new IPP stuff. If there's desire to have the new IPP stack fully available form our repos I can do the packaging because it's heavily related to recent multidevices and openprinting.org projects. But any help is welcome and I would prefer someone to become a backup and co-maintainer. If somebody has interest to help out here and maybe owns a modern IPP based multidevice please drop me a line. If nobody steps up or complains I plan to add sane-airscan and ipp-usb and maybe more if needed. -Andy [1] https://wiki.debian.org/CUPSDriverlessPrinting [2] https://github.com/alexpevzner/sane-airscan [3] https://aur.archlinux.org/packages/sane-airscan/ [4] https://github.com/OpenPrinting/ipp-usb [5] https://lists.debian.org/debian-printing/2020/07/msg0.html [6] https://github.com/apple/cups/issues/5693 pgpNmwvBwg5cA.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Thu, 2 Jul 2020 13:00:27 +0200 schrieb Baptiste Jonglez : > This is only midly annoying because I should have cleaned those up > long ago, but maybe put a notice on the website about this change? > > > Baptiste Everything in our repos has been fixed to allow a smooth -Syu upgrade path. We don't post news items for every package we remove (here xorg-font-utils) or split/rename (-alias packages here). That's why the discussion happens here before. We are not responsible for AUR stuff or custom packages. And in this case these packages had broken dependencies long before this package renaming/split happened. A simple pacman -Qm check will also show what happened to our repos. We expect Arch users to follow this public mailing list here and fix and rebuild related custom packages. -Andy pgpJgNmQGv3vb.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Fri, 26 Jun 2020 12:27:00 +0200
schrieb Andreas Radke via arch-dev-public
:
> Am Fri, 26 Jun 2020 12:15:54 +0200
> schrieb Andreas Radke via arch-dev-public
> :
>
> [...]
>
> We could also split the alias package or even drop it and add its
> source to the related fonts packages each building and including their
> own alias file.
>
> -Andy
I'm going to remove the unneeded dependency on xorg-fonts-alias package
from various font packages where it doesn't belong.
It only provides alias files for few Xorg fonts. I'm still thinking
about dropping the xorg-fonts-alias package. I'd prefer to put its
alias files into the corresponding
xorg-fonts-{100dpi,75dpi,cyrillic,misc} packages to avoid confusion and
drop it then.
In a 2nd step I'll make libfontenc depend on xorg-fonts-encodings as
stated in Xorg gitlab repo and will cleanup if something depends on
the encodings package.
Are there other font related tasks pen
-Andy
pgpq6tF3ADHIM.pgp
Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Fri, 26 Jun 2020 12:27:00 +0200
schrieb Andreas Radke via arch-dev-public
:
> Am Fri, 26 Jun 2020 12:15:54 +0200
> schrieb Andreas Radke via arch-dev-public
> :
>
> [...]
>
> We could also split the alias package or even drop it and add its
> source to the related fonts packages each building and including their
> own alias file.
>
> -Andy
I'm going to remove the unneeded dependency on xorg-fonts-alias package
from various font packages where it doesn't belong.
It only provides alias files for few Xorg fonts. I'm still thinking
about dropping the xorg-fonts-alias package. I'd prefer to put its
alias files into the corresponding
xorg-fonts-{100dpi,75dpi,cyrillic,misc} packages to avoid confusion and
drop it then.
In a 2nd step I'll make libfontenc depend on xorg-fonts-encodings as
stated in Xorg gitlab repo and will cleanup if something depends on
the encodings package.
Are there other font related tasks pending?
-Andy
pgpU2CjeaFe8c.pgp
Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
This ToDo list has been finished. I've removed xorg-font-utils from extra repo. Custom/AUR font packages should be fixed dropping their dependency on it to allow removing it from system. -Andy pgphSq88AyldY.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Fri, 26 Jun 2020 12:15:54 +0200
schrieb Andreas Radke via arch-dev-public
:
> Am Fri, 26 Jun 2020 16:56:03 +0800
> schrieb Felix Yan via arch-dev-public :
>
> [...]
>
> xorg-fonts-alias should only be required by the related
> xorg-fonts-{100dpi,75dpi,cyrillic,misc} packages.
>
> xorg-fonts-alias /usr/share/fonts/100dpi/fonts.alias
> xorg-fonts-alias /usr/share/fonts/75dpi/fonts.alias
> xorg-fonts-alias /usr/share/fonts/cyrillic/fonts.alias
> xorg-fonts-alias /usr/share/fonts/misc/fonts.alias
We could also split the alias package or even drop it and add its
source to the related fonts packages each building and including their
own alias file.
-Andy
pgpC8Ws1EjlPD.pgp
Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Fri, 26 Jun 2020 16:56:03 +0800
schrieb Felix Yan via arch-dev-public :
> I noticed that xorg-fonts-alias and xorg-fonts-encodings were still
> kept:
>
> https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/ttf-indic-otf=104e24f18c7138d6a0a260a86465375682d4edfa
>
> If they should be removed as well, perhaps this could also be
> mentioned in the TODO?
>
xorg-fonts-alias should only be required by the related
xorg-fonts-{100dpi,75dpi,cyrillic,misc} packages.
xorg-fonts-alias /usr/share/fonts/100dpi/fonts.alias
xorg-fonts-alias /usr/share/fonts/75dpi/fonts.alias
xorg-fonts-alias /usr/share/fonts/cyrillic/fonts.alias
xorg-fonts-alias /usr/share/fonts/misc/fonts.alias
Not sure about xorg-fonts-encodings. Debian packages a common
"xfonts-utils" package similar to our old transitional
"xorg-fonts-utils" package and make it depend on it. I guess these
encodings may be used more widely.
Just checking:
https://gitlab.freedesktop.org/xorg/font/encodings
"Font encoding tables for libfontenc" - maybe our libfontenc should
depend on it and nothing else. That way "xorg-mkfontscale" would pull
it in at build time.
-Andy
pgpPqoMvc1nDb.pgp
Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Fri, 26 Jun 2020 09:38:28 +0200 schrieb Jan de Groot : > Andreas Radke via arch-dev-public schreef op 2020-06-26 08:39: > [...] > > The description says "transitional". The reason it exists is because > it used to contain all utils it depends on. Since we have way too > many font packages in the repository that depend on it, we decided to > make a transitional package, which would get deleted some day when no > fonts depend on it anymore. > > Please kill it together with this change. Done: https://www.archlinux.org/todo/removal-of-xorg-font-utils-transitional-package/ -Andy pgpo0hlHNigOL.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Am Thu, 25 Jun 2020 23:33:45 -0400
schrieb Eli Schwartz via arch-dev-public
:
> On 6/25/20 11:29 PM, Chih-Hsuan Yen via arch-dev-public wrote:
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
>
> It is a "Transitional package depending on xorg font utilities", the
> package has no contents and simply
>
> depends=('xorg-bdftopcf' 'xorg-mkfontdir' 'xorg-mkfontscale'
> 'xorg-font-util')
>
> Not sure why it exists still TBH, but I'd venture to say it should be
> removed too, yes...
>
> e.g. why drag in a recursive dependency on xorg-bdftopcf in this day
> and age?
>
checking for mkfontdir... no
configure: error: mkfontdir is required to build font-arabic-misc.
==> ERROR: A failure occurred in build().
checking for bdftopcf... no
configure: error: bdftopcf is required to build font-arabic-misc.
==> ERROR: A failure occurred in build().
checking for ucs2any... no
configure: error: ucs2any is required to build font-misc-misc.
==> ERROR: A failure occurred in build().
We have to choose if we want simple
makedepends=('xorg-font-utils') or
makedepends=('xorg-mkfontscale' 'xorg-bdftopcf' 'xorg-font-util')
Sure we can drop the meta package "xorg-font-utils" entirely but it
simply covers all possible makedependencies to simplify packagers life.
We should add another ToDo list to either fully remove the
metapackage if we agree to do so or at least move it to a
makedependency. Check all those packages that still depend on it at
runtime probably all wrong:
https://www.archlinux.org/packages/extra/any/xorg-font-utils/
-Andy
pgpm9__zZn5Nd.pgp
Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Discussion - Increasing our CPU requirements
Am Sun, 29 Mar 2020 21:44:38 +1000 schrieb Allan McRae via arch-dev-public : > We are currently supporting processors from 2003. We can be better > than that. > > A In the very early Linux days many tasks maxed out the cpu performance and every cpus optimization was noticeable. This has changed a lot. Many even very old cpus are still fast enough for useful tasks. Do not force users with such a system to leave Arch. My main workstation system is still a SandyBridge 2600K and I guess it will last another 5-10 years. I much prefer runtime extension detection that should be implemented upstream. I'm strongly against increasing our main architecture requirements. I'm not sure if adding any additional more optimized repo is worth the work. -Andy pgpMlZGiGEuFw.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] News draft: hplip 3.20.3-2 update requires manual intervention
News draft - https://bugs.archlinux.org/task/61329 The hplip package prior to version 3.20.3-2 was missing the compiled python modules. This has been fixed in 3.20.3-2, so the upgrade will need to overwrite the untracked pyc files created. If you get errors like these hplip: /usr/share/hplip/base/__pycache__/__init__.cpython-38.pyc exists in filesystem hplip: /usr/share/hplip/base/__pycache__/avahi.cpython-38.pyc exists in filesystem hplip: /usr/share/hplip/base/__pycache__/codes.cpython-38.pyc exists in filesystem ...many more... when updating, use pacman -Suy --overwrite /usr/share/hplip/\* to perform the upgrade. -Andy pgpTgskUvGHeU.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Killing Python 2 (v2)
There's getmail missing in this list. There's no python v3 port or serious work happening. Whenever we drop python v2 we will drop getmail as well. In generell I'm not for keeping python v2 support any longer. I'm for announcing a public deadline and then drop everything that will not be ported. -Andy pgpuP9LMlwgoR.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] libx11/xorgproto dependency
Am Sat, 21 Dec 2019 19:47:39 +0200 schrieb Evangelos Foutras via arch-dev-public : > @Andreas: Can you go ahead and add xorgproto back to libx11? Better to > have 1.5 MiB of headers installed than add seemingly unrelated > xorgproto build dep to packages failing to build or have features > suddenly going missing from packages. Yes, I'm going to add it back. Sorry for the noise. -Andy pgp_eEADkkJ25.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] libx11/xorgproto dependency
With this move I've "fixed" libx11 no more depending at runtime on xorgproto package. I think no headers belong to an end user system and the libx11 library itself doesn't depend on it. But we also ship libx11-devel part inside the package and this indead depends on xorgproto headers. The libx11 .pc file clearly wants to have the headers installed. In the past it was enough to include libx11 to also pull in the proto headers at build time. This is now broken. Some devs call libx11 broken though only its -devel part is. After some discussion on IRC these solution are possible: a) revert to make libx11 depend again on xorgproto headers. This is the pragmatic way and would not need any further work. It just installs header files to the user system that aren't needed in any way there. So we did in the past and I don't really like it as it's not correct to me. b) stay with changed libx11 and add xorgproto to packages that check for any of its headers. This needs to be done to an amount of ~300 packages when hitting build errors over the next time. c) go an unusual way here and split libx11 into libx11, libx11-devel depending on xorgproto and maybe even libx11-xcb. This is the way distros go that support splitting libraries. It's probably the technical correct solution but will also require packages to makedepend on libx11-devel and save us no work. Other distributions have chosen what they prefer. That a decision that needs to be done downstream. I'd like to have either solution b) or c) in Arch to have a clear and more "transient" build time dependency. I guess it may help us also in the future when moving some day away from Xorg to its successor. But if majority wants solution a) back I'm fine reverting this change. Please vote. -Andy pgpko15n59YzQ.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] cleanup dead Xorg packages | news draft
Packages have been rebuilt and prepared to remove obsolete libdmx and libxxf86dga. Xorgproto legacy support has been removed and wherever it was added to be a runtime dependency it is now a build time dependency. Some packages will need additional xorgproto makedependency added when missing some header now that the libraries won't pull it in anymore. That behavior is desired. I'm still in the process of fixing the move from legacy proto headers to xorgproto headers. I'm going to commit the changes to trunk for future builds. There's no package replacing libdmx and libxxf86dga so manual intervention will be needed. So here's a small news draft: "Xorg cleanup requires manual intervention "In the process of Xorg cleanup [1] the update requires manual intervention when you hit this message: :: installing xorgproto (2019.2-2) breaks dependency 'inputproto' required by lib32-libxi :: installing xorgproto (2019.2-2) breaks dependency 'dmxproto' required by libdmx :: installing xorgproto (2019.2-2) breaks dependency 'xf86dgaproto' required by libxxf86dga when updating, use: `pacman -Rdd libdmx libxxf86dga && pacman -Syu` to perform the upgrade. After the update it will be safe to also remove the "xorgproto" package. [1] https://bugs.archlinux.org/task/64892; Note: One single package "Nexuiz" couldn't be fixed to work without libxxf86dga. The package maintainer has been informed to look out for a fix or remove the package and maintain it in AUR where libxxf86dga can be added. -Andy pgpCJG2PAkpPT.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] cleanup dead Xorg packages
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 pgpC4SDUBKEDb.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] xf86-input-keyboard dropped
This Xorg input driver package shouldn't be used under Linux systems anymore. It has been removed from our repos. Use either xf86-input-libinput or xf86-input-evdev driver package. https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/merge_requests/1 -Andy pgpKcmGBLgNMN.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] bringing vivaldi browser to community
Am Sat, 01 Jun 2019 17:53:58 +0200 schrieb Ike Devolder via arch-dev-public : > On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote: > > You don't seem to > > explain why you need to ask in your email. > > Because it is proprietary and I explain that now there is a valid > reason compared to 3 years ago where there was practically no > difference between vivaldi, chromium and opera. Crap. There's no reason to support any closed browser at all. We are still an Open Source Linux distribution. Sure we have a relaxed policy adding closed source packages and blobs wherever needed to support hardware. But there's no reason to support spying tools like closed source browsers! -Andy pgpmW0XDlZgdn.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Spring cleaning (take 2)
Am Wed, 27 Mar 2019 18:22:50 +0100 schrieb Jerome Leclanche : > I'll adopt bluez-firmware if no dev steps up (this one probably should > stay in [extra]). > > J. Leclanche It's deprecated for a long time and shouldn't be useful in any way: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=cdf746c4835ab3b64bbff3731ce02e65b4f6861f and http://www.bluez.org/download/ at the bottom of the page. It should be dropped at least to AUR if not dropped at all. -Andy pgpsiL4QxpeaW.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] away until 5th August
Time for two weeks offline with my family. -Andy pgpzMxqmqNNh2.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] linux-manpages
Am Sat, 31 Mar 2018 14:01:03 +0200 schrieb Andreas Radke via arch-dev-public <arch-dev-public@archlinux.org>: > The recent docs are available online here: > https://www.kernel.org/doc/html/latest/# > > Should we keep packaging this at all or drop it? Is there anybody who > want to take this package over? I'm not interested in packaging this > though maintenance work is low. > > > -Andy I'm going to drop it from the repos within the next 48hours if nobody jumps in. Online docs are available. I see no need to keep packaging this. -Andy pgpktDbVMTvDQ.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] linux-manpages
In the past we have packaged man9 section of kernel docs. Upstream
removed the man pages section in 4.14 release. There are now different
types of kernel docs available (make help output):
Documentation targets:
Linux kernel internal documentation in different formats from ReST:
htmldocs- HTML
latexdocs - LaTeX
pdfdocs - PDF
epubdocs- EPUB
xmldocs - XML
linkcheckdocs - check for broken external links (will connect to
external hosts)
refcheckdocs- check for references to non-existing files under
Documentation
cleandocs - clean all generated files
make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2
valid values for SPHINXDIRS are: crypto networking input media
core-api userspace-api process driver-api sh admin-guide doc-guide
filesystems dev-tools kernel-hacking sound gpu
make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build2
configuration. This is e.g. useful to build with nit-picking config.
Default location for the generated documents is Documentation/output
The recent docs are available online here:
https://www.kernel.org/doc/html/latest/#
Should we keep packaging this at all or drop it? Is there anybody who
want to take this package over? I'm not interested in packaging this
though maintenance work is low.
-Andy
pgpgA_wIv1Aa3.pgp
Description: Digitale Signatur von OpenPGP
