request for intel driver update in rawhide
Hello, I wanted to point out that about a month and a half ago intel released a new driver version 2.13.0. Could we please have an update in rawhide? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Monday, November 08, 2010 16:26:22 Rex Dieter wrote:
Michal Hlavinka wrote:
I'm trying to find out what are differences between environment for local
rpm build and usual user's environment.
You mean the difference between rpmbuild and... a manual ./configure;
make?
something like that but without configure and make. Just the %check section.
Executed by rpmbuild at the end of rpm build process VS running %check section
script by hand with the same ksh binary.
For starters, see rpm's output from
rpm --eval %{configure} which sets variance build/optimization flags.
configure makes no difference here, because I'm always using the same ksh binary
and rpmbuild also does:
LANG=C ; export LANG
unset DISPLAY
I tried this, no difference
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, 2010-11-06 at 08:43 +, Richard W.M. Jones wrote: On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote: On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Monday, November 08, 2010 19:34:14 Richard W.M. Jones wrote:
On Mon, Nov 08, 2010 at 03:49:28PM +0100, Michal Hlavinka wrote:
I'm trying to find out what are differences between environment for
local rpm build and usual user's environment. I've added regression
tests to %check section of ksh spec file. These tests never fails
when executed in user's environment, but some of them always fail
when executed as part of rpm build process. I've tried to compare
variable in the environment and ulimit values, but there does not
seem to be any significant difference. I've also tried to use the
same script generated by rpmbuild for %check section (from
/var/tmp/rpm.*), but still it does not reproduce the problem. Any
ideas?
Is the spec file using %configure? That adds a lot of flags to the
configure script. Similarly make _vs_ make %{_smp_flags}.
I'm always using the same ksh binary, so this does not make any difference
Have you tried 'printenv' at the top of the %check section?
tried, but there does not seem to be significant difference. Also the %check
script I used was the same script rpmbuild creates from the %check section (in
/var/tmp/rpm*) and it defines the same environment:
---
#!/bin/sh
RPM_SOURCE_DIR=/home/mhlavink/gitf/ksh
RPM_BUILD_DIR=/home/mhlavink/gitf/ksh
RPM_OPT_FLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -
fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
RPM_ARCH=x86_64
RPM_OS=linux
export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_DOC_DIR=/usr/share/doc
export RPM_DOC_DIR
RPM_PACKAGE_NAME=ksh
RPM_PACKAGE_VERSION=20101026
RPM_PACKAGE_RELEASE=1.fc14
export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
LANG=C
export LANG
unset CDPATH DISPLAY ||:
RPM_BUILD_ROOT=/home/mhlavink/rpmbuild/BUILDROOT/ksh-20101026-1.fc14.x86_64
export RPM_BUILD_ROOT
PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig
export PKG_CONFIG_PATH
set -x
umask 022
cd /home/mhlavink/gitf/ksh
cd 'ksh-20101026'
unset DISPLAY
SHELL=$(ls $(pwd)/arch/*/bin/ksh)
cp $SHELL ${SHELL}4check
export SHELL=${SHELL}4check
cd src/cmd/ksh93/tests/
ulimit -c unlimited
if [ ! -e /dev/fd ]
then
echo ERROR: /dev/fd does not exist, regression tests skipped
exit 0
fi
$SHELL ./shtests 21 | tee testresults.log
killall ksh4check -s SIGKILL
...
---
Are you specifically running rpmbuild as the same user?
rpmbuild vs. just %check script executed by the same user on the same machine
Or are we
talking about rpmbuild in some other environment (mock or Koji)?
There is a Koji bug which affects ksh %check in particular
(RHBZ#639275).
I know. I reported that bug
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 10:05 AM, Jon Masters wrote: On Sat, 2010-11-06 at 08:43 +, Richard W.M. Jones wrote: On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote: On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. Looks more like a case of crying wolf to me. It's probably going to take a year before Wayland can be turned on as the default desktop and it's probably going to take several years before X can possibly go away so to use this kind of hyperbole is really just flamebait. It's fine to bring your concerns up but please postpone this we are all going to die routine until we *actually* have something to complain about. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora 14: pulseaudio eating cpu and memory without reason...
On Sat, 2010-11-06 at 21:43 +0200, Marius Andreiana wrote: Hi, Even when not playing any audio, pulseaudio uses CPU and memory PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2257 marius20 0 941m 7524 3188 S 2.9 0.4 14:22.57 chrome 2956 marius20 0 2026m 537m 9612 S 2.9 26.8 27:40.42 java 1500 marius20 0 437m 3100 1768 S 2.0 0.2 14:53.45 pulseaudio There are numerous reports about this http://www.google.com/search?sourceid=chromeie=UTF-8q=pulseaudio+cpu Do you have any suggestions for fixing or replacing it with something else? First hit for Pulseaudio debugging on everyone's favourite search engine: http://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-ISA/f14/master] Increase release number to be higher than perl one
Summary of changes: 2c7f08b... Increase release number to be higher than perl one (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Mock question
Den 09-11-2010 13:56, Brendan Jones skrev: On 11/09/2010 10:48 PM, Rasmus Ory Nielsen wrote: Unfortunately yum-builddep doesn't work for me. I need to be able to change $releasever and enabled repositories (hence the mock config file). Is that possible with yum-builddep? You could try something like: mock -r fedora-14-i386 --install @development-tools mock -r fedora-14-i386 --install yum-utils # chroot mock -v -r fedora-14-i386 --shell yum-builddep your.src.rpm Thanks again. This works... almost. Apparently yum-builddep only prints the first missing requires and then quits. Any ideas? Regards, Rasmus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Mon, Nov 08, 2010 at 02:50:15PM -0800, Adam Williamson wrote: On Sat, 2010-11-06 at 16:41 +, Richard W.M. Jones wrote: Really, I have no problem using my keyboard, Given your location and native language, I suspect your keyboard layout is en_US, in which case this isn't much of a surprise - it's one of the simplest cases (it requires one of the fewest numbers of characters of any layout) and it's also the one which gets most attention, development and testing. If you spoke Chinese - or, even better, something Indic - you may have a different perspective. =) Just to clear this up, I'm using a UK keyboard and switch between English and Japanese input (Anthy). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mock question
Hi, Given a SRPM file and a mock config file, how do I get a list of all missing buildrequires for this SRPM? Is it possible using the command line tools, or do I need to use the python api? I looked at the yum/mock api and it seemed a bit overwhelming. Thanks in advance. Regards, Rasmus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-ISA] Increase release number to be higher than perl one
commit 2c7f08beedcecd8e5a8e302661a1fbd55fb5a727
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 9 11:50:49 2010 +0100
Increase release number to be higher than perl one
Unbundled Class::ISA should be preferred.
perl-Class-ISA.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Class-ISA.spec b/perl-Class-ISA.spec
index bd50e21..3261d10 100644
--- a/perl-Class-ISA.spec
+++ b/perl-Class-ISA.spec
@@ -1,6 +1,6 @@
Name: perl-Class-ISA
Version:0.36
-Release:2%{?dist}
+Release:1003%{?dist}
Summary:Report the search path for a class's ISA tree
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{perl_vendorlib}/*
%changelog
+* Tue Nov 09 2010 Petr Pisar ppi...@redhat.com - 0.36-1003
+- Increase release number to be higher than Perl core package (bug #651317)
+
* Mon May 10 2010 Marcela Mašláňová mmasl...@redhat.com 0.36-2
- fix of conflicting man pages
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: What are differences between real and rpmbuild's environment?
On Tue, Nov 09, 2010 at 10:07:05AM +0100, Michal Hlavinka wrote:
tried, but there does not seem to be significant difference. Also the %check
script I used was the same script rpmbuild creates from the %check section
(in
/var/tmp/rpm*) and it defines the same environment:
---
#!/bin/sh
RPM_SOURCE_DIR=/home/mhlavink/gitf/ksh
RPM_BUILD_DIR=/home/mhlavink/gitf/ksh
RPM_OPT_FLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -
fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
RPM_ARCH=x86_64
RPM_OS=linux
export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_DOC_DIR=/usr/share/doc
export RPM_DOC_DIR
RPM_PACKAGE_NAME=ksh
RPM_PACKAGE_VERSION=20101026
RPM_PACKAGE_RELEASE=1.fc14
export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
LANG=C
export LANG
unset CDPATH DISPLAY ||:
RPM_BUILD_ROOT=/home/mhlavink/rpmbuild/BUILDROOT/ksh-20101026-1.fc14.x86_64
export RPM_BUILD_ROOT
PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig
export PKG_CONFIG_PATH
set -x
umask 022
cd /home/mhlavink/gitf/ksh
cd 'ksh-20101026'
unset DISPLAY
SHELL=$(ls $(pwd)/arch/*/bin/ksh)
cp $SHELL ${SHELL}4check
export SHELL=${SHELL}4check
cd src/cmd/ksh93/tests/
ulimit -c unlimited
if [ ! -e /dev/fd ]
then
echo ERROR: /dev/fd does not exist, regression tests skipped
exit 0
fi
$SHELL ./shtests 21 | tee testresults.log
killall ksh4check -s SIGKILL
...
---
Maybe something strange like the size in bytes of the environment
is crossing some limit?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock question
On 11/09/2010 10:33 PM, Rasmus Ory Nielsen wrote: Hi, Given a SRPM file and a mock config file, how do I get a list of all missing buildrequires for this SRPM? Is it possible using the command line tools, or do I need to use the python api? I looked at the yum/mock api and it seemed a bit overwhelming. Hi you could use yum-builddep regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock question
Hi, Den 09-11-2010 13:37, Brendan Jones skrev: On 11/09/2010 10:33 PM, Rasmus Ory Nielsen wrote: Hi, Given a SRPM file and a mock config file, how do I get a list of all missing buildrequires for this SRPM? Is it possible using the command line tools, or do I need to use the python api? I looked at the yum/mock api and it seemed a bit overwhelming. Hi you could use yum-builddep Thanks for your reply. Unfortunately yum-builddep doesn't work for me. I need to be able to change $releasever and enabled repositories (hence the mock config file). Is that possible with yum-builddep? Regards, Rasmus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
2010/11/9 Jason L Tibbitts III ti...@math.uh.edu: RK == Rudolf Kastl che...@gmail.com writes: RK Hello, I wanted to point out that about a month and a half ago intel RK released a new driver version 2.13.0. Could we please have an update RK in rawhide? Currently rawhide seems to be at 2.13.901, a development version past the one you are requesting. not really: http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 guess you pulled that somewhere else. kind regards, Rudolf Kastl - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock question
On 11/09/2010 10:48 PM, Rasmus Ory Nielsen wrote: Unfortunately yum-builddep doesn't work for me. I need to be able to change $releasever and enabled repositories (hence the mock config file). Is that possible with yum-builddep? You could try something like: mock -r fedora-14-i386 --install @development-tools mock -r fedora-14-i386 --install yum-utils # chroot mock -v -r fedora-14-i386 --shell yum-builddep your.src.rpm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
On Tue, 2010-11-09 at 08:00 -0600, Jason L Tibbitts III wrote: RK == Rudolf Kastl che...@gmail.com writes: RK http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 RK guess you pulled that somewhere else. fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec 2.13.901 wasn't built yet because it required waiting for a libdrm update. Should have that pushed out today. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
RK == Rudolf Kastl che...@gmail.com writes: RK Hello, I wanted to point out that about a month and a half ago intel RK released a new driver version 2.13.0. Could we please have an update RK in rawhide? Currently rawhide seems to be at 2.13.901, a development version past the one you are requesting. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
2010/11/9 Adam Jackson a...@redhat.com: On Tue, 2010-11-09 at 08:00 -0600, Jason L Tibbitts III wrote: RK == Rudolf Kastl che...@gmail.com writes: RK http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 RK guess you pulled that somewhere else. fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec 2.13.901 wasn't built yet because it required waiting for a libdrm update. Should have that pushed out today. - ajax thanks ajax! kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
Michal Hlavinka mhlav...@redhat.com writes: So it seems rpmbuild has a bug and breaks sigpipe somehow... Perhaps it leaves it ignored? You can check with /proc/$$/status. $ (trap '' SIGPIPE; bash x.sh) early termination not causing broken Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 16:09 +0100, Dennis Jacobfeuerborn wrote: On 11/09/2010 10:05 AM, Jon Masters wrote: On Sat, 2010-11-06 at 08:43 +, Richard W.M. Jones wrote: On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote: On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. Looks more like a case of crying wolf to me. It's probably going to take a year before Wayland can be turned on as the default desktop and it's probably going to take several years before X can possibly go away so to use this kind of hyperbole is really just flamebait. It's fine to bring your concerns up but please postpone this we are all going to die routine until we *actually* have something to complain about. At which point, it's too late. Unless Server-y people point out that things like network apps actually matter, the default path may be to do what will look nice on a local desktop (for the record, I can see full screen tearing-free graphics both using upstream Intel and upstream ATI drivers - one on a laptop, one dual headed desktop - just fine already). Like Rich, I enjoy being able to start e.g. rawhide apps running on a virtual machine and have them render to my local X server, or start a second X and have an entire gnome-session running from a rawhide box sitting on my virt server. Also, although there are other ways to do it, my typical use of virt-manager these days is by forwarded X over ssh. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Tue, 9 Nov 2010, Michal Hlavinka wrote:
On Monday, November 08, 2010 15:49:28 Michal Hlavinka wrote:
Hi,
I'm trying to find out what are differences between environment for local
rpm build and usual user's environment. I've added regression tests to
%check section of ksh spec file. These tests never fails when executed in
user's environment, but some of them always fail when executed as part of
rpm build process. I've tried to compare variable in the environment and
ulimit values, but there does not seem to be any significant difference.
I've also tried to use the same script generated by rpmbuild for %check
section (from
/var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas?
Michal
Ok, I've forgot to mention a few things and I'll also add new information I've
found.
- Tests that are failing are all about pipe and sigpipe/pipefail.
- I've tried to reproduce this just with empty spec file - I've moved the
tests in %prep section just after sources are unpacked and patched (required
for running tests) and it still fails
- I've prepared simple script with just the first failing test and. I've
modified this test slightly so it can be used with bash too. BASH has no
problem with this test when executed from terminal. When it's executed from
prep section in rpmbuild it fails too.
This is the test script (defined as Source6:)
#
s=$SECONDS
set -o pipefail
for ((i=0; i 30; i++))
do printf hello 2/dev/null
sleep .1
done | /bin/sleep 1
(( (SECONDS-s) 2 )) || printf 2 'early termination not causing broken
pipe'
#
and it's being executed from %prep section:
#
%prep
export SHELL=/bin/bash
time $SHELL %{SOURCE6}
exit 1
#
Correct real time is 1 sec something, when broken, time is 3 seconds something
and error message is produced.
So it seems rpmbuild has a bug and breaks sigpipe somehow...
Any comments before I file bug?
Oh, SIGPIPE. That explains... nspr (to which rpm is indirectly married to
through nss) quietly sets SIG_IGN on SIGPIPE on initialization, triggering
these kind of obscure misbehaviors in rpm-related scripts. Ain't the first
time for sure, but the first time somebody manages to trigger the issue in
build.
Fixing is easy enough, but do file a bug so I wont forget. Extra bonus for
minimal reproducer.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Monday, November 08, 2010 15:49:28 Michal Hlavinka wrote:
Hi,
I'm trying to find out what are differences between environment for local
rpm build and usual user's environment. I've added regression tests to
%check section of ksh spec file. These tests never fails when executed in
user's environment, but some of them always fail when executed as part of
rpm build process. I've tried to compare variable in the environment and
ulimit values, but there does not seem to be any significant difference.
I've also tried to use the same script generated by rpmbuild for %check
section (from
/var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas?
Michal
Ok, I've forgot to mention a few things and I'll also add new information I've
found.
- Tests that are failing are all about pipe and sigpipe/pipefail.
- I've tried to reproduce this just with empty spec file - I've moved the
tests in %prep section just after sources are unpacked and patched (required
for running tests) and it still fails
- I've prepared simple script with just the first failing test and. I've
modified this test slightly so it can be used with bash too. BASH has no
problem with this test when executed from terminal. When it's executed from
prep section in rpmbuild it fails too.
This is the test script (defined as Source6:)
#
s=$SECONDS
set -o pipefail
for ((i=0; i 30; i++))
do printf hello 2/dev/null
sleep .1
done | /bin/sleep 1
(( (SECONDS-s) 2 )) || printf 2 'early termination not causing broken
pipe'
#
and it's being executed from %prep section:
#
%prep
export SHELL=/bin/bash
time $SHELL %{SOURCE6}
exit 1
#
Correct real time is 1 sec something, when broken, time is 3 seconds something
and error message is produced.
So it seems rpmbuild has a bug and breaks sigpipe somehow...
Any comments before I file bug?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
debugging build hang in koji ?
So, local mock x86_64 builds work just fine. But AFAICS the build just hangs in fairly random places when put through x86_64 koji, anyone got any good ideas about how to find out even what process is hung ? e.g. http://koji.fedoraproject.org/koji/getfile?taskID=2589336name=build.logoffset=-4000 is an example of the hang, i.e. time taken was 0.004 seconds zip warning: help.jar not found or empty adding: com.sun.PresenterScreen-linux_x86_64/presenter.xhp (deflated 81%) and nothing else. C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
RK == Rudolf Kastl che...@gmail.com writes: RK http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 RK guess you pulled that somewhere else. fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: debugging build hang in koji ?
A few folks have sufficient access to log into the builders and strace things if necessary. You're welcome to ping me on IRC. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: debugging build hang in koji ?
Caolán McNamara caol...@redhat.com writes: time taken was 0.004 seconds zip warning: help.jar not found or empty adding: com.sun.PresenterScreen-linux_x86_64/presenter.xhp (deflated 81%) and nothing else. Perhaps some ENOSPC condition? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Tuesday, November 09, 2010 16:30:17 Panu Matilainen wrote:
On Tue, 9 Nov 2010, Michal Hlavinka wrote:
On Monday, November 08, 2010 15:49:28 Michal Hlavinka wrote:
Hi,
I'm trying to find out what are differences between environment for
local rpm build and usual user's environment. I've added regression
tests to %check section of ksh spec file. These tests never fails when
executed in user's environment, but some of them always fail when
executed as part of rpm build process. I've tried to compare variable
in the environment and ulimit values, but there does not seem to be any
significant difference. I've also tried to use the same script
generated by rpmbuild for %check section (from
/var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas?
Michal
Ok, I've forgot to mention a few things and I'll also add new information
I've found.
- Tests that are failing are all about pipe and sigpipe/pipefail.
- I've tried to reproduce this just with empty spec file - I've moved
the tests in %prep section just after sources are unpacked and patched
(required for running tests) and it still fails
- I've prepared simple script with just the first failing test and. I've
modified this test slightly so it can be used with bash too. BASH has no
problem with this test when executed from terminal. When it's executed
from prep section in rpmbuild it fails too.
This is the test script (defined as Source6:)
#
s=$SECONDS
set -o pipefail
for ((i=0; i 30; i++))
do printf hello 2/dev/null
sleep .1
done | /bin/sleep 1
(( (SECONDS-s) 2 )) || printf 2 'early termination not causing broken
pipe'
#
and it's being executed from %prep section:
#
%prep
export SHELL=/bin/bash
time $SHELL %{SOURCE6}
exit 1
#
Correct real time is 1 sec something, when broken, time is 3 seconds
something and error message is produced.
So it seems rpmbuild has a bug and breaks sigpipe somehow...
Any comments before I file bug?
Oh, SIGPIPE. That explains... nspr (to which rpm is indirectly married to
through nss) quietly sets SIG_IGN on SIGPIPE on initialization, triggering
these kind of obscure misbehaviors in rpm-related scripts. Ain't the first
time for sure, but the first time somebody manages to trigger the issue in
build.
Fixing is easy enough, but do file a bug so I wont forget. Extra bonus for
minimal reproducer.
Thanks, filed as #651463
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/9/10 8:23 AM, Andrew Haley wrote: I've seen the responses on the Wayland list, and it's always Wayland isn't intended to do that. So, there's no point raising objections there. The risk is that Wayland gets developed and a bunch of key applications in Fedora get broken. The Wayland guys are not the people to talk to, since network transparency isn't on their radar, from what I can see. What makes you think that carping about it here will have any effect, particularly because NOBODY HAS PROPOSED WE USE WAYLAND yet. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 02:48 -0500, Felix Miata wrote: On 2010/11/09 07:39 (GMT+0100) David Tardon composed: Btw, maybe you should look at the proverb in your signature and try to apply it to yourself. Because in this thread you have neither shown understanding nor used pleasant words. The words I used are not inherently unpleasant, only unpleasant because people don't want to hear the truth they report. Testers who can't fix bugs are treated like lepers compared to those who provide patches, deserving of less than equal respect. As a Bugzilla user for a decade or so, I understand this very well. It's a constant battle to remember to spend enough time rereading before sending in order to prevent inappropriate language to escape, particularly as given so little respect in the whole test and bug process overall (e.g. not only the duping of good older bugs to newer bugs, but Bugzilla itself: https://bugzilla.redhat.com/show_bug.cgi?id=638726 ). ...another thread in which you bang on about rudeness from others but can't seem to recognize it in yourself. Note how the first comment on that bug is me agreeing with you about that specific problem. Where you get into trouble is where you start making grand declarations about how the entire websites team should be run. This isn't the Godfather, and you're not Marlon Brando. Exactly as Karsten said in that bug, inflating a single bug into a grand theory of everything is counter-productive, and your implicit suggestion that they don't know what the hell they're doing was deeply insulting to those who work on the websites team. The problem with this thread is that you still haven't explained one fundamental thing which you keep taking for granted and assume everyone agrees with you about: you think an older bug being marked as a duplicate of a newer bug is a huge problem. What I'm trying to explain is that not everyone *does* agree with you about this; I for one don't see what the big deal is. There isn't a prize system for bug reports. No-one's keeping track of who files bugs and who 'won' in terms of reporting the bug first. You don't lose any points if your report gets closed as a dupe of someone else's. There just isn't a 'respect' issue here, as far as I can see, which you seem to assume is the case. When there are duplicate reports and someone cleans them up and fixes the bug, that's a *good* thing. I can see an argument here for keeping the older bug open as a bug against xorg, as the fix to pyxf86config kinda works around an underlying bug in xorg which hasn't gone away (someone's explained this in the bug thread) - but that's just a plain technical discussion. I really don't see why it ought to make anyone get hot under the collar. So, once more for the cheap seats: *why* do you think closing an older bug as a dupe of a newer one is a respect issue? What's the big problem with it? As the subject says, I see no point in further bother. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/Auth/rudeweb.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. AIUI the Grand Plan is for everyone to write apps in GTK+ and Qt (which is more or less the case already), and for GTK+ and Qt to be compatible with *both* Wayland and X. Again AIUI, there's no impediment to this in the design of Wayland and it's actually what Wayland's designers expect to happen, in order to make sure things still work on platforms where Wayland isn't available, and to deal with exactly this kind of case. So I think the future vision is that if you're running on your system you get a shiny Wayland-y version, and if you run something via ssh -x you get a slightly less pretty X version. And all the Hard Stuff happens in the background and you don't really have to care about it. If I'm wrong, someone correct me, but I think I'm right and people are getting a rather misleading vision of a glorious future where everything only runs on Wayland, which I don't think is the idea at all. (presumably if you're one of the few apps which don't use a toolkit, you should yourself make sure you support both Wayland and X. Or make sure no-one wants to run your apps over a network, or there's another way to do it.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 12:29 +, Richard W.M. Jones wrote: On Mon, Nov 08, 2010 at 02:50:15PM -0800, Adam Williamson wrote: On Sat, 2010-11-06 at 16:41 +, Richard W.M. Jones wrote: Really, I have no problem using my keyboard, Given your location and native language, I suspect your keyboard layout is en_US, in which case this isn't much of a surprise - it's one of the simplest cases (it requires one of the fewest numbers of characters of any layout) and it's also the one which gets most attention, development and testing. If you spoke Chinese - or, even better, something Indic - you may have a different perspective. =) Just to clear this up, I'm using a UK keyboard and switch between English and Japanese input (Anthy). d'oh, right, too many Joneses around, I forgot you were the one who uses Japanese too. =) well, I imagine you know more about this than me, but I run with Japanese input support at least occasionally, and my impression is that a lot of it is a fragile tower necessitated by the fact that the deep underlying stuff was coded with the assumption that all anyone ever wanted to type was ASCII. It feels to me like CJK input breaks a lot more than it really *should*, if you step back and look at it from first principles - it's just an input method, and we'd feel pretty dumb if we shipped a release where you can't type the letter Q, yet this sort of thing seems to happen all the time with non-en_US input. From a QA perspective, I know keyboard layout selection and complex character input is one of the things that breaks so often we had to stick an explicit validation test in for it. I don't know how much of this is related to X specifically, but I know it's certainly one of the things involved which makes the whole process of providing switchable input methods so icky. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 03:57 PM, Jesse Keating wrote: On 11/9/10 7:23 AM, Jon Masters wrote: At which point, it's too late. Unless Server-y people point out that things like network apps actually matter, the default path may be to do what will look nice on a local desktop (for the record, I can see full screen tearing-free graphics both using upstream Intel and upstream ATI drivers - one on a laptop, one dual headed desktop - just fine already). Like Rich, I enjoy being able to start e.g. rawhide apps running on a virtual machine and have them render to my local X server, or start a second X and have an entire gnome-session running from a rawhide box sitting on my virt server. Also, although there are other ways to do it, my typical use of virt-manager these days is by forwarded X over ssh. Perhaps you should take your concerns to a mailing list the Wayland developers actually read and participate on. Banging on about it here, when nobody in Fedora has actually suggested we make use of Wayland, seems like a big waste of everybody's time. I've seen the responses on the Wayland list, and it's always Wayland isn't intended to do that. So, there's no point raising objections there. The risk is that Wayland gets developed and a bunch of key applications in Fedora get broken. The Wayland guys are not the people to talk to, since network transparency isn't on their radar, from what I can see. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing. You are, in short, scared. It's well established by now that the problems of window system, rendering system, input system, and application remoting are in fact pretty dang separate, and that the more you conflate them the worse your solution ends up being. You can thank X for being ~24 years of research into just how badly you can conflate them and get away with it, but it's just about reached the limits of what it can do. I'm sad to see it go too, but I've been working to knock X out of hegemony for the last six years, and I'm quite sure that the sooner that happens the better for all concerned. Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 11:55 AM, Adam Jackson a...@redhat.com wrote: On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing. I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. So, You are, in short, scared. ... I think this is a rather unfair characterization. Perhaps the concerns that people have are misplaced—— perhaps a switch to somehow wayland doesn't imply a loss of reasonably functioning network transparency. If so, then clarifying it beyond your gtk/qt will offer both X and wayland would be helpful. Especially since providing both TUI and GUI administrative tools hasn't really panned out in practice. In any case, I can't see that there has been any real concern raised about _change_. Fedora is full of change. People are raising and arguing specific concerns about the nature of the changes. Please treat your list co-habitants with a little more respect. [snip] Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 11:44 -0500, Gregory Maxwell wrote: I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install. Well, the Fedora graphics cabal is basically me, Kevin Martin, and Dave Airlie, and since we were hanging out at Plumbers last week and talked about this, here's the rough consensus I think we reached: Wayland's not a usable default yet. It'll probably be packaged in F15 as something you can play with. We don't even have a complete list of transition criteria yet, let alone a timeframe for switching the default. But it's likely to happen eventually because it's a serious win for a lot of things, and the downsides are pretty negligible despite the fear from the peanut gallery. Feel free to quote me. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 08:45 -0800, Adam Williamson wrote: So, once more for the cheap seats: *why* do you think closing an older bug as a dupe of a newer one is a respect issue? What's the big problem with it? As a devel - I've found that I close bugs as dupes of other bugs and I try to have the bug which has the most succinct explanation of the problem and the solution as the one that everything is duped TO. That way when I look at open bugs I get the best one, not the others. the order they came in doesn't matter, imo. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 10:23:22AM -0500, Jon Masters wrote: At which point, it's too late. Unless Server-y people I object strongly to this perception that nobody involved in developing desktop technologies has any idea what server admins want. What we're seeing is the development of technologies that bear little resemblance to the Unix way of doing things, but which will in many cases make life better for server admins. systemd is a wonderful example, and Wayland has the potential to be used in such a way that it will work much better for what you want than X currently does. To put it plainly: we know that people use X remoting. We're not going to change the default to something that makes that use-case impossible. Nobody who has any understanding of any of this is suggesting that we do so. It would be *stupid* to do so. But if you're asking for something that's identical to what we currently have (a reliance on a protocol that has an irritating number of round trips for something as simple as a keypress) then you're not going to get it, any more than us still providing support for a.out applications. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 17:25 +, Matthew Garrett wrote: On Tue, Nov 09, 2010 at 10:23:22AM -0500, Jon Masters wrote: At which point, it's too late. Unless Server-y people I object strongly to this perception that nobody involved in developing desktop technologies has any idea what server admins want. What we're seeing is the development of technologies that bear little resemblance to the Unix way of doing things, but which will in many cases make life better for server admins. systemd is a wonderful example, and Wayland has the potential to be used in such a way that it will work much better for what you want than X currently does. I can agree with that. I'd like for something in return - could the folks working on desktop technologies acknowledge that those of us who are more server-oriented have an idea of what users want? B/c the perception I get is that only the desktop-oriented folks know what users want or need and the server-oriented folks do not. I think that's in error, too. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 05:13 PM, Adam Jackson wrote: On Tue, 2010-11-09 at 11:44 -0500, Gregory Maxwell wrote: I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install. Well, the Fedora graphics cabal is basically me, Kevin Martin, and Dave Airlie, and since we were hanging out at Plumbers last week and talked about this, here's the rough consensus I think we reached: Wayland's not a usable default yet. It'll probably be packaged in F15 as something you can play with. We don't even have a complete list of transition criteria yet, let alone a timeframe for switching the default. But it's likely to happen eventually because it's a serious win for a lot of things, and the downsides are pretty negligible despite the fear from the peanut gallery. I'm wondering of I'm reading this correctly. The downsides that have been described are quite severe in contrast to the possible benefits. It is, of course, possible that a mistake has been made, and the acute loss of functionality is just scaremongering. It's also possible that I've misunderstood something. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 04:49 PM, Adam Williamson wrote: On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. AIUI the Grand Plan is for everyone to write apps in GTK+ and Qt (which is more or less the case already), and for GTK+ and Qt to be compatible with *both* Wayland and X. Again AIUI, there's no impediment to this in the design of Wayland and it's actually what Wayland's designers expect to happen, in order to make sure things still work on platforms where Wayland isn't available, and to deal with exactly this kind of case. So I think the future vision is that if you're running on your system you get a shiny Wayland-y version, and if you run something via ssh -x you get a slightly less pretty X version. And all the Hard Stuff happens in the background and you don't really have to care about it. Well, that would be an excellent result. All it takes is someone who is a member of the cabal (TINC) to confirm this, and everyone will be happy. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 12:16 -0500, seth vidal wrote: On Tue, 2010-11-09 at 08:45 -0800, Adam Williamson wrote: So, once more for the cheap seats: *why* do you think closing an older bug as a dupe of a newer one is a respect issue? What's the big problem with it? As a devel - I've found that I close bugs as dupes of other bugs and I try to have the bug which has the most succinct explanation of the problem and the solution as the one that everything is duped TO. That way when I look at open bugs I get the best one, not the others. the order they came in doesn't matter, imo. right, that seems to be the approach Lubomir took. I don't see a problem with that approach, to be frank, I can't see any intrinsic reason why we should prescribe always making the oldest report the 'original'; it does seem to make more sense to make the most useful report the 'original'. Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
Adam Williamson wrote: Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 11:49 -0600, Michael Cronenworth wrote: Adam Williamson wrote: Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 well hey, that saves me the trouble. :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SWI Prolog is gone from F13 and F14
Is anyone interested in resurrecting SWI Prolog? I just noticed that it was dropped from F13 and F14. The version in F12 was 5.7.11, the current version is 5.10.2 according to: http://www.swi-prolog.org/ The previous packager was Gerard Milmeister. http://www.mail-archive.com/devel@lists.fedoraproject.org/msg10336.html Thanks! Joel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Gregory Maxwell (gmaxw...@gmail.com) said: So, You are, in short, scared. ... I think this is a rather unfair characterization. I don't know about that. Something new is discussed, and not everyone understands it, and they have concerns about how it may handle some particular cases. Now, people can go about the discussion in multiple ways. People can ask questions... get more info... try and understand the architecture... work on ways to fit into it, or move it, or discover better ways to accomplish that usage case. Or people can start posting how WE agree that THOSE people are coming into OUR space and I see how they're moving towards THEIR way doing things that are against OUR way of life, and how this is going to be a DISASTER and THOSE people must be STOPPED because THEY can't be reasoned with. (Paid for by the committee to elect blah blah fishcakes send your donations now so we can stop THOSE people and their AGENDA today.) And that's argumentation that's based on fear and instilling fear, and the more that an argument tends down those lines, the more I'd expect a response with condescension. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 6:12 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet. raising concerns != screaming the sky is falling Actually, if we go back to the first post in the thread... it was the premature suggestion by a by stander of bringing a still far from being finished technology into Fedora because another entity has prematurely decided to announce to the world that its going to be their default. That triggered a certain amount of bloodletting. If the original poster had come to the conclusion that it was far from being finished before writing the first post do you think that the original poster would have written that post in exactly the say way? Something the original poster should probably ruminate on. Generally speaking, if you aren't prepared to talk in detail about the suitability of a technology, you shouldn't bring it up for discussion like that. If you are personally interested in it, you should inquire as to whether there are people in our development community who are currently working on it and ask them questions about it. To come out of the gate suggesting its time to discuss it for inclusion is putting the card before the horse. What the original post is, is a classic enthusiast blunder. The active developers working on the problem space are more than capable of proposing wayland for inclusion and answer questions about wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 13:27 -0500, Bill Nottingham wrote: Matthew Miller (mat...@mattdm.org) said: B/c the perception I get is that only the desktop-oriented folks know what users want or need and the server-oriented folks do not. I think that's in error, too. In fact, us server-oriented folks are often blessed with working directly with actual users every day. Right, but that just leads to informing people that what users desparately need is a beating. Or it leads to the development of an expertise or an intuition about the complaints and issues a user actually runs into or about how the systems are actually being used. For example - talking to my former co-workers at a .edu I've determined that a LARGE number of users are no longer using local mail tools at all. They've transitioned exclusively to using gmail for all their accounts. The younger users in particular are expecting access to their information from all their devices independently - which gmail provides. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 17:40 +, Andrew Haley wrote: I'm wondering of I'm reading this correctly. The downsides that have been described are quite severe in contrast to the possible benefits. It is, of course, possible that a mistake has been made, and the acute loss of functionality is just scaremongering. It's also possible that I've misunderstood something. The downsides that have been described include: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.) - We lose support for older hardware! Yep. Here's a nickel. We have sufficient kernel support for this for the big three hardware vendors, and we're probably going to see more ports to the marginal hardware in the next year or two. Losing 1% of the hardware support isn't keeping me up at night. (But, we can't switch yet, because there's not a good fallback design to classic X on that kind of hardware, and it includes things enterprisey people run on; so we're not switching yet.) - All my X apps have to be ported! Yes, if they want to be native wayland clients, they do. If they don't, you can run a nested X server like on OSX. They'll still work as well as they ever did, and you even get to keep ssh forwarding of them. You can run a wayland server that does nothing but run a nested X server and you wouldn't ever know the difference. Except of course that your shell and your screensaver can be wayland apps, which means your screen locker will still work even if an app has a menu open, and you can actually do secure password input, and and and. (But, we really don't have _any_ good native wayland apps yet, thus the benefit of native apps are at the moment theoretical; so we're not switching yet.) Anything I'm missing? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 19:12 +0100, Dennis Jacobfeuerborn wrote: On 11/09/2010 06:12 PM, Gregory Maxwell wrote: On Tue, Nov 9, 2010 at 11:55 AM, Adam Jacksona...@redhat.com wrote: On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing. I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends. And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Answering that you can still use X on top of Wayland doesn't do anything: it is the native Wayland clients that are the issue. If they are not network transparent then it cannot be a suitable replacement for X because native clients _will_ appear and we end up with the situation of OSX and Windows where some clients are more equal than others. [snip] Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue. X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. Are the native wayland clients network transparent? If they are not, then it isn't a suitable replacement for X for my usage (or my 2 dozen users) and it means that either the native wayland clients or X clients will be second class citizens as time goes on. That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this. Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. Which should be considered now. VNC screen scraping sucks. If the native clients cannot be networked from the beginning, then they will never be able to be networked in a suitable fashon. Its not something you can bolt on later if [it] is really successful I like the concept of the project and I like the energy, but the bottom line is: if you want to make a replacement for X it needs to offer at least the same feature set. That includes network transparency. Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 6:33 PM, Jeff Spaleta jspal...@gmail.com wrote: wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech. I have been watching this growing thread with some bewilderment - is it possible for someone who knows by direct experience how Wayland has been moving, but who is also a Fedora developer, to give a more detailed description of where the project has been heading in terms of both what it *may* be able to provide in functionality beyond the discussion in this thread, as well as how it is envisaged it may yet satisfy the needs of the critics concerning the loss of essential functionality - I guess that if the project is still being defined then it is important to understand its potential for the future, and not just what has been planned at this point in time? Jeff makes a good point here - it sounds like this is still nascent at a level where *we* don't really know the extent of its capabilities, but has the potential to be developed in directions that have not yet been clarified in the developer's minds - and a considered discussion between the experts could say what its limitations might be? However there must be many unknowns and until the development gets to the stage where some code can be tested as part of a rawhide level system then it is perfectly possible that the developers could make the system work in a way that the critics are currently implying cannot happen - or am I being naive? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote: Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors. And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 13:43 -0500, Adam Jackson wrote: - All my X apps have to be ported! Yes, if they want to be native wayland clients, they do. Minor correction (I think?) - the apps don't really need to be ported, the toolkits do. Once GTK+ is ported to Wayland, fr'instance, all GTK+ apps are ported, right? It's not like we need to go in and poke all ten zillion apps we ship separately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote: On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote: Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors. Also, those two things are not at all incompatible (though ajax, please do correct me if I was wrong in what I wrote, or if I'm wrong in this). It's perfectly possible (and I think likely) both for Wayland to be implemented in such a way that you can use X remoting more or less transparently, *and* for there to be some kind of native remoting protocol for Wayland. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote: On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote: Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors. And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work. So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always kept in sync. The truth is, I think this could be an interesting project, and I think most people are raising their concerns now to make sure that should it become a successful project we're not stuck with either VNC or local-only. Brian - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-11-10)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (1:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 * F12 critical path/update testing issues. (does it matter this close to EOL?) * Need work on stats to see trends with new policy. * Need to investigate a 'new features' repo setup. * Need to look at education/enforcement = New business = #topic ELECTIONS * Need someone to help coordinate townhalls/etc. #topic #485 Revisit Bundled Libraries process https://fedorahosted.org/fesco/ticket/485 #topic #486 Plan Fedora 12 EOL https://fedorahosted.org/fesco/ticket/486 #topic #487 Approve Fedora 15 Schedule https://fedorahosted.org/fesco/ticket/487 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
Hi, On 11/09/2010 07:14 PM, Adam Williamson wrote: On Tue, 2010-11-09 at 11:49 -0600, Michael Cronenworth wrote: Adam Williamson wrote: Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 well hey, that saves me the trouble. :/ I completely understand the :/ I myself haver filed a bug about bugzilla setting a mime type which browsers don't recognize rather then text/plain, which would be correct: https://bugzilla.redhat.com/show_bug.cgi?id=555677 I cannot help but notice a trend here, that our bugzilla is not getting the love it needs :( Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-10)
On Tue, 2010-11-09 at 12:02 -0700, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (1:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 * F12 critical path/update testing issues. (does it matter this close to EOL?) Two things - it's generally a good idea to at least push a final set of fixes for outstanding major issues (esp. security) before going EOL. Also, there's a more generic case here: it's possible and probably likely that we'll have an ongoing issue trying to apply the policy to whatever release is stable-but-not-latest at any given time; as people move up to F14, the problem will likely move across to F13, we'll have fewer people running it, fewer proventesters running it, and we'll start seeing delays for F13 updates the way we did for F12 updates. So please discuss the generic case as well as F12 specifics. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 20:06 +0100, Hans de Goede wrote: Hi, On 11/09/2010 07:14 PM, Adam Williamson wrote: On Tue, 2010-11-09 at 11:49 -0600, Michael Cronenworth wrote: Adam Williamson wrote: Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 well hey, that saves me the trouble. :/ I completely understand the :/ I myself haver filed a bug about bugzilla setting a mime type which browsers don't recognize rather then text/plain, which would be correct: https://bugzilla.redhat.com/show_bug.cgi?id=555677 I cannot help but notice a trend here, that our bugzilla is not getting the love it needs :( in a sense our hands are somewhat tied; we have a policy of sticking close to upstream Bugzilla code to avoid getting (back) into the case where our Bugzilla is so diverged from upstream that we can no longer track upstream updates promptly. So our Bugzilla maintainers generally won't push changes that aren't either upstreamed or stand a good chance of being upstreamed soon, AIUI. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 06:43 PM, Adam Jackson wrote: On Tue, 2010-11-09 at 17:40 +, Andrew Haley wrote: I'm wondering of I'm reading this correctly. The downsides that have been described are quite severe in contrast to the possible benefits. It is, of course, possible that a mistake has been made, and the acute loss of functionality is just scaremongering. It's also possible that I've misunderstood something. The downsides that have been described include: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.) OK, so it's likely that everything will just continue to work remotely, and people won't experience any problems. And they won't have to run VNC just to get their favourite app to display remotely. If this had been explained clearly to begin with, we could have avoided all this pain. - All my X apps have to be ported! Yes, if they want to be native wayland clients, they do. If they don't, you can run a nested X server like on OSX. They'll still work as well as they ever did, and you even get to keep ssh forwarding of them. You can run a wayland server that does nothing but run a nested X server and you wouldn't ever know the difference. Except of course that your shell and your screensaver can be wayland apps, which means your screen locker will still work even if an app has a menu open, and you can actually do secure password input, and and and. (But, we really don't have _any_ good native wayland apps yet, thus the benefit of native apps are at the moment theoretical; so we're not switching yet.) Anything I'm missing? It looked like a bunch of kiddies who had never used remote X applications had decided we didn't need to do that anymore, and it was more important to get kewl features like smooth scrolling and rotating 3D whatnots. It seems that isn't true, and we don't need to worry. The lunatics have not, in fact, taken over the asylum. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 11/09/2010 06:12 PM, Gregory Maxwell wrote: I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends. Nice way to assume. Its pretty likely that you use software I wrote every day. So long as the _system_ provides robust and fully integrated network transparency I don't really care which sub-components are actually providing it. I think I already made that clear enough. I don't think anyone here really cares about the internal details so long as the functionality works well and is well integrated. What hasn't been made clear to me so far is that this is the case. I see you saying this, it's also argued that network transparency is not required in wayland because some toolkits will support falling back to X. Other people have argued that network transparency is no longer required because of the existence of web applications. If is so clear-cut for wayland then why can't a clear message be provided? Please don't blame me the lack of clarity in the communications on Wayland's intended capabilities and confusion that other people have created by arguing the network transparency isn't a requirement. Miscommunication happens. It doesn't even require anyone to be uniformed or incompetent. I'm perfectly capable of understanding a statement like Cairo^wWayland is just a rendering layer, the communications is provided by FooBar, and that will provide good network transparency or at least as good as X11, so there is no need to worry if network transparency is important to you. [snip] In any case, I can't see that there has been any real concern raised about _change_. Fedora is full of change. People are raising and arguing specific concerns about the nature of the changes. Please treat your list co-habitants with a little more respect. Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet. raising concerns != screaming the sky is falling Well _I_ certainly didn't intend to call for a rejection of wayland— it seems to be far too immature to even talk about rejecting it at this point. But I think Fedora ought to make clear that network transparency is requirement. It seems that at least a few people in this thread don't believe that it is, and I think that ought to be cleared up sooner rather than later because I'd hate to hear that a lot of effort was put in building a system that won't really meet the needs. If the need for network transparency is already well understood then I don't think there is much more to discuss. [snip] X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. This is exactly the sort of non-comforting communication that I was complaining about above. The fact that 'legacy' apps will continue to function in a network transparent manner for some time is nice thing... but it suggests a future which will be increasingly boxed in if it becomes a central component of common GNU/Linux distributions. You're giving a really confused message here. In some parts of the thread it's being argued that the complaints are unfounded because the system will provide network transparency, but it's also argued that transparency isn't required because old applications will continue to work the old way, or because people don't actually need the functionality. That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this. Keep your windowing system out of my network transparency ;) Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. I think it's needed on the first day that wayland desktop applications are widely deployed— someone shouldn't have to choose between the wayland ui and network transparency. I suppose there is plenty of room to disagree
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 10:54 -0800, Adam Williamson wrote: On Tue, 2010-11-09 at 13:43 -0500, Adam Jackson wrote: - All my X apps have to be ported! Yes, if they want to be native wayland clients, they do. Minor correction (I think?) - the apps don't really need to be ported, the toolkits do. Once GTK+ is ported to Wayland, fr'instance, all GTK+ apps are ported, right? It's not like we need to go in and poke all ten zillion apps we ship separately. To the extent that those apps call (and link) only against the toolkit and not against an assumed backend, sure. The strict linking changes in F12 or F13 or whichever it was helped a lot with this, and gtk3 will help more, but to pick an arbitrary example: % ldd `which gcalctool` | grep libX libX11.so.6 = /usr/lib/libX11.so.6 (0x05f1a000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x001c1000) libXext.so.6 = /usr/lib/libXext.so.6 (0x00d42000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0x001c6000) libXinerama.so.1 = /usr/lib/libXinerama.so.1 (0x001cf000) libXi.so.6 = /usr/lib/libXi.so.6 (0x0094e000) libXrandr.so.2 = /usr/lib/libXrandr.so.2 (0x0095d000) libXcursor.so.1 = /usr/lib/libXcursor.so.1 (0x009c8000) libXcomposite.so.1 = /usr/lib/libXcomposite.so.1 (0x001d2000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x001d5000) libXau.so.6 = /usr/lib/libXau.so.6 (0x006f8000) - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY). Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:19 -0500, Adam Jackson wrote: On Tue, 2010-11-09 at 14:01 -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote: And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work. So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always kept in sync. Sorry, I assumed a bit much domain knowledge here. No worries When I say vnc-like I mean let's scrape the pixels out of the rendering buffer and shove them over the wire. VNC itself is rooted, but vnc-like remoting can be rooted or rootless. In wayland the fundamental object of composition is a whole window, so you have scrapeable surfaces both at the window level and at the top level. Take your pick. I was hoping that window-level scraping was possible but I wasn't sure how to phrase it. When I say rdp-like I mean instill enough awareness of the possibility of remoting in the rendering system that remoting can send a rendering command stream instead of raw pixels if that seems to be a win. Wordy, I admit. And, obviously, much more work than just vnc-like scraping. But it's a serious win for WAN links, and is the only viable way to remote 3D, etc. Wordy, true, but I think its the kind of detail necessary to calm a lot of the fears that people have. And, of course, you can have both at once. rdp-like remoting probably requires toolkit awareness (in this bizarro world, the nested X server counts as a toolkit!), so if you end up remoting an app that lacks that level of toolkit support, you can fall back to vnc-like. Sounds reasonable enough Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:12 -0500, Adam Jackson wrote: To the extent that those apps call (and link) only against the toolkit and not against an assumed backend, sure. The strict linking changes in F12 or F13 or whichever it was helped a lot with this, and gtk3 will help more, but to pick an arbitrary example: % ldd `which gcalctool` | grep libX libX11.so.6 = /usr/lib/libX11.so.6 (0x05f1a000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x001c1000) libXext.so.6 = /usr/lib/libXext.so.6 (0x00d42000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0x001c6000) libXinerama.so.1 = /usr/lib/libXinerama.so.1 (0x001cf000) libXi.so.6 = /usr/lib/libXi.so.6 (0x0094e000) libXrandr.so.2 = /usr/lib/libXrandr.so.2 (0x0095d000) libXcursor.so.1 = /usr/lib/libXcursor.so.1 (0x009c8000) libXcomposite.so.1 = /usr/lib/libXcomposite.so.1 (0x001d2000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x001d5000) libXau.so.6 = /usr/lib/libXau.so.6 (0x006f8000) GTK+ backends are linked in at this time. One of the things that we will need to address before switching to wayland-with-X-fallback-for-remote-or-poor-hw becomes a realistic possibility. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY). When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor. Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both. I assume there would be a fallback method for older ssh clients? In any case, combined with the stuff that ajax has said in the last couple of emails it sounds like it could be a workable solution. Brian --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 7:09 PM, Andrew Haley a...@redhat.com wrote: OK, so it's likely that everything will just continue to work remotely, and people won't experience any problems. And they won't have to run VNC just to get their favourite app to display remotely. If this had been explained clearly to begin with, we could have avoided all this pain. All participants need to take responsibility for being situationally aware to keep things from spiralling out of control. The person starting this conversation is not involved in the work. Because of that there is no initial clarity or statement of purpose..no expert opinion to rely on at the outset. The people involved in the work are bravely walking into a discussion they didn't expect to be having at this point in time to pour water on reactions that have already grown somewhat overheated by the lack of clarity which was created through no fault of their own. It looked like a bunch of kiddies who had never used remote X applications had decided we didn't need to do that anymore, and it was more important to get kewl features like smooth scrolling and rotating 3D whatnots. It seems that isn't true, and we don't need to worry. The lunatics have not, in fact, taken over the asylum. If you thought that, if anyone thought that, they are bringing a huge amount of mental baggage into the discussion with them and are setting everyone up for a passionate overheated argument instead of a dispassionate informative discussion. A quick look over at freedesktop's git at the people who have had personal wayland branches in recent history would eradicate this particular characterization. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On 2010/11/09 08:45 (GMT-0800) Adam Williamson composed: There isn't a prize system for bug reports. Actually there is. When someone files a good bug, as opposed to one that requires more than trivial attention due to significant missing or invalid information, achieving fixed status is an informal statement that the filer's effort was valuable. It getting duped to a newer bug that isn't materially different in quality is an informal statement that the filer's effort was not appreciated, thus the subject. So, once more for the cheap seats: *why* do you think closing an older bug as a dupe of a newer one is a respect issue? What's the big problem with it? When I get a list of all bugs I filed, there's nothing AFAICT that can tell me whether a dupe to a newer is really a fixed - there's no way to get into a buglist the status of a bug duped to. Thus the report misleads about the quality of effort put forth, a significant part of which is ensuring against filing a duplicate by competent searching prior to filing. When anyone is attempting to assess the overall efficiency of Bugzilla, one aspect is the open time. Duping to newer misleads about this too. It shouldn't happen unless the newer is clearly better. 50+ CCs, some of which are from dupes of newer bugs, and little metoo or other noise, should be a pretty good condition that a bug is good enough that justification for duping to a newer should be overwhelming to be allowed. Plus https://bugzilla.mozilla.org/show_bug.cgi?id=108983 https://bugzilla.redhat.com/show_bug.cgi?id=523634 -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Once upon a time, Adam Jackson a...@redhat.com said: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a VNC-like remoting is a significant loss for server environments compared to X-like remoting. With an X-based GUI management tool on a server, you fire up an SSH (or if you are old style you can even xhost +foo, or manually copy magic cookies) and run just the app on the server, exporting the display of the app to your local system. All the heavy-lifting runs on your local system, not the server. When you close the app, there's nothing left running on the server. If you have to use a VNC-like remoting, you have to run a desktop environment on the server (at least some minimal thing). You either have to have it running all the time, or start it up on demand. Then you can log in to start your app. When you shut down the app, you have to remember to shut down the desktop environment as well. This is much more overhead on the server for an occasional use GUI app. None of my servers even have any desktop-environment type stuff install. In virtualized environments, making the servers run desktop stuff could greatly increase the overhead. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 561389] amavisd-new always reports Shutting down amavisd: Daemon [19248] terminated by SIGTERM
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=561389 --- Comment #12 from Sandro Janke bugzilla_red...@penguinpee.nl 2010-11-09 14:34:42 EST --- (In reply to comment #9) (In reply to comment #8) (In reply to comment #7) Wouldn't be better to send this patch to upstream? They are preparing new release and your patch can be included there. Well, I'll suppose that's up to the package maintainer. But, I'll be happy to report upstream if someone can tell me where to go. I looked at the projects website [1], but can't find a bug tracker or the like. [1] http://www.ijs.si/software/amavisd/ I also didn't find any email. At least I add your patch in F-13,14,rawhide. I hope Steve won't mind. Thanks a lot. I'm sure many system administrators won't mind getting less pointless mails. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 13:34 -0600, Chris Adams wrote: Once upon a time, Adam Jackson a...@redhat.com said: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a VNC-like remoting is a significant loss for server environments compared to X-like remoting. See that other email where I say that VNC-like means pixel scraping and not full-desktop. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 14:33 -0500, Felix Miata wrote: On 2010/11/09 08:45 (GMT-0800) Adam Williamson composed: There isn't a prize system for bug reports. Actually there is. When someone files a good bug, as opposed to one that requires more than trivial attention due to significant missing or invalid information, achieving fixed status is an informal statement that the filer's effort was valuable. It getting duped to a newer bug that isn't materially different in quality is an informal statement that the filer's effort was not appreciated, thus the subject. You may interpret it this way, but with my maintainer hat on, I can tell you it's simply not how most maintainers look at things. Maintainers want to fix bugs in the most efficient way possible. They're not thinking in terms of passing judgments and handing out prizes to the bug reporters; there is no judgment on the initial reporter implicit in their duping decisions. Just as Lubomir noted when he did this particular dupe: he didn't say anything about the quality of the *initial reports*. He preferred the newer bug because it had fewer messy side discussions and useless +1 comments. In this particular case we can confidently say that, based on direct evidence, your interpretation of the duplication decision as an implicit judgment on the quality of the initial bug report is incorrect. In the general case, I think we can still confidently say, given the priorities and workflow of most maintainers, that your interpretation of duplication decisions in general as being conscious implicit judgements on the qualities of the initial reports is also usually incorrect. So, once more for the cheap seats: *why* do you think closing an older bug as a dupe of a newer one is a respect issue? What's the big problem with it? When I get a list of all bugs I filed, there's nothing AFAICT that can tell me whether a dupe to a newer is really a fixed - there's no way to get into a buglist the status of a bug duped to. Thus the report misleads about the quality of effort put forth, a significant part of which is ensuring against filing a duplicate by competent searching prior to filing. Sure. But this is only special to you from *your* perspective. From the disinterested bystander's perspective, this suckage is going to happen to all the reporters but one; whichever one happens to be the lucky one whose bug stays open isn't really important from the overall perspective, the ratio of people for whom the end result isn't perfect to people for whom it is does not change. Bugzilla is a long way from perfect, practically speaking it's best to recognize that it has limitations that you're going to have to deal with, and these do not reflect anyone being personally out to get you. When anyone is attempting to assess the overall efficiency of Bugzilla, one aspect is the open time. Duping to newer misleads about this too. Okay, that's an actual reasonable concrete objective point, and you're right. In practice, we run very few metrics on Bugzilla, so I don't think this is a huge issue in Fedora's case, but yes, that's one factor which should work in favor of duplicating to the oldest report when all other factors are equal. I wouldn't assign it as much weight as you do, but it's certainly a factor. It shouldn't happen unless the newer is clearly better. 50+ CCs, some of which are from dupes of newer bugs, and little metoo or other noise, should be a pretty good condition that a bug is good enough that justification for duping to a newer should be overwhelming to be allowed. Again, from the developer's perspective, metoos are usually a negative, not a positive. They just make it harder to find the *useful* input. A comment which provides information that helps to debug the problem is useful. A comment with an attached patch is really useful. A comment which says I'm having the same problem as the last 500 people to comment on this bug is usually not at all useful and just makes it harder to find the good comments. (It can be useful if a bug's been open for three years and you're not really sure whether it's still valid, but when 15 people have told you in the last two days that they're having the problem, a 16th person saying that they're also having it really isn't contributing anything helpful). Plus https://bugzilla.mozilla.org/show_bug.cgi?id=108983 https://bugzilla.redhat.com/show_bug.cgi?id=523634 again, yeah, Bugzilla sucks. But then, if you want to look at it logically, the sensible response to this bug is 'make the 'original' the bug with the largest number of subscribers', not 'make the 'original' the oldest bug'. The two are not always the same. And Lubomir likely wasn't even aware of the above bug when he did the duplicating. It seems most people aren't. So again, you have no reason to ascribe personal motivations. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT
Re: Why should I ever bother filing another bug?
On Tue, Nov 9, 2010 at 7:33 PM, Felix Miata mrma...@earthlink.net wrote: Actually there is. When someone files a good bug, as opposed to one that requires more than trivial attention due to significant missing or invalid information, achieving fixed status is an informal statement that the filer's effort was valuable. It getting duped to a newer bug that isn't materially different in quality is an informal statement that the filer's effort was not appreciated, thus the subject. I humbly disagree with this point of view and I'm pretty sure we have never documented this interpretation or expectation in anything set forth in the project level guidance around bug ticket activity. I don't know of a way to convince to change your person opinion on this, but its critical you realize that its most likely not a widely held one and thus you will continually find yourself in conflict with other people's workflows. So, once more for the cheap seats: *why* do you think closing an older bug as a dupe of a newer one is a respect issue? What's the big problem with it? When I get a list of all bugs I filed, there's nothing AFAICT that can tell me whether a dupe to a newer is really a fixed - there's no way to get into a buglist the status of a bug duped to. Thus the report misleads about the quality of effort put forth, a significant part of which is ensuring against filing a duplicate by competent searching prior to filing. This buglist reporting workflow deficiency is an argument against setting dupes at all for any bug ever and is not specific to the issue of how to competently choose how to set a duplicate tag among multiple bugs. Are you really trying to do a comprehensive assessment of _quality_ of bugzilla activity? I'd like to see a fully written up methodology around that. We may get a better idea of what your ultimately trying to achieve if you see your concerns about quality of effort inside the context of the larger assessment goals you are interested in. When anyone is attempting to assess the overall efficiency of Bugzilla, one aspect is the open time. Duping to newer misleads about this too. Is anyone actually attempting to do that at this point in time? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 651571] When attrcrypt is on, entrydn is stored in the backend db
https://bugzilla.redhat.com/show_bug.cgi?id=651571 https://bugzilla.redhat.com/attachment.cgi?id=459236action=diff https://bugzilla.redhat.com/attachment.cgi?id=459236action=edit Description: If an entry contains a to-be-encrypted attribute, id2entry_add_ext handles a copy of the entry in which the attribute is encrypted, then the copy is being stored in the backend db. On the other hand, an entrydn attribute is supposed to remove from the entry before storing the entry in the db. There was a bug there: the removal was done on the original entry, but not on the encrypted copy. This patch correctly removes the entrydn attribute from the encrypted entry to be stored in the db. Thanks, --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 02:28:10PM -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY). When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor. Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both. I assume there would be a fallback method for older ssh clients? It would involve a bit more effort on the user's part (most of which could be rolled into a script) but you could set up the final scenario using present-day ssh assuming you had the wayland bits on both ends. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 08:53:36AM -0800, Adam Williamson wrote: well, I imagine you know more about this than me, but I run with Japanese input support at least occasionally, and my impression is that a lot of it is a fragile tower necessitated by the fact that the deep underlying stuff was coded with the assumption that all anyone ever wanted to type was ASCII. It feels to me like CJK input breaks a lot more than it really *should*, if you step back and look at it from first principles - it's just an input method, and we'd feel pretty dumb if we shipped a release where you can't type the letter Q, yet this sort of thing seems to happen all the time with non-en_US input. From a QA perspective, I know keyboard layout selection and complex character input is one of the things that breaks so often we had to stick an explicit validation test in for it. I don't know how much of this is related to X specifically, but I know it's certainly one of the things involved which makes the whole process of providing switchable input methods so icky. I've yet to reliably compose a Japanese email through my non-Red Hat email address, but that's going over gnome-terminal - ssh - Debian - mutt, and to be honest absolutely anything could be the problem there. I wouldn't blame X for that one ... It generally works for gtk2 apps. The actual implementation of the input mode switching is pretty horrible, but I sort of assume that's the usual open-source- developers-can't-do UI issue. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 01:43:06PM -0500, Adam Jackson wrote: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.) Just so we don't lose the point: VNC-style remoting is *not* a suitable alternative. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures). -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 07:33 PM, Jeff Spaleta wrote: On Tue, Nov 9, 2010 at 6:12 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet. raising concerns != screaming the sky is falling Actually, if we go back to the first post in the thread... it was the premature suggestion by a by stander of bringing a still far from being finished technology into Fedora because another entity has prematurely decided to announce to the world that its going to be their default. That triggered a certain amount of bloodletting. If the original poster had come to the conclusion that it was far from being finished before writing the first post do you think that the original poster would have written that post in exactly the say way? Something the original poster should probably ruminate on. Generally speaking, if you aren't prepared to talk in detail about the suitability of a technology, you shouldn't bring it up for discussion like that. If you are personally interested in it, you should inquire as to whether there are people in our development community who are currently working on it and ask them questions about it. To come out of the gate suggesting its time to discuss it for inclusion is putting the card before the horse. What the original post is, is a classic enthusiast blunder. The active developers working on the problem space are more than capable of proposing wayland for inclusion and answer questions about wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech. No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine. As for the the developers will come forward when it's done you apparently seem to know know about the behind the scenes connections between Wayland and Fedora than others. I was aware of the initial anouncement of Wayland when the project was started at long time ago and wouldn't have dreamed of bringing it up precisely because it would have been premature. However now Ubuntu is apparently going to introduce its influence so I thought it to be fair to make Fedora aware of the project. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 09:03:38PM +, Richard W.M. Jones wrote: On Tue, Nov 09, 2010 at 01:43:06PM -0500, Adam Jackson wrote: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.) Just so we don't lose the point: VNC-style remoting is *not* a suitable alternative. Ajax is using VNC-style remoting to refer to a pixel-scraping remoting mechanism which would not necessarily include a root window and would in most cases function the same way as X forwarding. Seems to be a repeated confusion in this branch of the thread. --CJD Rich. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 17:55 +, Jeff Spaleta wrote: On Tue, Nov 9, 2010 at 4:55 PM, Adam Jackson a...@redhat.com wrote: Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. I think what's missing is a concrete demonstration to point to of remoting of a Wayland native client window to wrap our heads around how different (easy or hard) it is. When the time comes to introduce initial wayland packages into Fedora having the ability to demonstrate a native toy Wayland client rendered remotely (and securely from say a virtualized host) is probably something to shoot for. The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591 - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote: I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures). You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 04:17:25PM -0500, Adam Jackson wrote: The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591 Hopefully with a better security model than 'ssh -Y'? If this has Xpra-like functionality (i.e. screen for X) standard, and it works and is managed well, suddenly there's a pretty compelling advantage. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock question
Hi Seth, Den 09-11-2010 15:05, seth vidal skrev: Unfortunately yum-builddep doesn't work for me. I need to be able to change $releasever and enabled repositories (hence the mock config file). Is that possible with yum-builddep? yum-builddep --releasever --disablerepo='*' --enablerepo=myrepo1 --enablerepo=myrepo2 pkg Unfortunately if a SRPM has multiple buildrequires, then yum-builddep only prints out the first missing requires and then quits. :( Is it hard to do using the python api? Best regards, Rasmus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On 11/09/2010 07:50 PM, Adam Williamson wrote: In practice, we run very few metrics on Bugzilla This is the problem we should be gather all kinds of bug metrics and general component activity from bugzilla. This is very vital information for QA group to harvest and have. ( without it we cant find the areas were both parties can do better. ) And since there is general will amongst reporters that this information is collected this I maintainers if they are opposed that this information will be harvested? If so why? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 9, 2010 at 9:09 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine. Am I holding you responsible for others? No. I'm saying very specifically that you started a topic about inclusion instead of simply inquiring as to whether people in our community are already involved. The inquiry would have been perfectly appropriate. A suggestion we talk about inclusion when we don't have a clearly defined technical expert to make the case for it is not. We have a featuring process for some very good reasons. One of those reasons is to allow the person make the propose to provide adequate amount of information as a starting point for a constructive discussion about technical pros and cons. That's like me suggesting we have a discussion about moving over to the hurd kernel as a default when I know absolutely nothing about kernel implementation details and watching concerns over the issue spiral out of control. I am saying very specifically that noone should propose a discussion for technology inclusion on this list unless they feel comfortable addressing questions of a technical nature about the technology or failing that they bring someone along at the start of the conversation who is able to be the technical expert when the quite expected questions about technical issues come up. The discussion spirals when questions go unanswered by a technical expert and the void in the discussion is instead filled up with meatheads like myself. As for the the developers will come forward when it's done you apparently seem to know know about the behind the scenes connections between Wayland and Fedora than others. I was aware of the initial anouncement of Wayland when the project was started at long time ago and wouldn't have dreamed of bringing it up precisely because it would have been premature. However now Ubuntu is apparently going to introduce its influence so I thought it to be fair to make Fedora aware of the project. You yourself have stated as part of this discussion that its still as a long way to go as a technology. Appearently you came to that conclusion later in the discussion. It appears that Shuttleworth's sincere enthusiasm for what is achievable with Wayland has mislead you into thinking the project is futher along than it is. Just to save yourself some heartbreak down the road, assuming a technology that Shuttleworth is personally excited about is not what I would call due diligence in gaining enough of an understanding of the subject matter to competently lead a discussion on the topic. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock question
On Tue, 2010-11-09 at 22:29 +0100, Rasmus Ory Nielsen wrote: Hi Seth, Den 09-11-2010 15:05, seth vidal skrev: Unfortunately yum-builddep doesn't work for me. I need to be able to change $releasever and enabled repositories (hence the mock config file). Is that possible with yum-builddep? yum-builddep --releasever --disablerepo='*' --enablerepo=myrepo1 --enablerepo=myrepo2 pkg Unfortunately if a SRPM has multiple buildrequires, then yum-builddep only prints out the first missing requires and then quits. :( Is it hard to do using the python api? I doubt it - it's probably just a bug. file it, please -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
At least it's winter now and a hot netbook is less of a problem than in the summer. On 9 Nov 2010 21:22, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote: I'm using the experimental 3d now with gno... You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listin... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 16:26 -0500, Matthew Miller wrote: On Tue, Nov 09, 2010 at 04:17:25PM -0500, Adam Jackson wrote: The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591 Hopefully with a better security model than 'ssh -Y'? What kind of attack are you trying to prevent, and how do you envision that interacting with the window system? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On Tue, 2010-11-09 at 21:31 +, Jóhann B. Guðmundsson wrote: On 11/09/2010 07:50 PM, Adam Williamson wrote: In practice, we run very few metrics on Bugzilla This is the problem we should be gather all kinds of bug metrics and general component activity from bugzilla. This is very vital information for QA group to harvest and have. ( without it we cant find the areas were both parties can do better. ) And since there is general will amongst reporters that this information is collected this I maintainers if they are opposed that this information will be harvested? If so why? no-one's opposed to it. Just no-one's actually stepping up to do it. We've had three attempts so far within bugzappers to get metrics going, and it never works out, because no-one follows through. Demanding that it happen is not going to magically make it happen; someone has to do the work. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 04:35:33PM -0500, Adam Jackson wrote: The UX will probably be somewhere between ssh -Y, vncserver(1), and: https://bugzilla.redhat.com/show_bug.cgi?id=651591 Hopefully with a better security model than 'ssh -Y'? What kind of attack are you trying to prevent, and how do you envision that interacting with the window system? The classic is a hostile remote binary which secretly maps a full-screen transparent window and captures everything you do in your other windows. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On 11/09/2010 09:40 PM, Adam Williamson wrote: On Tue, 2010-11-09 at 21:31 +, Jóhann B. Guðmundsson wrote: On 11/09/2010 07:50 PM, Adam Williamson wrote: In practice, we run very few metrics on Bugzilla This is the problem we should be gather all kinds of bug metrics and general component activity from bugzilla. This is very vital information for QA group to harvest and have. ( without it we cant find the areas were both parties can do better. ) And since there is general will amongst reporters that this information is collected this I maintainers if they are opposed that this information will be harvested? If so why? no-one's opposed to it. Just no-one's actually stepping up to do it. We've had three attempts so far within bugzappers to get metrics going, and it never works out, because no-one follows through. Demanding that it happen is not going to magically make it happen; someone has to do the work. Do you have any links to the bugzappers discussions about this and the code that was used in these attempts? Do we have access to bugzilla clone to test against? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 09.11.10 04:05, Jon Masters (jonat...@jonmasters.org) wrote: From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. I think you aren't even aware how broken this mix and match network approach of classic X11 is. The semantics of D-Bus and other IPCs in a distributed X11 session has never been clearly defined, and all kinds of integration between apps mostly just vanishes if you do this, or will behave weirdly. Yes, X11 over the network still kinda works, but if you claim the status quo was so awesome, then you're just blind. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 08:04 PM, Gregory Maxwell wrote: On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 11/09/2010 06:12 PM, Gregory Maxwell wrote: I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends. Nice way to assume. Its pretty likely that you use software I wrote every day. So long as the _system_ provides robust and fully integrated network transparency I don't really care which sub-components are actually providing it. I think I already made that clear enough. I don't think anyone here really cares about the internal details so long as the functionality works well and is well integrated. What hasn't been made clear to me so far is that this is the case. I see you saying this, it's also argued that network transparency is not required in wayland because some toolkits will support falling back to X. Other people have argued that network transparency is no longer required because of the existence of web applications. If is so clear-cut for wayland then why can't a clear message be provided? Please don't blame me the lack of clarity in the communications on Wayland's intended capabilities and confusion that other people have created by arguing the network transparency isn't a requirement. Miscommunication happens. It doesn't even require anyone to be uniformed or incompetent. I'm perfectly capable of understanding a statement like Cairo^wWayland is just a rendering layer, the communications is provided by FooBar, and that will provide good network transparency or at least as good as X11, so there is no need to worry if network transparency is important to you. From what you wrote it sounded like you were specifically insisting that the network transparency bits were supposed to go into Wayland proper and that would make some sense if said but someone who has never developed software and doesn't understand the layering of subsystems. It was an honest mistake and not an attempt to get cute. My apologies. What I was trying to get at is that even if the Wayland developers completely ignore network transparency that has no bearing on an independent implementation of that feature (see Casey Dahlins example elsewhere in this thread). [snip] X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. This is exactly the sort of non-comforting communication that I was complaining about above. The fact that 'legacy' apps will continue to function in a network transparent manner for some time is nice thing... but it suggests a future which will be increasingly boxed in if it becomes a central component of common GNU/Linux distributions. You're giving a really confused message here. In some parts of the thread it's being argued that the complaints are unfounded because the system will provide network transparency, but it's also argued that transparency isn't required because old applications will continue to work the old way, or because people don't actually need the functionality. The reason for the confusion is that two cases are conflated here: Wayland + X and Wayland without X. As long as X is present as a client on top of Wayland all apps will just continue to work as usual. That is the initial state of affairs and native network transparency for Wayland is not going to be that important. Once Wayland is established and successfull people will eventually want to get rid of X altogether. At this we'll need an X-less way of doing network transparency. This point lies 2-3 Years in the future though so it's not necessary to get worked up about the details just yet. That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this. Keep your windowing system out of my network transparency ;) Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. I think it's
Re: Ubuntu moving towards Wayland
Lennart Poettering píše v Út 09. 11. 2010 v 23:07 +0100: I think you aren't even aware how broken this mix and match network approach of classic X11 is. The semantics of D-Bus and other IPCs in a distributed X11 session has never been clearly defined, and all kinds of integration between apps mostly just vanishes if you do this, or will behave weirdly. Well, isn't that mostly the fault of D-Bus, GConf and other relatively recent inventions that they decided to ignore this use case of running desktop applications? In the far past, IPC mechanisms somehow managed to cooperate with X (e.g. ICCCM, XSettings) - admittedly with lower-level functionality. (The decision to ignore remote applications may have been correct - that's beside the point: You really can't blame X for things D-Bus/GConf didn't do; and the fundamental semantic problem of should this setting refer to the machine this process runs or to the machine it is displayed does not ever go away simply by changing the remote communication protocol.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 09.11.10 23:14, Miloslav Trmač (m...@volny.cz) wrote: Lennart Poettering píše v Út 09. 11. 2010 v 23:07 +0100: I think you aren't even aware how broken this mix and match network approach of classic X11 is. The semantics of D-Bus and other IPCs in a distributed X11 session has never been clearly defined, and all kinds of integration between apps mostly just vanishes if you do this, or will behave weirdly. Well, isn't that mostly the fault of D-Bus, GConf and other relatively recent inventions that they decided to ignore this use case of running desktop applications? In the far past, IPC mechanisms somehow managed to cooperate with X (e.g. ICCCM, XSettings) - admittedly with lower-level functionality. (The decision to ignore remote applications may have been correct - that's beside the point: You really can't blame X for things D-Bus/GConf didn't do; and the fundamental semantic problem of should this setting refer to the machine this process runs or to the machine it is displayed does not ever go away simply by changing the remote communication protocol.) Oh, of course you can blame X for that. There's simply no sane way how to get a parallel connection for D-Bus/GConf/ICE/PA/whatever to the main X11 display connection. Something like that has been tried a number of times, but in some way or the other it just failed in the end. It's a can of worms. Really, for example in the GConf case I know that Havoc spent quite some time to design the IPC so that it could be used alongside X11 on the network, but eventually gave up on it. I think it is fundamentally wrong to ask us to support setups where you might or might not share $HOME, might or might not share the D-Bus session bus, might or might not share the D-Bus system bus, might or might not share PA, might or might not share GConf, might or might not share X11 displays, in all combinations over the network at all times. Complete flexibility like that is not only impossible to manage or test, but also inherently slow. For example: if you say the D-Bus bus should be shared across the network, but $HOME shouldn't, then applications could not refer to files anymore in the bus protocols, which would basically require them to pipe everything through a bus, which is a textbook example how to make things slow. Of course, it's easy to assume that all the building blocks we build our desktop off would be completely independent black boxes, but turns they aren't, and are deeply integrated these days. The pixel-scraping approach is the only thing that in the end makes sense, since you have a very clear idea of what you share, and what you don't share, and what you share is only at the very very end of what you do, i.e. the last step of presentation of the app to the user. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
That's true, using freenx to access a whole desktop works well with xfce and no sound. I can't imagine it working so well if trying to run gnome-shell, sound etc remotely. I get the impression a lot of the current desktop infrastructure doesn't make sense when accessed remotely, eg if I ssh'ed into a machine what could I usefully do with nm-applet or a lot of other desktop infrastructure? A lot of the desktop is already beyond the reach of X. On 9 Nov 2010 22:26, Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 09.11.10 23:14, Miloslav Trmač (m...@volny.cz) wrote: Lennart Poettering píše v Út 09. 11... Oh, of course you can blame X for that. There's simply no sane way how to get a parallel connection for D-Bus/GConf/ICE/PA/whatever to the main X11 display connection. Something like that has been tried a number of times, but in some way or the other it just failed in the end. It's a can of worms. Really, for example in the GConf case I know that Havoc spent quite some time to design the IPC so that it could be used alongside X11 on the network, but eventually gave up on it. I think it is fundamentally wrong to ask us to support setups where you might or might not share $HOME, might or might not share the D-Bus session bus, might or might not share the D-Bus system bus, might or might not share PA, might or might not share GConf, might or might not share X11 displays, in all combinations over the network at all times. Complete flexibility like that is not only impossible to manage or test, but also inherently slow. For example: if you say the D-Bus bus should be shared across the network, but $HOME shouldn't, then applications could not refer to files anymore in the bus protocols, which would basically require them to pipe everything through a bus, which is a textbook example how to make things slow. Of course, it's easy to assume that all the building blocks we build our desktop off would be completely independent black boxes, but turns they aren't, and are deeply integrated these days. The pixel-scraping approach is the only thing that in the end makes sense, since you have a very clear idea of what you share, and what you don't share, and what you share is only at the very very end of what you do, i.e. the last step of presentation of the app to the user. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/de... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Le mardi 09 novembre 2010 à 14:19 -0500, Adam Jackson a écrit : When I say vnc-like I mean let's scrape the pixels out of the rendering buffer and shove them over the wire. VNC itself is rooted, but vnc-like remoting can be rooted or rootless. In wayland the fundamental object of composition is a whole window, so you have scrapeable surfaces both at the window level and at the top level. Take your pick. I hope no one is assuming there the pixels remote-side have the same properties as the pixels local-side (size, form factor, alignment, color-correction, etc) and we'll not get yet another display tech that only works as long as there is a single screen model everyone uses. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 10:33 PM, Jeff Spaleta wrote: On Tue, Nov 9, 2010 at 9:09 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine. Am I holding you responsible for others? No. I'm saying very specifically that you started a topic about inclusion instead of simply inquiring as to whether people in our community are already involved. The inquiry would have been perfectly appropriate. A suggestion we talk about inclusion when we don't have a clearly defined technical expert to make the case for it is not. We have a featuring process for some very good reasons. One of those reasons is to allow the person make the propose to provide adequate amount of information as a starting point for a constructive discussion about technical pros and cons. That's like me suggesting we have a discussion about moving over to the hurd kernel as a default when I know absolutely nothing about kernel implementation details and watching concerns over the issue spiral out of control. I am saying very specifically that noone should propose a discussion for technology inclusion on this list unless they feel comfortable addressing questions of a technical nature about the technology or failing that they bring someone along at the start of the conversation who is able to be the technical expert when the quite expected questions about technical issues come up. The discussion spirals when questions go unanswered by a technical expert and the void in the discussion is instead filled up with meatheads like myself. Point taken. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
