[arch-dev-public] system-config-printer requires --force
The system-config-printer package in [extra] is back: this package is no more split between system-config-printer-common and -gnome. As a side effect, this package now ships (the missing) *.pyc files and this causes the update to fail due to some conflicts. To update, please use the following: # pacman -Su --ignore system-config-printer # pacman -S system-config-printer --force -- Andrea Arch Linux Developer
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On Feb 8, 2013 2:56 PM, "Jan de Groot" wrote: > > On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: > > > I appreciate your effort and have no objection against adding Wayland. > > > > However, to limit people's enthusiasm about this, I just want to remark > > that having Wayland installed now is not incredibly useful: Weston is > > AFAIK the only compositor available at this time, and it is, as you > > mention, a demo (there was talk of some tiling WM being ported to > > Wayland, I forgot the name). Also you'll use XWayland most of the time. > > > > When Qt5 gets released and Qt4 applications are ported (which will > > likely happen for all Qt4 applications), there'll be at least many > > applications that can use Wayland natively. When KDE is ported to Qt5, > > we'll also get kwin as a more feature-rich Wayland compositor. > > > > I didn't read about the GTK situation yet, but I guess GTK3 has Wayland > > support already. > > This is my main concern for Wayland at this moment. Though it looks cool > to support new technology and having released versions of Wayland with > 1.x versioning, I doubt there's much use for it at this moment. Running > X inside of wayland is a nice feature for apps that aren't ported yet, > but if you only run apps that aren't ported yet, there's no use for > Wayland at the moment. Thomas and Jan are right, Wayland does not provide much at the moment. However, I still think it makes a lot of sense to ship it even now, provided it has no negative effects on the non-wayland usecase, and it does not entail too much work. It would at least make life simpler for devs/testers of wayland/weston/kwin and friends. Cheers, Tom
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On Feb 8, 2013 2:56 PM, "Jan de Groot" wrote: > > On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: > > > I appreciate your effort and have no objection against adding Wayland. > > > > However, to limit people's enthusiasm about this, I just want to remark > > that having Wayland installed now is not incredibly useful: Weston is > > AFAIK the only compositor available at this time, and it is, as you > > mention, a demo (there was talk of some tiling WM being ported to > > Wayland, I forgot the name). Also you'll use XWayland most of the time. > > > > When Qt5 gets released and Qt4 applications are ported (which will > > likely happen for all Qt4 applications), there'll be at least many > > applications that can use Wayland natively. When KDE is ported to Qt5, > > we'll also get kwin as a more feature-rich Wayland compositor. > > > > I didn't read about the GTK situation yet, but I guess GTK3 has Wayland > > support already. > > This is my main concern for Wayland at this moment. Though it looks cool > to support new technology and having released versions of Wayland with > 1.x versioning, I doubt there's much use for it at this moment. Running > X inside of wayland is a nice feature for apps that aren't ported yet, > but if you only run apps that aren't ported yet, there's no use for > Wayland at the moment. Thomas and Jan are right, Wayland does not provide much at the moment. However, I still think it makes a lot of sense to ship it even now, provided it has no negative effects on the non-wayland usecase, and it does not entail too much work. It would at least make life simpler for devs/testers of wayland/weston/kwin and friends. Cheers, Tom
Re: [arch-dev-public] kdelibs / docbook-xsl
On 8 February 2013 17:27, Tom Gundersen wrote: > Please someone move it. Im not at home at the moment. Moved.
Re: [arch-dev-public] kdelibs / docbook-xsl
Please someone move it. Im not at home at the moment. T On Feb 8, 2013 12:01 PM, "Ike Devolder" wrote: > Hi, > > Is there something stopping us moving docbook-xsl and co to extra, > kdelibs 4.10.0-2 references to is and is already moved to extra > > thx > -- > Ike >
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On Fri, Feb 08, 2013 at 02:55:51PM +0100, Jan de Groot wrote: > On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: > > > I appreciate your effort and have no objection against adding Wayland. > > > > However, to limit people's enthusiasm about this, I just want to remark > > that having Wayland installed now is not incredibly useful: Weston is > > AFAIK the only compositor available at this time, and it is, as you > > mention, a demo (there was talk of some tiling WM being ported to > > Wayland, I forgot the name). Also you'll use XWayland most of the time. > > > > When Qt5 gets released and Qt4 applications are ported (which will > > likely happen for all Qt4 applications), there'll be at least many > > applications that can use Wayland natively. When KDE is ported to Qt5, > > we'll also get kwin as a more feature-rich Wayland compositor. > > > > I didn't read about the GTK situation yet, but I guess GTK3 has Wayland > > support already. > > This is my main concern for Wayland at this moment. Though it looks cool > to support new technology and having released versions of Wayland with > 1.x versioning, I doubt there's much use for it at this moment. Running > X inside of wayland is a nice feature for apps that aren't ported yet, > but if you only run apps that aren't ported yet, there's no use for > Wayland at the moment. > > Anyways, to get everything out of Wayland, this needs: > - wayland backend in GTK3 > - GL backend in cairo (experimental) > - EGL/GLES backends in Mesa > > For GTK3 I don't think there's a big issue, it's just a backend > resulting in some additional files and (optional?) dependencies. > > 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
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: > I appreciate your effort and have no objection against adding Wayland. > > However, to limit people's enthusiasm about this, I just want to remark > that having Wayland installed now is not incredibly useful: Weston is > AFAIK the only compositor available at this time, and it is, as you > mention, a demo (there was talk of some tiling WM being ported to > Wayland, I forgot the name). Also you'll use XWayland most of the time. > > When Qt5 gets released and Qt4 applications are ported (which will > likely happen for all Qt4 applications), there'll be at least many > applications that can use Wayland natively. When KDE is ported to Qt5, > we'll also get kwin as a more feature-rich Wayland compositor. > > I didn't read about the GTK situation yet, but I guess GTK3 has Wayland > support already. This is my main concern for Wayland at this moment. Though it looks cool to support new technology and having released versions of Wayland with 1.x versioning, I doubt there's much use for it at this moment. Running X inside of wayland is a nice feature for apps that aren't ported yet, but if you only run apps that aren't ported yet, there's no use for Wayland at the moment. Anyways, to get everything out of Wayland, this needs: - wayland backend in GTK3 - GL backend in cairo (experimental) - EGL/GLES backends in Mesa For GTK3 I don't think there's a big issue, it's just a backend resulting in some additional files and (optional?) dependencies. 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. 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.
[arch-dev-public] kdelibs / docbook-xsl
Hi, Is there something stopping us moving docbook-xsl and co to extra, kdelibs 4.10.0-2 references to is and is already moved to extra thx -- Ike pgpjBczJN5EWU.pgp Description: PGP signature
Re: [arch-dev-public] [RFC] Add Wayland/Weston
Am 08.02.2013 01:23, schrieb Sébastien Luttringer: > Hello gentleman, > > Wayland is now in version 1.0.4[1]. I plan to move it to community to > offer a first support of the wayland protocol into Archlinux. > This will allow toolkit[2][3] packages to smoothly enable wayland > support when maintainers wants and let users try this > next-to-systemd-troll[4]. > > After Wayland I would add the demo compositor Weston to our community > repositories. To do this we needs to: > - enable wayland support into mesa ; > - enable wayland support into cairo. > > If the both maintainers agreed to add support, we need to find a > gentle developper which can move wayland to extra[5]. I appreciate your effort and have no objection against adding Wayland. However, to limit people's enthusiasm about this, I just want to remark that having Wayland installed now is not incredibly useful: Weston is AFAIK the only compositor available at this time, and it is, as you mention, a demo (there was talk of some tiling WM being ported to Wayland, I forgot the name). Also you'll use XWayland most of the time. When Qt5 gets released and Qt4 applications are ported (which will likely happen for all Qt4 applications), there'll be at least many applications that can use Wayland natively. When KDE is ported to Qt5, we'll also get kwin as a more feature-rich Wayland compositor. I didn't read about the GTK situation yet, but I guess GTK3 has Wayland support already. signature.asc Description: OpenPGP digital signature
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 14 new packages in last 24 hours * 1 known bad package * 0 packages not accepting signoffs * 15 fully signed off packages * 310 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (14 total) == * groff-1.22.2-1 (i686) * krb5-1.11-3 (i686) * libevent-2.0.21-2 (i686) * openssl-1.0.1.d-1 (i686) * groff-1.22.2-1 (x86_64) * krb5-1.11-3 (x86_64) * libevent-2.0.21-2 (x86_64) * openssl-1.0.1.d-1 (x86_64) * docbook-xsl-1.78.0-1 (any) * kdelibs-4.10.0-2 (i686) * libdrm-2.4.42-1 (i686) * kdelibs-4.10.0-2 (x86_64) * libdrm-2.4.42-1 (x86_64) * netctl-0.5-1 (any) == Incomplete signoffs for [core] (10 total) == * btrfs-progs-0.20rc1.1-1 (i686) 0/2 signoffs * groff-1.22.2-1 (i686) 0/2 signoffs * libevent-2.0.21-2 (i686) 1/2 signoffs * linux-3.7.6-1 (i686) 1/2 signoffs * linux-lts-3.0.62-1 (i686) 1/2 signoffs * openssl-1.0.1.d-1 (i686) 1/2 signoffs * syslinux-5.01-1 (i686) 1/2 signoffs * btrfs-progs-0.20rc1.1-1 (x86_64) 1/2 signoffs * groff-1.22.2-1 (x86_64) 0/2 signoffs * libevent-2.0.21-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (214 total) == * calligra-l10n-2.6.0-1 (any) 0/2 signoffs * docbook-xsl-1.78.0-1 (any) 0/2 signoffs * hwdetect-2013.02-1 (any) 0/2 signoffs * kde-base-artwork-4.10.0-1 (any) 0/2 signoffs * kde-l10n-4.10.0-1 (any) 0/2 signoffs * kde-meta-4.10-1 (any) 0/2 signoffs * kde-wallpapers-4.10.0-1 (any) 0/2 signoffs * oxygen-icons-4.10.0-1 (any) 0/2 signoffs * akonadi-1.9.0-2 (i686) 0/2 signoffs * calligra-2.6.0-1 (i686) 0/2 signoffs * kactivities-4.10.0-1 (i686) 0/2 signoffs * kdeaccessibility-jovie-4.10.0-1 (i686) 0/2 signoffs * kdeaccessibility-kaccessible-4.10.0-1 (i686) 0/2 signoffs * kdeaccessibility-kmag-4.10.0-1 (i686) 0/2 signoffs * kdeaccessibility-kmousetool-4.10.0-1 (i686) 0/2 signoffs * kdeaccessibility-kmouth-4.10.0-1 (i686) 0/2 signoffs * kdeadmin-4.10.0-1 (i686) 0/2 signoffs * kdeartwork-4.10.0-1 (i686) 0/2 signoffs * kdebase-4.10.0-1 (i686) 0/2 signoffs * kdebase-konsole-4.10.0-1 (i686) 0/2 signoffs * kdebase-runtime-4.10.0-1 (i686) 0/2 signoffs * kdebase-workspace-4.10.0-1 (i686) 0/2 signoffs * kdebindings-kimono-4.10.0-1 (i686) 0/2 signoffs * kdebindings-korundum-4.10.0-1 (i686) 0/2 signoffs * kdebindings-kross-4.10.0-1 (i686) 0/2 signoffs * kdebindings-perlkde-4.10.0-1 (i686) 0/2 signoffs * kdebindings-perlqt-4.10.0-1 (i686) 0/2 signoffs * kdebindings-python-4.10.0-1 (i686) 0/2 signoffs * kdebindings-qtruby-4.10.0-1 (i686) 0/2 signoffs * kdebindings-qyoto-4.10.0-1 (i686) 0/2 signoffs * kdebindings-smokegen-4.10.0-1 (i686) 0/2 signoffs * kdebindings-smokekde-4.10.0-1 (i686) 0/2 signoffs * kdebindings-smokeqt-4.10.0-1 (i686) 0/2 signoffs * kdeedu-analitza-4.10.0-1 (i686) 0/2 signoffs * kdeedu-blinken-4.10.0-1 (i686) 0/2 signoffs * kdeedu-cantor-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kalgebra-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kalzium-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kanagram-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kbruch-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kgeography-4.10.0-1 (i686) 0/2 signoffs * kdeedu-khangman-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kig-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kiten-4.10.0-1 (i686) 0/2 signoffs * kdeedu-klettres-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kmplot-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kstars-4.10.0-1 (i686) 0/2 signoffs * kdeedu-ktouch-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kturtle-4.10.0-1 (i686) 0/2 signoffs * kdeedu-kwordquiz-4.10.0-1 (i686) 0/2 signoffs * kdeedu-marble-4.10.0-1 (i686) 0/2 signoffs * kdeedu-pairs-4.10.0-1 (i686) 0/2 signoffs * kdeedu-parley-4.10.0-1 (i686) 0/2 signoffs * kdeedu-rocs-4.10.0-1 (i686) 0/2 signoffs * kdeedu-step-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-gwenview-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-kamera-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-kcolorchooser-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-kgamma-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-kolourpaint-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-kruler-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-ksaneplugin-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-ksnapshot-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-mobipocket-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-okular-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-strigi-analyzer-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-svgpart-4.10.0-1 (i686) 0/2 signoffs * kdegraphics-thumbnailers-4.10.0-1 (i686) 0/2 signoffs * kdelib
Re: [arch-dev-public] [RFC] Add Wayland/Weston
Hi Sébastien, Thanks for bringing this up! On Fri, Feb 8, 2013 at 1:23 AM, Sébastien Luttringer wrote: > If the both maintainers agreed to add support, we need to find a > gentle developper which can move wayland to extra[5]. I'd be happy to take wayland to extra when the time comes. Just let me know when you think it is ready. As long as there are no objections from mesa/cairo maintainers that is. Cheers, Tom
