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&id=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 : > 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
Re: [arch-dev-public] systemd - move to base group and expect it to be installed?
Am Tue, 12 Sep 2017 22:02:54 +0200 schrieb Sébastien Luttringer : > Hello, > > Systemd is in the base group since October 2012. Not sure to > understand if your problem is about base or base-devel. > Most of our packages moved to systemd-sysusers. Would make sense to > not have filesystem do the same? > > Regards, It's in the core repo but not in "base" group. root@laptop64:/root # LANG=C pacman -Qi systemd | grep Groups Groups : base-devel And chroots and Arch installation media simply install the full base group. So far systemd is not included and we now have a problem with user/group creation. -Andy pgpa3LD2Fr3ci.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] systemd - move to base group and expect it to be installed?
New filesystem/systemd packages in testing have changed the way we create system users/groups. That's done now via systemd itself or using a systemd hook. So every package that needs certain user/group existent or certain UID/GID to install its file will depend on systemd to be installed on the system. Check https://bugs.archlinux.org/task/55492 - systemd is now part of base-devel. I think it's not consequent not to move it to base group. It's the only init system we support and therefor should be expected to be installed on every Arch installation from now on. User/group creating packages will need it installed in any way. Opinions? -Andy pgpxT9r1bTALl.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Phasing out webkitgtk{,2}
This list doesn't seem to cover (all) optional deps: My claws-mail pkg optdepends on webkitgtk2. I will rebuild it removing the html plugin. http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3710 -Andy pgp3LZw9DL3PP.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Shadowing i686, round 1
Am Mon, 12 Dec 2016 21:51:31 +0100 schrieb Bartłomiej Piotrowski : > I'd like to set a certain date of dropping i686 completely. During > that time, community and/or interested packagers could come up with > either automated build solution, making it "tier 2" architecture. > Otherwise it would just die of natural cause. > > Let's see where we end up this time. > > Bartłomiej > A big +1 from me. I'd suggest to give community 6 or 12 months to prepare the drop. -Andy pgp2qhy8ABiVh.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] i686 and SSE2
Am Wed, 28 Sep 2016 13:10:30 +1000 schrieb Allan McRae : > It would be "simple" to add an SSE2 detection hook into the filesystem > package that aborts any pacman transaction attempting to install a > list of packages on i686 systems without SSE2 support. Is that a > viable solution? > > Any other suggestions? > > Allan Is there a list of the "increasing amount" of packages that require SSE2? If this is still limited to a few packages I'd be fine with such a SSE2 blocking hook for the time until we drop that architecture. -Andy pgpC50P2tkusE.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] i686 and SSE2
Am Mon, 19 Sep 2016 23:30:35 +0200 schrieb Sven-Hendrik Haase : > This would probably be a good time to get a fully automated building > setup going. We certainly have the hardware for it now. +1 > >> Another option could be to keep i686 and x86_64 as is, and > >> introduce new architectures with automatically built optimised > >> packages for i686 + SSE2 or SSE3, and for x86_64 + SSE4.2 or AVX. > >> This is something similar to your option #4, but keeps the > >> compatibility with all existing systems. > > > > Yes! If we want to limit our offer to two binary architectures I'm for x86_64 maybe with SSE3 enabled (kicks out oldest Athlon XPs) and keep i686 with least features needed for full compatibility. I could even live with i586 for fallback. Though I'd prefer to fully drop 32bit and rather leave it up to the community if they want to keep it alive any longer. -Andy pgpogRIjpYHj1.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] away till Aug 20th
Time for some vacation. -Andy pgptXBCrAoBFp.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] libvpx moved to testing - dropping avidemux?
The libvpx rebuilt packages have been moved to testing. Old avidemux won't compile against it. A major update is pending for a long time. Eric isn't around it seems already for a few months. Is there any Dev or TU wanting to take care of it? If not we should drop it to AUR. -Andy pgpqUCKFwBQd0.pgp Description: Digitale Signatur von OpenPGP
[arch-dev-public] away from May 22nd to Jun 4th
I'll be away for a vacation trip to Italy and Austria. Have fun. GnuTLS has a new branch 3.5.x out. We don't want that "next stable branch" this early. Let's keep holding it back a bit more. There are hunspell and poppler .so rebuild pending we can do later. And I have some LibreOffice related library updates pending that I also hold back until LibO itself supports them safely. -Andy pgpDPfsxwN4c7.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Consensus: DKMS modules
Am Thu, 14 Apr 2016 13:29:33 +0200
schrieb Ike Devolder :
> On Thu, Apr 14, 2016 at 08:06:35PM +1000, Allan McRae wrote:
> > On 14/04/16 19:23, Ike Devolder wrote:
> > > - use separate repo [kernel-update{-testing,-staging}]
> >
> > Why? We have staging for rebuilds like these.
>
> So we can have easier updates when a kernel is updated in both core
> and testing.
>
> In that case we would have to land a kernel in core and then update
> the modules as fast as possible. If this update process has its own
> repo you can make sure the updates of the kernel and its out-of-tree
> modules happen on the same time.
>
There's no need for new repos.
I'm for binary modules for our -ARCH main kernel pkg. I see no real
need for -lts modules but if there're a few people who find them
useful I can handle the kernel rebuilds.
No opinion about dkms at all. DKMS could be useful if a foo-dkms pkg is
able to detect all local kernels and build required modules without
interaction. dkms packages for kernel for which we provide binary
modules doesn't provide any more comfort for the user to me.
-Andy
pgpBBbxsIR2ON.pgp
Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Conclusion: DKMS modules
Am Thu, 24 Mar 2016 08:29:57 +1000 schrieb Allan McRae : > I did. Maxime said building modules for only linux and linux-lts is a > good compromise. The Florian said "please go that route". Lukas was > strongly in favour "of have binary modules for kernels from [core]". > > Gatean was in favour of having all kernels support binary modules. > > Hence my conclusion: > > "Binary modules are to be provided at minimum of all kernels in > [core], with preference to providing them for all supported kernels > (noting that out-of-tree modules may not work with some patched > kernels)." Building binary modules for LTS kernel is no big task and takes me 15 minutes when they break. The real work is done in the mainline vanilla kernel (tpowa and module package maintainers). I'm fine with providing binary modules as long as this is an easy task for me to keep them building. I see dkms more something for custom kernels and such stuff. I see no need to have this in core or extra repo. There's no real advantage for the user experience over binary modules. Community repo would be fine for users who prefer to play with dkms stuff if not AUR. -Andy pgpVDM5_Xmt9H.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] DKMS modules for virtualbox
Am Wed, 9 Mar 2016 10:19:18 +1000 schrieb Allan McRae : > > That will fix the use of "optdepends" for things that are not optional > (this is not the only package that does this...) We should have "optdepends" for choice where users should be forced to make a choice like we do now when a "provides" is pulled in. Feature expanding not essential dependencies should better be called "suggested" or similar where no input is required. -Andy pgpbY68VnBVgF.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] vulkan packages, opencl-headers package
Am Tue, 16 Feb 2016 20:03:40 +0100 schrieb Laurent Carlier : > I have two packages for vulkan, headers and manpage and i would like > to add them to extra. > > By the way, i would also like to move opencl-headers in extra for > consistency > Go on. They will become essential pretty soon anyway. -Andy pgp7xXJmYiWoc.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Arch DevOps mailing list
Am Sun, 20 Dec 2015 18:13:02 +0100 schrieb Sébastien Luttringer : > Hello, > > A new arch-devops mailing list has been added to lists.archlinux.org. > The list should be used to discuss Arch Linux infrastructure and > operations topics. > > Permission scheme are based on arch-dev-public; list is open for > subscription to anyone and writing only for Arch Linux Staff. So, the > moderation flag should be removed by mail to be able to write. If you > can't do it, ping me. > > Cheers, > > Subscribed. Filtering requires X-Been-There @lists.archlinux.org. Other lists all seem to have @archlinux.org. -Andy pgpq9V7vALhXc.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] [arch-commits] Commit in xz/trunk (PKGBUILD)
What's the plan with xz update? Will you push 5.2.0 with smp support right after the 5.0.8 update? -Andy pgpWe6OX64ZrC.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Moving gnutls to [core]
Am Wed, 10 Dec 2014 11:46:27 -1000 schrieb Gaetan Bisson : > Hi guys, > > I'd like to move gnutls and its dependencies (libtasn1, nettle, > p11-kit) to [core] so gnupg can link against it; that'll enable HKPS > support. Does anyone think it's not a good idea? > > Other [core] packages may later decide to link against gnutls, but > please discuss this on a per-package basis separately from the above > proposal... > > Cheers. > I'm fine with maintaining gnutls and its dependencies in core if you want. -Andy pgpyCPPrhwUN_.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] Packages added to todo list 'glew 1.11 rebuild'
Am Tue, 19 Aug 2014 09:38:12 +0200 schrieb Jan de Groot : > On di, 2014-08-19 at 09:13 +0900, Gaetan Bisson wrote: > > > What the ?!? > > > > You know that's not how this is supposed to work, right? > > > > It's the second time in two days hugin is broken because of people > > updating a dependency without checking for soname bumps and pushing > > straight to [extra]. > > > > Is it really that hard? > > > > GLEW is broken in a special way: it doesn't provide the .so.1 library, > so applications link against .so.1.11 or .so.1.10 instead. This is not > something you would detect when running checkpkg (common sense says to > ignore soname changes which are not in the first digit). > > Anyways, before rebuilding a lot of shit, please check what's wrong > with GLEW, you can do the rebuild all over again when this is fixed. > I've run checkpkg and tested with glxgears that worked well here. Sorry if something broke. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] libreoffice-still install messages
Am Thu, 7 Aug 2014 10:11:02 +0200 schrieb Bartłomiej Piotrowski : > On Wed, 06 Aug 2014 22:33:30 +1000 > Allan McRae wrote: > > As an aside... why name the package libreoffice-still and not just > > keep libreoffice? As a user I would expect "pacman -S libreoffice" > > to find some form of libreoffice. > > > > Allan > > I can't really give a good answer, as I'm for keeping plain > "libreoffice" too. Another possibility is "libreoffice" virtual > package provided by both -still and -fresh, but I'll abstain before > Andy returns. > We can drop install messages about splitting now. Note: The splitting has been reduced in LibO 4.3 packages (currently the LibO - "fresh" branch). About the branches: LibreOffice has two releases at a time. Those are called libreoffice-fresh and libreoffice-still. "Fresh" ist the one with new features and usually with bugs many users can't accept in a production use case. The LibO community does maintain a 2nd branch called "still" for critical use cases. The "fresh" releases becomes the new "still" release when a new major "fresh" release happens after 6 months. In the past Arch shipped the "fresh" releases from .1 or .2 minor releases but they were still very fresh and sometimes a serious feature is still broken at that time. Pointing user to ABS and "patch yourself" is pretty unfair with that large package that takes ages to compile. So we went forward and ship now both branches. This will also help upstream with more users of the fresh branch and earlier bug reports from a distribution use. About the name "still": That's an upstream decision we take over. We don't want to prefer one or the other branch. So there is no more a simple "libreoffice" package. pacman -S libreoffice should force the users to decide one or the other branch. http://nabble.documentfoundation.org/LibreOffice-Still-tt4117297.html There's some info from upstream devs about the branch naming scheme. For safety the -still branch packages will replace the old "libreoffice" packages. It's just release in the same branch LibO 4.2.5 to 4.2.6. I'll put a note about the new -fresh branch into the new -still install msg. -Andy -Andy signature.asc Description: PGP signature
[arch-dev-public] away until 15 August
I'll be away for holiday over the next 2 weeks in northern Italy. Have fun and keep Arch running. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] librevenge .so bumps
Am Sun, 25 May 2014 21:53:44 +0200 schrieb Andreas Radke : > Newly added librevenge requires many document treating libraries being > released with .so bumps. > > http://listarchives.documentliberation.org/www/discuss/msg00070.html > > I'm currently pushing updated libs to staging. Please wait for a 2nd > mail before starting the rebuilds. > > -Andy All libs have been uploaded to staging. Please start the rebuilds. -Andy signature.asc Description: PGP signature
[arch-dev-public] librevenge .so bumps
Newly added librevenge requires many document treating libraries being released with .so bumps. http://listarchives.documentliberation.org/www/discuss/msg00070.html I'm currently pushing updated libs to staging. Please wait for a 2nd mail before starting the rebuilds. -Andy signature.asc Description: PGP signature
[arch-dev-public] libetpan removed from testing
Libetpan built with new toolchain braiks claws-mail even after recompiling it. For now I removed the broken new libetpan version from testing. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Fwd: [arch-general] Java 8
Am Sun, 30 Mar 2014 11:21:25 +0200 schrieb Guillaume ALAUX : > Hi devs, > > A new major version of Java went out recently [0]: "OpenJDK 8" but we > do not have a package for it (for the following reason) and some > Archers are asking questions [1] or flagging our openjdk7 package as > out of date: > > All Linux distros - including Arch - build OpenJDK using the IcedTea > project [2]. Its goal is to cleanly build OpenJDK from Oracle, bring > some more feature and it **was** also to re-implement closed source > parts. I expected IcedTea to quickly release a version for OpenJDK8 > but it seems this is not their first priority [3] (which I totally > understand). Nowadays there is no closed source part anymore in > OpenJDK, and the license is clearly "GPL with classpath exception" > which is a standard in the Java world. > > I have been working on a package based on OpenJDK8 built from source > but without IcedTea that I think would fit to our repos. I still have > some work for it to be released but I would be in favor of pushing > this "OpenJDK without IcedTea" to extra until IcedTea v3.0 stable is > out and could be used to build/augment our package. > > Any thought/objection/remark about? How about using icedtea master bzr shots to build openjdk8 until they publish a release? -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Kingsoft Office License
Arch philosophy is to provide an open source software distribution. We do allow exceptions where open source software is not available or in very poor shape. I can't see how this office suite would fit this. I'm generally for avoiding closed stuff wherever possible. -1 -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] libssh - X2goclient
Am Sat, 15 Mar 2014 16:05:35 +0800 schrieb Felix Yan : > On Saturday, March 15, 2014 08:29:42 Andrea Scarpino wrote: > > On Tue 21, January 11:20:07 Andreas Radke wrote: > > > There is a libssh 0.6.0 release update pending for us. I'd like > > > to ask you stay with 0.5.x branch for a bit longer. > > > > Any news here? KDE 4.13 requires libssh >= 0.6.0 [1] > > > > [1] > > https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/4007 > > 6246be995cc006a12f8afc2c18cfacbf0604 > > May be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1053305 > > Regards, > Felix Yan http://permalink.gmane.org/gmane.linux.terminal-server.x2go.devel/6690 A x2goclient release should happen early next week. If not we can always use a current git snapshot and live with that one rare pulseaudio related bug. -Andy signature.asc Description: PGP signature
[arch-dev-public] libevdev .so bump / clutter status
I took over libevdev. It's somehow related to the Xorg packages I maintain. But the only packages in our repo that can optionally depend on it are clutter and packages depending in it. I've put libevdev 1.0.x into staging to start the .so rebuild. I've found that the old 1.16.x clutter won't build with this new libevdev version. New clutter 1.17.x in gnome-unstable can make use of it but the rebuild should be done in gnome-unstable. It could be an option to move libevdev from staging to gnome-unstable. Can the gnome and clutter maintainers please take care of this or point me how to fix this situation? Note: Gentoo seems to disable libevdev support in clutter, Fedora has it enabled. -Andy signature.asc Description: PGP signature
[arch-dev-public] Apache webserver status
There's a major version bump pending now for a very long period and user request come up every now and then requesting the update to the current 2.4.x branch. The current maintainer seems to have no time or interest to work on this in the near future. So someone else should pick this package up or we should drop it to some TU or even to AUR if nobody is interested. Meanwhile I've pushed a lacking minor update from the 2.2.x branch to testing. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] moving libpaper to extra / new (Calligra/LibO) Office related libs
Am Wed, 22 Jan 2014 21:03:14 +0100 schrieb Jelle van der Waa : > It totally makes sense to create packages for libraries which are > used in Calligra and LibreOffice. Creating packages for obscure > libraries used only in LibreOffice seems like an unnecessary maintain > burden, I just wonder why you don't use boost and rhino from our > repos. > > When I used to contribute to LibreOffice, I've build flawlessly > against our repo's boost version. > Libpaper is now used by cups and ghostscript. Libvisio is now used by Calligra and system libvisio will soon replace the internal libvisio in LibO. Libetonyek and libodfgen are used in LibO and will be used in Calligra 2.8.x. - so packaging these libs also makes sense. Boost is only a makedep in LibO and not linked. Build was very often broken when we had updated our system boost. As it has no benefit at runtime I stay with the well tested internal boost in LibO. For rhino LibO uses a patched source. I doubt we can use our rhino pkg. Have a look at http://cgit.freedesktop.org/libreoffice/core/tree/external/rhino/README -Andy signature.asc Description: PGP signature
[arch-dev-public] moving libpaper to extra / new (Calligra/LibO) Office related libs
I'd like to make use of libpaper in Ghostscript, Cups and LibreOffice. So I will move it to extra and will maintain it there. Also I was told that Callibre can make use of certain libraries in future versions that are already part of the internal LibreOffice sources. I will do some investigation and will decide if we make them system libs so we can do shared linking to these libs. Please have a look at the PKGBUILD, what internal sources we will use in LibO 4.2 : https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD.42?h=packages/libreoffice -Andy signature.asc Description: PGP signature
[arch-dev-public] libssh - X2goclient
There is a libssh 0.6.0 release update pending for us. I'd like to ask you stay with 0.5.x branch for a bit longer. X2goclient currently doesn't build and run with libssh 0.6.x. Upstream is aware of it and will soon fix it. For now the next X2goclient release will require patching old libssh 0.5.x. I'm going to push a patched 0.5.x version to tesing for the new X2goclient release. See also https://lists.berlios.de/pipermail/x2go-dev/2014-January/006847.html -Andy signature.asc Description: PGP signature
[arch-dev-public] bluez4 has been dropped
Bluez4 stack related packages have been dropped from extra repo. Please remove all depending packages in our community repo (Blueman comes to my mind if it is not fully ported to bluez5). Bluez4 should not be picked up into the community repo. If people can't make their to devices work with current bluez5 they should file bugs to our tracker and work with upstream to solve the problems. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping bluez4
Am Sat, 12 Oct 2013 16:28:56 +0200 schrieb Tom Gundersen : > Hi guys, > > Once pulseaudio and bluedevil moves out of [testing], the only > official package depending on bluez4 will be blueman. > > As blueman was last released two years ago, and last upstream activity > was more than one year ago and that bluez4 is no longer developed > upstream at all, I suggest dropping both of them from the > repositories. > > Any objections? > > Cheers, > > Tom > I've done some work and research on bluez lately. I can confirm my adapters to work with bluez 5.10 and gnome-bluetooth (connecting to headset + smartphone) that has already moved to extra. I couldn't make it work with kde+bluedevil that is in testing. Also it seems not possible to use plain bluetoothctl to pair (works sometimes)/connect(never working here) your device and use plain alsa/obex. This is an annoying situation for any other desktop apart from Gnome. Blueman is broken and for many users not even starting. No idea about our networkmanager bluetooth support. Fedora 20 has switched over to only use bluez v5, OpenSuSE is also using it. We should search further how to solve kde and plain console situation. Is Bluez4 still required to use with obexd? If not we can drop it and focus on improving bluez5 support. Best would be to get bluez connecting to devices from console or/and to have a desktop independent frontend like this approach: http://mail.xfce.org/pipermail/xfce4-dev/2013-July/030408.html -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR
Am Mon, 4 Nov 2013 13:39:48 +0100 schrieb Alexander Rødseth : > Hi, > > gnome-commander doesn't compile. Do you still mind if I move it to > AUR? > > > Here is one of the errors: > > > In file included from gnome-cmd-tags.cc:36:0: > ./../dict.h: In instantiation of 'void DICT::add(KEY, const > VAL&) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]': > ./../dict.h:155:10: required from 'void load_data(DICT&, > void*, unsigned int) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]' > gnome-cmd-tags.cc:540:68: required from here > ./../dict.h:58:101: error: 'make_pair' was not declared in this scope, > and no declarations were found by argument-dependent lookup at the > point of instantiation [-fpermissive] > std::pair k_pos = > k_coll.insert(make_pair(k,(const VAL *) NULL)); > > ^ > In file included from /usr/include/c++/4.8.2/bits/stl_algobase.h:64:0, > from /usr/include/c++/4.8.2/vector:60, > from gnome-cmd-tags.cc:26: > /usr/include/c++/4.8.2/bits/stl_pair.h:286:5: note: 'template _T1, class _T2> std::pair<_T1, _T2> std::make_pair(_T1, _T2)' declared > here, later in the translation unit > make_pair(_T1 __x, _T2 __y) > ^ > > http://pkgs.fedoraproject.org/cgit/gnome-commander.git/tree/gnome-commander-1.2.8.15-gcc47.patch?id=eaa0a46abc3dc6ecdaa539be5e2f556d680e With this fix it builds well here. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR
Am Mon, 4 Nov 2013 18:54:29 +0100 schrieb Ike Devolder : > Have you tried doublecmd ? > > It is actively maintained and has a gtk and qt gui. Looks promising. Thx. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR
Am Mon, 4 Nov 2013 11:54:25 +0100 schrieb Alexander Rødseth : > Hi, > > gnome-commander was last updated 2011-12-10, is currently an orphan > and no other package needs it. > https://www.archlinux.org/packages/community/x86_64/gnome-commander/ > > perl-config-ini was last updated 2013-10-28, is currently an orphan > and no other package needs it. > https://www.archlinux.org/packages/community/any/perl-config-ini/ > > I'm planning to move these two from [community] to AUR. > Please keep gnome-commander for now, the package works pretty well so far. After the initial upstream developer died it now has been picked up and development seems to be started again. It's my daily FM (I couldn't find another good gtk based two panel FM so far) and I can help out Sergej if problems occur. http://lists.nongnu.org/archive/html/gcmd-devel/2013-11/msg0.html -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Making !staticlibs the default in makepkg.conf
Am Tue, 15 Oct 2013 23:18:00 -0400
schrieb Eric Bélanger :
> I just discussed on IRC with Allan about the possibility of
> making !libtool the default in makepkg.conf. Currently, 104 packages
> contains *.la files (mostly gambas stuff). We could check which of
> these packages really require the libtool files and add an
> options=('libtool') to them. This could be done at the same time as
> the !staticlibs rebuild. Any objections?
>
> Eric
>
Sounds good to me.
+1
-Andy
signature.asc
Description: PGP signature
[arch-dev-public] LTS kernel moved to 3.10.x - module rebuilds
I've updated LTS kernel to 3.10.x branch into testing repo. Please rebuild all community modules. I'll do the module rebuilds for extra repo packages. -Andy signature.asc Description: PGP signature
[arch-dev-public] nvidia-304 packages
I don't have a Nvidia card anymore. I've done a final untested bump to 304.108 to testing. I'm orphaning nvidia-304-utils and both kernel modules now. If nobody will pick them up we should move them to community or AUR. -Andy signature.asc Description: PGP signature
[arch-dev-public] db6 rebuild dropped - new ToDo list
Due to the license change in db5 (MIT style) to db6 (AGPLv3) we drop the db6 update and will keep db5 in core for now. Berkeley db5 won't see much further updates if any at all. We should check each package that now links to it if that functionality is essentially required. I'm going to remove all db bump related packages from staging repo. I'm also going to revert the ToDo list to incomplete for each pkg for checking if a pkg can be build without db support. On the long run we should move db in a first step to extra and maybe later drop it completely. So go on and fix svn trunk to the old state or rebuild it to testing repo without db support wherever possible without loosing important features and mark the ToDo list. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] licensing issues with DB 6.0
I suggest the quick solution to drop the db v6 rebuild and stay with old db 5.3.21 to be on the safe side. We should check all packages on the rebuild list if they can be build without linking to Berkeley db at all (new Todo list). Maybe that way we can move db in a first step to extra and drop it later completely. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] licensing issues with DB 6.0
After some reading the AGPLv3 license is not different from GPLv3 with one addition. Since many services now run in the cloud in AGPLv3 this is also covered as "distribution" of the code and must be done under the same rights that GPLv3 would require when shipping software as binary builds via some storage media. We do not change anything to the "db v6" code base. A quick overview over the rebuilt packages I can't see a pkg that is published under a non-free license. If we would be allowed to link to DBv6 if it would be under GPLv3 then we are also allowed to link to it under AGPLv3. I see no serious reason to not accept that license change. http://en.wikipedia.org/wiki/Affero_General_Public_License#Compatibility_with_the_GPL http://lwn.net/Articles/557820/ http://en.wikipedia.org/wiki/GPL_linking_exception I'm no expert in that stuff. Maybe someone dealing day by day with such stuff has more knowledge here. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] The next LTS
Am Mon, 5 Aug 2013 21:16:26 +0200 schrieb Rémy Oudompheng : > Would it be a good idea to switch to 3.2 now until October? Linux 3.2 > is used by Debian 7 and is definitely widely tested by a lot of > people. > > Rémy. > Not worth for the few months. We could have done that for over a year and also a switch to 3.4 was possible. We stayed with 3.0 for good reason. The plan will be to switch to 3.10 in testing when 3.11 will be out for the stock kernel. We can delay this until the last 3.0 release or be pretty quick when 3.11 is just released. I notice 3.0 to be slow in boot and shutdown with systemd even with a slow hdd as boot drive, much more with a ssd. I suggest to put 3.10 LTS as early as possible into testing maybe parallel to 3.10 stock kernel in a few weeks. I'd be happy to test it. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] gcc 4.8 breaking libdrm for me
I've bisected gcc and found this commit breaking it for me: http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=32b227ebedc3dde524cdbb3bfa7ccbca23e2a185 I've sent a mail to the gcc-help list with cc to the gcc commit author and some libdrm and nouveau guys. Let's see if someone can help. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] gcc 4.8 breaking libdrm for me
Uploaded tarballs with gcc47 and 48 with -O0 and -save-temps: https://docs.google.com/file/d/0B8HSjV2qdYV1VXhmdnlxc29RZDQ/edit?usp=sharing https://docs.google.com/file/d/0B8HSjV2qdYV1aE80NWh4S1Yzdlk/edit?usp=sharing Feel free to run meld over .s files. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] gcc 4.8 breaking libdrm for me
Am Sat, 13 Jul 2013 08:45:38 +0200 schrieb Alexander Rødseth : > Well done narrowing the issue down. I haven't had the chance to > compare the assembly output yet, but does it work if you compile with > -fno-aggressive-loop-optimizations? Ref: > http://postgresql.1045698.n5.nabble.com/Back-branches-vs-gcc-4-8-0-td5750997.html > > - Alexander / xyproto > No. I've tried this one already and it doesn't fix it. When built with -O0 all optimization should be turned off and it's still failing. I guess I should build libdrm with gcc 4.7 and 4.8 both with -O0 and compare the full trees with meld. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] gcc 4.8 breaking libdrm for me
I've built libdrm now with CLANG compiler and so far also no problems. Clean dmesg, no hangs and no glitches over Firefox tabs. I suggest to push a "fixed" package built with clang to testing and report this one to gcc people. Opinions? -Andy signature.asc Description: PGP signature
[arch-dev-public] gcc 4.8 breaking libdrm for me
This is just a heads up notice. I've found gcc 4.8 breaking libdrm on my nouveau nv44 device. When compiled with gcc 4.8 I'm faced with random nouveau related error messages in dmesg. Using new google maps quickly leads to Xorg hanging and finally to Xorg freezing or even crashing. I've seen other Arch people also claiming about random X crashes. Recompiling libdrm with -O0 or other new optimizaions disabled didn't solve it for me so far. But recompiling with a local gcc 4.7.3 makes it stable again. I'm asking for help in tracking this down. We need to find out if a certain part of libdrm has broken code that needs to be fixed. Please everybody with random Xorg crashes try to downgrade to libdrm 2.4.43 (the last one that was built with gcc 4.7) and post your gfx card. And this could also be a gcc 4.8 bug or regression. I've seen almost the same behavior with kernel xfs file system code leading to fs corruption under heavy load: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57436 Then we need to compare assembler code created by gcc 4.7 vs. 4.8. Any suggestion and help is welcome. -Andy signature.asc Description: PGP signature
[arch-dev-public] dropping FreeNX/OpenNX and nx-common
I'd like to drop FreeNX from our extra repo. It's not maintained for several years now though it can still do its job pretty well with some heavy patching and sed commands fixing things that have changed meanwhile. We've already dropped the closed NoMachine NX client and I'd like to drop OpenNX along with FreeNX because there's a successor out there named X2go. X2go packages are in extra: a functional replacement with the same and better features. And it's well maintained upstream. nx-common pkg with remaining NoMachine libs is only required by FreeNX and OpenNX and can be removed too then. Any objections or somebody who wants to take over these packages? -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Adding !staticlibs to our default makepkg.conf
Am Wed, 29 May 2013 10:03:29 +0200
schrieb Gaetan Bisson :
> I doubt most of the static libraries our packages ship ever get used,
> so I strongly support getting rid of all that dead weight (that's
> 115M on my system, for instance). If needed, we can explicitly re-add
> options=('staticlibs') to core libraries' PKGBUILD, but that should
> really be the exception rather than the rule.
>
> Cheers.
>
+1
-A
signature.asc
Description: PGP signature
Re: [arch-dev-public] kernels: NFS ACL trouble
Am Fri, 12 Apr 2013 20:30:54 +0200 schrieb Andreas Radke : > New stable kernels have been released. > > I suggest to avoid all the NFS lost files and other trouble we've seen > recently to revert the 4 NFS ACL related commits that went into 3.0.72 > and 3.8.6 when updating our LTS and current kernel. If all is still > fine after the bump we should inform upstream about the trouble and > should try to find a proper fix. > > -Andy I've found the time to track this down a bit further. It's all not a bug in the kernel or NFS it seems. It's more likely a gcc compiler regression. All kernels built with gcc 4.8.0 can easily reproduce file system corruption here. I've build a 3.0.80 kernel with gcc 4.7.3 and it doesn't show this bug. I'll bring this to the gcc bug tracker. Still no clue how to help them tracking this down further. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Merging the "bin" directories
Am Sun, 12 May 2013 02:56:50 -0300 schrieb Gerardo Exequiel Pozzi : > Looks like we are going "one step" more compared to Fedora right? > > /bin /sbin /usr/sbin -> /usr/bin (Arch Linux) > /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora) > > This looks nice :) > Is it safe to move a daemon to /usr/bin where any user can access its binary (e.g. my cups pkg)? -Andy signature.asc Description: PGP signature
[arch-dev-public] Away until May 9
Time for a short holiday trip. -Andy signature.asc Description: PGP signature
[arch-dev-public] kernels: NFS ACL trouble
New stable kernels have been released. I suggest to avoid all the NFS lost files and other trouble we've seen recently to revert the 4 NFS ACL related commits that went into 3.0.72 and 3.8.6 when updating our LTS and current kernel. If all is still fine after the bump we should inform upstream about the trouble and should try to find a proper fix. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Build issues due to -D_FORTIFY_SOURCE=2 in CPPFLAGS
Am Mon, 08 Apr 2013 09:18:40 +0200
schrieb Thomas Bächler :
> Am 08.04.2013 08:54, schrieb Allan McRae:
> > What do we do? Do we need to ignore the fact the this should be in
> > CPPFLAGS and move it back to C{,XX}FLAGS?
> >
> > The other options is for packages that are affected by this to
> > unset the CPPFLAGS and add it to CFLAGS in the PKGBUILD, but I have
> > no idea how many packages this affects. What portion of KDE and
> > GNOME were built with pacman-4.1?
>
> In PKGBUILD:
>
> CPPFLAGS="$CPPFLAGS -O2" - problem solved.
>
>
"man feature_test_macros" says:
_FORTIFY_SOURCE (since glibc 2.3.4)
Defining this macro causes some lightweight checks to
be performed to detect some buffer overflow errors when employing
various string and memory manipulation functions. Not all buffer
overflows are detected, just some common cases. In the current
implementation checks are added for calls to memcpy(3),
mempcpy(3), memmove(3), memset(3), stpcpy(3), strcpy(3), strncpy(3),
strcat(3), strncat(3), sprintf(3), snprintf(3), vsprintf(3),
vsnprintf(3), and gets(3). If _FORTIFY_SOURCE is set to 1, with
compiler optimization level 1 (gcc -O1) and above, checks that
shouldn't change the behavior of conforming programs are performed.
With _FORTIFY_SOURCE set to 2 some more checking is added, but some
conforming programs might fail. Some of the checks can be performed at
compile time, and result in compiler warnings; other checks take
place at run time, and result in a run-time error if the check
fails. Use of this macro requires compiler support, available with
gcc(1) since version 4.0.
I'm for "unset CPPFLAGS" in our PKGBUILD and reporting it upstream. Any
other solution is probably not worth the effort. I don't see any
advantage to move it back to CFLAGS for certain packages. Maybe Thomas'
workaround is also a valid solution until upstream ships proper fixes.
-Andy
signature.asc
Description: PGP signature
Re: [arch-dev-public] rc.d init files package
Am Sun, 31 Mar 2013 17:09:00 +0300 schrieb Ionut Biru : > Let me know what you guys want me to support and i'll add it into my > package. > > -1 for such support in our official repos. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Xorg-server 1.14 hitting testing
Am Tue, 19 Mar 2013 19:18:49 +0100 schrieb Pierre Schmitz : > Am 16.03.2013 11:09, schrieb Pierre Schmitz: > > Am 16.03.2013 10:05, schrieb Andreas Radke: > >> I'd like to move Xorg 1.14 pretty soon, best would be together with > >> the kernels. It's up to you whether you want to announce to hold > >> the update for catalyst users or remove it from the repos. > > > > I just noticed that Virtualbox does not work with the latest > > xorg-server due to ABI mismatch. Is this known? It's possible that > > rebuildig the driver might fix this. > > Why was this moved to extra regardless of the known issues it causes? > The kernel got moved and no stopper for Xorg was known. We don't care about catalyst, vmware is broken upstream and this is known for months, for vbox there's no bug report expect your late mail and there's a workaround to ignore the ABI mismatch. So far this is a calm move. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Xorg-server 1.14 hitting testing
Am Sun, 17 Mar 2013 04:55:01 +0100 schrieb Sven-Hendrik Haase : > > I'd keep it for now and block update. AMD has been better the last 2 > years. Maybe they'll follow up on this problem soon enough? > There's already a beta driver out with 1.14 support ;) But I don't want to wait until they will release it as final. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Xorg-server 1.14 hitting testing
Am Sun, 10 Mar 2013 09:27:16 +0100 schrieb Laurent Carlier : > Users will have to wait until a compatible version is available. Mesa > drivers are an alternative, or they can block the upgrade. > > ++ I'd like to move Xorg 1.14 pretty soon, best would be together with the kernels. It's up to you whether you want to announce to hold the update for catalyst users or remove it from the repos. I suggest to use the video api dependency + conflicts like we do in all other driver packages to avoid the xorg-server update for catalyst users. But this is your choice. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Xorg-server 1.14 hitting testing
SIS* drivers are rebuilt and also in testing. -Andy signature.asc Description: PGP signature
[arch-dev-public] Xorg-server 1.14 hitting testing
Following drivers need further fixing and are not yet rebuilt: xf86-video-sis: sis_driver.c:9384:13: error: too few arguments to function 'miPointerSetPosition' In file included from /usr/include/xorg/xf86Cursor.h:6:0, from sis.h:83, from sis_driver.c:50: /usr/include/xorg/mipointer.h:118:1: note: declared here This is due to changes in Xinput 2.3 in /usr/include/xorg/mipointer.h changes from miPointerSetPosition(DeviceIntPtr pDev, int mode, double *x, double *y); to miPointerSetPosition(DeviceIntPtr pDev, int mode, double *x, double *y, int *nevents, InternalEvent *events); similar for sisimedia and sisusb drivers. Current NVidia blob driver + NVidia-304 series claims to be ready for new Xorg. No idea about catalyst. Happy testing and upstream bug reporting. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] cleaning up unneeded static libraries?
Am Sat, 02 Mar 2013 19:29:13 +1000 schrieb Allan McRae : > Just add *.a to PURGE_TARGETS in makepkg.conf rather than manually > removing them. Anyone who needs them can disable that. > > (I will keep them in glibc/gcc/binutils...) > > Allan > Nice solution. We should add *.a to the default PURGE_TARGETS in the next pacman release. Static libs will die out then pretty quick. Maybe after some time a ToDo list could clean the older packages then. -Andy signature.asc Description: PGP signature
[arch-dev-public] cleaning up unneeded static libraries?
Our packages in our repos by default don't need static libraries (random .a files all around). I think they are a waste of disc space and abuse bandwidth when uploading/mirroring packages. Most users will never need them. I suggest to drop all static libs by creating a ToDo list and install a rule to not ship static libraries anymore, maybe with some exceptions. Whenever users require static libs we should point to abs. Opinions? [andyrtr@workstation64 ~]$ pkgfile -v -g /usr/lib/\*.a | sort | wc -l 3417 There are probably more in other directories. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] ISO image announcements
Am Fri, 01 Mar 2013 10:20:55 +0100 schrieb Pierre Schmitz : > Hi all, > > I just uploaded a new installer image. I did not write any > announcement for the last two. Some people were asking for a news > item. What is your opinion on this? Should we post announcements even > if there are no exciting changes? I could also generate a list of > updated packages that are available on the new iso compared to the > old one. > > Greetings, > > Pierre > I don't see the need for a news announcement. Maybe put a ChangeLog next to the download link. That should be more than enough for a rolling release install media. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Mesa 9.1 in testing
Am Mon, 25 Feb 2013 21:56:37 +0100 schrieb Laurent Carlier : > Le lundi 25 février 2013 04:24:07 Sven-Hendrik Haase a écrit : > > On 24.02.2013 23:31, Gaetan Bisson wrote: > > > [2013-02-24 17:16:42 +0100] Sven-Hendrik Haase: > > >> +1 for moving mesa quickly > > > > > > Do you have any more arguments than Andreas gave to support this? > > > > > > Or is the "+1" entirely for free? > > > > Moving it quickly would seem like the simplest solution and the > > bugs I heard of seem only to concern wayland. I'd wager that for > > most our users, moving it now would be a fine idea. The other > > trickery suggested doesn't sit well with me. > > I agree. A quick move is the best solution. > > ++ Already done. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] Mesa 9.1 in testing
Am Sun, 24 Feb 2013 22:41:08 +1100 schrieb Gaetan Bisson : > [2013-02-23 10:23:13 +0100] Andreas Radke: > > There are still packages in extra depending on the old libgl > > package. We will need to fix them before makepkg will properly > > allow to build only against new mesa. > > With [testing] enabled, `pacman -S libgl` still pulls the old libgl, > rather than mesa-libgl which provides it and lies in a higher-priority > repo. I am not sure why. Anyhow, most pacman transactions required to > build anything depending (directly or not) on mesa and libgl result > in: > > /usr/lib/xorg/modules/dri/swrast_dri.so exists in both 'mesa' > and 'libgl' > > Is this what you were referring to? Or is there anything I am missing > to avoid running into this issue. > Yes. We are looking for a solution for this. I guess this is a pacman limitation. Afaik pacman can resolve replaces only on -Su upgrades. If nobody shows a real solution we can either move Mesa pretty quickly to extra resolving this. This will for sure trigger some bugs for the users. Or we use an ugly workaround: when a chroot build fails move the dependency array from the top of the PKGBUILD to the package() function array. -A signature.asc Description: PGP signature
[arch-dev-public] Mesa 9.1 in testing
New unified Mesa has hit testing. Upgrade path went smooth here. Please test it. Now the main mesa pkg should provide everything required to build and link packages. The mesa-libgl pkg providing libgl should be not be used in the dependency array when linking to libgl.so - please use "libgl" that will allow users to choose also nvidia-utils or catalyst-utils. There are still packages in extra depending on the old libgl package. We will need to fix them before makepkg will properly allow to build only against new mesa. -Andy signature.asc Description: PGP signature
[arch-dev-public] dropping OpenJDK6 by the end of this month
We will remove the OpenJDK6 packages by the end of this month. All users should move to OpenJDK7 based packages jre7-openjdk/jre7-openjdk-headless/jdk7-openjdk (or the Oracle based JRE/JDK from AUR) very soon. The next OpenJDK7 update will replace openjdk6 on your system. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] mesa packaging, libGL handling
> My current plan: merge libglapi mesa osmesa libgbm libgles libegl > khrplatform-devel and a separate libgl with libGL.so and libglx.so > conflicting with nvidia-utils. Not sure if we can do this without > symlinks. > > I'd like to keep separate *-dri driver packages. Nobody needs drivers > for other hardware. > > -Andy I've updated the Mesa PKGBUILD in trunk. Please have a look if it now covers all your wishes. Mesa 9.1 release is expected for this Friday. We will need an updated llvm-amdgpu-snapshot pkg to be able build all AMD drivers. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] mesa packaging, libGL handling
Am Fri, 15 Feb 2013 20:17:03 +0100 schrieb Laurent Carlier : > Le vendredi 15 février 2013 20:02:28 Tom Gundersen a écrit : > > On Fri, Feb 15, 2013 at 7:05 PM, Jan Steffens > > > wrote: > > > On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier > > > > wrote: > > >> Perhaps we could merge: > > >> - mesa, khrplatform-devel > > >> - libglapi, libgl, libgles > > >> - libgbm, libegl > > > > > > Also, the pipe drivers from libgbm should be sorted into the *-dri > > > packages. > > Out of curiosity, what would be the benefit of keeping it split up > > rather than just merging (almost) everything? > > > > -t > > Just asked on irc, libegl can only work with mesa, not with > nvidia/ati blobs. So a merge between libglapi, libgl, libgles, libgbm > and libegl make sense. > > > My current plan: merge libglapi mesa osmesa libgbm libgles libegl khrplatform-devel and a separate libgl with libGL.so and libglx.so conflicting with nvidia-utils. Not sure if we can do this without symlinks. I'd like to keep separate *-dri driver packages. Nobody needs drivers for other hardware. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Add Wayland/Weston
Am Sat, 9 Feb 2013 17:35:27 +0100 schrieb Andreas Radke : > Since cairo will also depend on that libegl then every system will > pull in Wayland. Is this really needed? If we can't build it in a > different way we directly need to move Wayland to extra. > > -Andy Bump. If we agree that we want to start to support Wayland in Arch we need to move Wayland libs to the extra repo. Then I can build Mesa making use of it in libegl. This shouldn't harm anything else and wayland libs are a pretty small pkg (when we drop the static libs). So who's going to move it to extra and wants to maintain it there? I could build it but will not use it myself anytime soon. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Add Wayland/Weston
Now that Wayland has landed in Community I can build Mesa with support for Wayland. This leads to a new dependency in libegl: libegl E: Dependency wayland detected and not included (libraries ['usr/lib/libwayland-server.so.0', 'usr/lib/libwayland-client.so.0'] needed in files ['usr/lib/egl/egl_gallium.so','usr/lib/libEGL.so.1.0.0']) Since cairo will also depend on that libegl then every system will pull in Wayland. Is this really needed? If we can't build it in a different way we directly need to move Wayland to extra. -Andy signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Add Wayland/Weston
Am Fri, 8 Feb 2013 09:07:26 -0500 schrieb Dave Reisner : > > For Cairo, the GL backend is experimental. Given the fact that > > upstream fails to provide a stable release model for cairo (every > > released version is taken from master, featuring regressions), I > > wouldn't even think about enabling an experimental backend there. > > Upstream also claims that applications which don't make use of the GL > backend won't be bothered at all. I don't see the harm in a trial run > through [testing]. > > > For Mesa, we have to look at how we can implement this without > > breaking existing stuff. I haven't looked much at Mesa recently, so > > I can't tell much about this. > > Backends are enabled on a priority basis. As long as we pass > "--with-egl-platforms=x11,drm,wayland" (in that order), we're fine. > > d > I've pushed cairo with gl and egl backends to testing. xlib-xcb is now also enabled again that now should be safe to use. I can't build mesa with --with-egl-platforms=x11,drm,wayland until we have wayland in community or extra to build against. Package libclc was not found in the pkg-config search path. Perhaps you should add the directory containing `libclc.pc' to the PKG_CONFIG_PATH environment variable No package 'libclc' found Package libclc was not found in the pkg-config search path. Perhaps you should add the directory containing `libclc.pc' to the PKG_CONFIG_PATH environment variable No package 'libclc' found checking for XCB_DRI2... yes checking for xcb_dri2_connect_alignment_pad in -lxcb-dri2... yes checking for WAYLAND... no configure: error: Package requirements (wayland-client >= 1.0.2 wayland-server >= 1.0.2) were not met: No package 'wayland-client' found No package 'wayland-server' found -Andy signature.asc Description: PGP signature
[arch-dev-public] adding X2go to extra
FreeNX isn't maintained upstream anymore. X2go is the current project that develops NX-libs v3 and ship a different set of Server+Client that is a full replacement for remote Client-Server access with similar functionality. X2go packages can be installed along FreeNX/OpenNX/NXclient and later we can drop FreeNX packages if they really die. I'm currently building packages locally based on the AUR packages and I'd like to bring them all to extra with needed build dependencies (only man2html so far). If there are no objections I'll push them over the next few days to testing. -Andy signature.asc Description: PGP signature
[arch-dev-public] [cups-filters] adds cups-browserd.service - please test
New cups-filters 1.0.26 brings back browsing remote shared printers using the new cups-browserd. This requires a running a local cupsd instance and avahi on the client system. Please test the included cups-browserd.service file and check if browsing now works as expected and described in /usr/share/doc/cups-filters/README. -Andy signature.asc Description: PGP signature
[arch-dev-public] away until 16th Dez.
I'll be away until Sunday for a short trip to Dresden. -Andy signature.asc Description: PGP signature
