[AppDB] -more spam-
Hi list, again a spammer used the AppDB for his nasty activities: 1.) Comment for 'Adobe Photoshop CS3 (10.0)' added by tokoku12345 --- To reply to this email please use the link provided below. DO NOT reply via your email client as it will not reach the person who wrote the comment http://appdb.winehq.org/objectManager.php?sClass=versioniId=6584#Comment-84693 2.) Comment for 'ElsterFormular 12.0 (2010 + 2011)' added by tokoku12345 --- To reply to this email please use the link provided below. DO NOT reply via your email client as it will not reach the person who wrote the comment http://appdb.winehq.org/objectManager.php?sClass=versioniId=22570#Comment-84724 No. #2 is maintained by me, so I deleted the comment just some minutes ago. Is it possible, to mail to all maintainers to inform them about the actual mail food and to have an eye on their applications? If so please do it. -- Kindly regards Joerg Schiermeier Bielefeld/Germany
Re: We're in GSoC 2013
Hello, can the project Implementing a vertex pipeline be added for the possible GSOC projects? It would fix plenty of broken games (see bug 6955). Henri Verbeet said it could be a project, depending of skills of the student. David De : Austin English austinengl...@gmail.com À : Wine Devel wine-devel@winehq.org Envoyé le : Mardi 9 avril 2013 7h30 Objet : We're in GSoC 2013 If you're interested in mentoring, please apply at: https://www.google-melange.com/gsoc/org/google/gsoc2013/wine In either case, please take a look at http://wiki.winehq.org/SummerOfCode and update/remove/any projects you're familiar with. If you have any questions, feel free to contact me. Thanks for your help everyone! -- -Austin
Re: [PATCH v5 4/7] CIFS: Use NT_CREATE_ANDX command for forcemand mounts
On Tue, 9 Apr 2013 16:40:24 +0400
Pavel Shilovsky pias...@etersoft.ru wrote:
forcemand mount option now lets us use Windows mandatory style of
byte-range locks even if server supports posix ones - switches on
Windows locking mechanism. Share flags is another locking mehanism
provided by Windows semantic that can be used by NT_CREATE_ANDX
command. This patch combines all Windows locking mechanism in one
mount option by using NT_CREATE_ANDX to open files if forcemand is on.
Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
fs/cifs/dir.c | 1 +
fs/cifs/file.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index d4331de..8587021 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -217,6 +217,7 @@ cifs_do_create(struct inode *inode, struct dentry
*direntry, unsigned int xid,
}
if (tcon-unix_ext cap_unix(tcon-ses) !tcon-broken_posix_open
+ ((cifs_sb-mnt_cifs_flags CIFS_MOUNT_NOPOSIXBRL) == 0)
(CIFS_UNIX_POSIX_PATH_OPS_CAP
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
rc = cifs_posix_open(full_path, newinode, inode-i_sb, mode,
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 9394b2b..19038a4 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -455,8 +455,9 @@ int cifs_open(struct inode *inode, struct file *file)
else
oplock = 0;
- if (!tcon-broken_posix_open tcon-unix_ext
- cap_unix(tcon-ses) (CIFS_UNIX_POSIX_PATH_OPS_CAP
+ if (!tcon-broken_posix_open tcon-unix_ext cap_unix(tcon-ses)
+ ((cifs_sb-mnt_cifs_flags CIFS_MOUNT_NOPOSIXBRL) == 0)
+ (CIFS_UNIX_POSIX_PATH_OPS_CAP
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
/* can not refresh inode info since size could be stale */
rc = cifs_posix_open(full_path, inode, inode-i_sb,
@@ -624,6 +625,7 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool
can_flush)
oplock = 0;
if (tcon-unix_ext cap_unix(tcon-ses)
+ ((cifs_sb-mnt_cifs_flags CIFS_MOUNT_NOPOSIXBRL) == 0)
(CIFS_UNIX_POSIX_PATH_OPS_CAP
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
/*
I'm trying to understand why forcemand would matter here. Wouldn't
you just want to switch to using NT_CREATE_ANDX if O_DENY* is set
instead? What happens if I didn't mount with forcemand and then try to
use O_DENY*?
--
Jeff Layton jlay...@samba.org
Re: [PATCH v5 1/7] fcntl: Introduce new O_DENY* open flags
On Tue, 9 Apr 2013 16:40:21 +0400
Pavel Shilovsky pias...@etersoft.ru wrote:
This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename,
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules as well as Samba and
NFS file servers that export the same directory for Windows clients,
or Wine applications that access the same files simultaneously.
These flags are only take affect for opens on mounts with 'sharelock'
mount option. They are translated to flock's flags:
!O_DENYREAD - LOCK_READ | LOCK_MAND
!O_DENYWRITE - LOCK_WRITE | LOCK_MAND
and set through flock_lock_file on a file. If the file can't be locked
due conflicts with another open with O_DENY* flags, the -EBUSY error
code is returned.
Create codepath is slightly changed to prevent data races on
newely created files: when open with O_CREAT can return with -EBUSY
error for successfully created files due to a deny lock set by
another task.
It's good that this is consistent with the new patchset. I'm still not
100% sure that -EBUSY is the right error return here, but it should at
least help distinguish between mode bits don't allow me to open and
file has share reservation set.
Heck, since we're departing from POSIX here, maybe we should consider a
new error code altogether? ESHAREDENIED or something?
Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
fs/fcntl.c | 5 ++-
fs/locks.c | 93
+---
fs/namei.c | 45 +--
fs/proc_namespace.c | 1 +
include/linux/fs.h | 7 +++
include/uapi/asm-generic/fcntl.h | 11 +
include/uapi/linux/fs.h | 1 +
7 files changed, 150 insertions(+), 13 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 71a600a..7abce5a 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -730,14 +730,15 @@ static int __init fcntl_init(void)
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
* is defined as O_NONBLOCK on some platforms and not on others.
*/
- BUILD_BUG_ON(19 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
+ BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
O_RDONLY| O_WRONLY | O_RDWR|
O_CREAT | O_EXCL| O_NOCTTY |
O_TRUNC | O_APPEND | /* O_NONBLOCK | */
__O_SYNC| O_DSYNC | FASYNC|
O_DIRECT| O_LARGEFILE | O_DIRECTORY |
O_NOFOLLOW | O_NOATIME | O_CLOEXEC |
- __FMODE_EXEC| O_PATH
+ __FMODE_EXEC| O_PATH| O_DENYREAD|
+ O_DENYWRITE | O_DENYDELETE
));
fasync_cache = kmem_cache_create(fasync_cache,
diff --git a/fs/locks.c b/fs/locks.c
index a94e331..1eccc75 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -605,20 +605,73 @@ static int posix_locks_conflict(struct file_lock
*caller_fl, struct file_lock *s
return (locks_conflict(caller_fl, sys_fl));
}
-/* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
- * checking before calling the locks_conflict().
+static unsigned int
+deny_flags_to_cmd(unsigned int flags)
+{
+ unsigned int cmd = LOCK_MAND;
+
+ if (!(flags O_DENYREAD))
+ cmd |= LOCK_READ;
+ if (!(flags O_DENYWRITE))
+ cmd |= LOCK_WRITE;
+
+ return cmd;
+}
+
+/*
+ * locks_mand_conflict - Determine if there's a share reservation conflict
+ * @caller_fl: lock we're attempting to acquire
+ * @sys_fl: lock already present on system that we're checking against
+ *
+ * Check to see if there's a share_reservation conflict. LOCK_READ/LOCK_WRITE
+ * tell us whether the reservation allows other readers and writers.
+ */
+static int
+locks_mand_conflict(struct file_lock *caller_fl, struct file_lock *sys_fl)
+{
+ unsigned char caller_type = caller_fl-fl_type;
+ unsigned char sys_type = sys_fl-fl_type;
+ fmode_t caller_fmode = caller_fl-fl_file-f_mode;
+ fmode_t sys_fmode = sys_fl-fl_file-f_mode;
+
+ /* they can only conflict if FS is mounted with MS_SHARELOCK */
+ if (!IS_SHARELOCK(caller_fl-fl_file-f_path.dentry-d_inode))
+ return 0;
+
+ /* they can only conflict if they're both LOCK_MAND */
+ if (!(caller_type LOCK_MAND) || !(sys_type LOCK_MAND))
+ return 0;
+
+ if (!(caller_type LOCK_READ) (sys_fmode FMODE_READ))
+ return 1;
+ if (!(caller_type LOCK_WRITE) (sys_fmode FMODE_WRITE))
+ return 1;
+ if (!(sys_type LOCK_READ) (caller_fmode FMODE_READ))
+ return 1;
+ if (!(sys_type LOCK_WRITE) (caller_fmode
Re: [PATCH v5 4/7] CIFS: Use NT_CREATE_ANDX command for forcemand mounts
On Wed, 10 Apr 2013 15:45:33 +0400
Pavel Shilovsky pias...@etersoft.ru wrote:
2013/4/10 Jeff Layton jlay...@samba.org:
On Tue, 9 Apr 2013 16:40:24 +0400
Pavel Shilovsky pias...@etersoft.ru wrote:
forcemand mount option now lets us use Windows mandatory style of
byte-range locks even if server supports posix ones - switches on
Windows locking mechanism. Share flags is another locking mehanism
provided by Windows semantic that can be used by NT_CREATE_ANDX
command. This patch combines all Windows locking mechanism in one
mount option by using NT_CREATE_ANDX to open files if forcemand is on.
Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
fs/cifs/dir.c | 1 +
fs/cifs/file.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index d4331de..8587021 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -217,6 +217,7 @@ cifs_do_create(struct inode *inode, struct dentry
*direntry, unsigned int xid,
}
if (tcon-unix_ext cap_unix(tcon-ses)
!tcon-broken_posix_open
+ ((cifs_sb-mnt_cifs_flags CIFS_MOUNT_NOPOSIXBRL) == 0)
(CIFS_UNIX_POSIX_PATH_OPS_CAP
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
rc = cifs_posix_open(full_path, newinode, inode-i_sb, mode,
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 9394b2b..19038a4 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -455,8 +455,9 @@ int cifs_open(struct inode *inode, struct file *file)
else
oplock = 0;
- if (!tcon-broken_posix_open tcon-unix_ext
- cap_unix(tcon-ses) (CIFS_UNIX_POSIX_PATH_OPS_CAP
+ if (!tcon-broken_posix_open tcon-unix_ext cap_unix(tcon-ses)
+ ((cifs_sb-mnt_cifs_flags CIFS_MOUNT_NOPOSIXBRL) == 0)
+ (CIFS_UNIX_POSIX_PATH_OPS_CAP
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
/* can not refresh inode info since size could be stale */
rc = cifs_posix_open(full_path, inode, inode-i_sb,
@@ -624,6 +625,7 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool
can_flush)
oplock = 0;
if (tcon-unix_ext cap_unix(tcon-ses)
+ ((cifs_sb-mnt_cifs_flags CIFS_MOUNT_NOPOSIXBRL) == 0)
(CIFS_UNIX_POSIX_PATH_OPS_CAP
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
/*
I'm trying to understand why forcemand would matter here. Wouldn't
you just want to switch to using NT_CREATE_ANDX if O_DENY* is set
instead? What happens if I didn't mount with forcemand and then try to
use O_DENY*?
If cifs client mounts Samba share and negotiates posix extensions, it
uses trans2 command to open files. In this case O_DENY* flags that are
passed to open syscall won't be sent to the server and the file won't
be locked. This patch gives us an opportunity to make the client
always use NT_CREATE_ANDX command to open file - in this case O_DENY*
flags won't be missed.
You are right, we can leave forcemand option without changes and use
an appropriate smb command depending on openflags we have. Another
possibility is to make the client use NT_CREATE_ANDX command if new
'sharelock' VFS mount options is specified. If we mount a share with
sharelock mount option, we need O_DENY* flags sent to the server, but
the only one way to do it is to use NT_CREATE_ANDX command all the
time we need to open a file - so, using trans2 open command doesn't
make any sense in the case of 'sharelock' mounts.
(cc'ing samba-technical)
I don't understand. Why would we need to use NT_CREATE_ANDX in lieu of
the POSIX trans2 open if the client isn't setting a share reservation
on that particular open? The server should still enforce share
reservations that are already set on the file regardless of which
method is used.
Perhaps too we should add these flags to the POSIX open call as well.
It would be nice not to have to fall back to NT_CREATE_ANDX.
--
Jeff Layton jlay...@samba.org
Re: [PATCH v5 1/7] fcntl: Introduce new O_DENY* open flags
linux-nfs-ow...@vger.kernel.org wrote on 04/10/2013 06:24:39 AM: 2013/4/10 Jeff Layton jlay...@poochiereds.net: On Tue, 9 Apr 2013 16:40:21 +0400 Pavel Shilovsky pias...@etersoft.ru wrote: This patch adds 3 flags: 1) O_DENYREAD that doesn't permit read access, 2) O_DENYWRITE that doesn't permit write access, 3) O_DENYDELETE that doesn't permit delete or rename, Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules as well as Samba and NFS file servers that export the same directory for Windows clients, or Wine applications that access the same files simultaneously. These flags are only take affect for opens on mounts with 'sharelock' mount option. They are translated to flock's flags: !O_DENYREAD - LOCK_READ | LOCK_MAND !O_DENYWRITE - LOCK_WRITE | LOCK_MAND and set through flock_lock_file on a file. If the file can't be locked due conflicts with another open with O_DENY* flags, the -EBUSY error code is returned. Create codepath is slightly changed to prevent data races on newely created files: when open with O_CREAT can return with -EBUSY error for successfully created files due to a deny lock set by another task. It's good that this is consistent with the new patchset. I'm still not 100% sure that -EBUSY is the right error return here, but it should at least help distinguish between mode bits don't allow me to open and file has share reservation set. Heck, since we're departing from POSIX here, maybe we should consider a new error code altogether? ESHAREDENIED or something? That can make sense. I don't mind to change this part. I like this return code, it will help user space file servers return the correct error to their clients when they depend on the kernel to resolve share reservations. Internal to the kernel, having ESHAREDENIED will also be helpful to the NFS v4 and NLM code. Frank
Re: [2/5] include/wine/test.h: Report child process failures using shared memory.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@winehq.org wrote: As far as I can see ExitProcess returns 'failures' as the child process exit code, but variable 'failures' is not visible from the tests. Do you have a suggestion how to fix that? You need to report the status a different way. For instance you could store it in a file. How does this one look like? (In theory this approach could be used to transfer other child process information to the parent). Something like this would work, but it should be done in the test that needs it, not in the generic code. -- Alexandre Julliard julli...@winehq.org
Re: GSoC 2013 proposal: Implement XPath from scratch
On 4/11/2013 05:52, John Chadwick wrote: Hello, I am a student of computer science interested in entering Wine development via GSoC 2013. Upon looking at the various suggested proposals, the project of reimplementing XPath without libxml2 looked particularly interesting. I am familiar with the C language, W3C DOM and XPath, and I believe this is something I could do. I have a few questions I'd be interested in seeing answered: * One of the 'important things to keep in mind' is that changes should be incremental, with a fallback to libxml2 until new processor is fully functional. Does this mean at compile time, or at runtime, when the evaluator recognizes unimplemented features in an expression, or something else entirely? Yes, what I meant is that a transition should be as smooth as possible, it should be a runtime check like you described - if processor doesn't support something that's needed to process given expression it shouldn't fail completely, but fallback to existing code. * Is only MSXML 3.0 supported? It appears to be the only version implemented in the Wine source tree. It's just a way it's done. All code is in msxml3 dir, and msxml4 and msxml6 just forward to it, wine's msxml3 is able to create coclass versions that normally would live in msxml4 or msxml6. That's how code duplication is resolved. * What should I aim at doing first? Because what I'd be working on is a library, I would probably need some application to test features with (test cases aside.) Should I be using an existing program, or writing a new one? You should be writing tests for XPath API, and it should be placed somewhere in msxml3/tests. Currently it lives in domdoc.c cause XPath is a part of DOM API, but it will be probably okay to create a separate file if amount of tests is expected to be large enough (and it is imho). Speaking of tests, it should be easily extendible meaning that adding more tests should be mostly a matter of adding more test data and not that much of a code. Currently in existing XPath tests returned node set forms some string representation and we compare these strings with expected ones. I don't really like this way mostly cause it's hard to read and relate to original tree, but we could discuss that and make it better or find another way. By the way, the main reason why I added this topic to GSoC page was that it seems to me that it's possible to implement it incrementally, this is a very important, and XPath implementation is a significant part of a long term plan to stop using libxml2 and have our own code (likely a lot of own code). If anyone has anything to add here or is even opposed to such project for some reason, I'd really like to hear that. Thanks, John Chadwick
Re: [PATCH 1/2] wined3d: Use the np2_fixup to find out if a RECT texture is used
On 11 April 2013 11:32, Stefan Dösinger ste...@codeweavers.com wrote: @@ -1069,17 +1069,17 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont shader_addline(buffer, uniform sampler1D %s_sampler%u;\n, prefix, i); break; case WINED3DSTT_2D: -texture = state-textures[i]; +tex_rect = version-type == WINED3D_SHADER_TYPE_PIXEL (ps_args-np2_fixup (1 i)); The basic idea is ok, but the conditions for when np2_fixup is set are a bit more complicated than that. Specifically, look at how the WINED3D_TEXTURE_POW2_MAT_IDENT texture flag is set / cleared in texture_init().
Re: [PATCH 2/2] wined3d: Store ps 1.4 texture types in ps_compile_args
On 11 April 2013 11:40, Stefan Dösinger ste...@codeweavers.com wrote:
+for (i = 0; i 6; ++i)
+{
This could probably do with an appropriate constant.
+enum shader_tex_types
+{
+shader_tex_2d = 0,
+shader_tex_3d = 1,
+shader_tex_cube = 2,
+};
Please use uppercase for enum elements. Some wined3d prefixes
probably wouldn't hurt either, although I guess it doesn't matter so
much for things that are only used internally.
Re: [2/5] include/wine/test.h: Report child process failures using shared memory.
Alexandre Julliard julli...@winehq.org wrote: As far as I can see ExitProcess returns 'failures' as the child process exit code, but variable 'failures' is not visible from the tests. Do you have a suggestion how to fix that? You need to report the status a different way. For instance you could store it in a file. How does this one look like? (In theory this approach could be used to transfer other child process information to the parent). Something like this would work, but it should be done in the test that needs it, not in the generic code. What's wrong with using this code for all tests? And sorry, I don't see how I could utilize this in the ExitProcess test since I need to call ExitProcess with a not zero exit code and that code is currently used to report number of child failures to parent. -- Dmitry.
Re: [2/5] include/wine/test.h: Report child process failures using shared memory.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@winehq.org wrote: As far as I can see ExitProcess returns 'failures' as the child process exit code, but variable 'failures' is not visible from the tests. Do you have a suggestion how to fix that? You need to report the status a different way. For instance you could store it in a file. How does this one look like? (In theory this approach could be used to transfer other child process information to the parent). Something like this would work, but it should be done in the test that needs it, not in the generic code. What's wrong with using this code for all tests? And sorry, I don't see how I could utilize this in the ExitProcess test since I need to call ExitProcess with a not zero exit code and that code is currently used to report number of child failures to parent. The standard test code should be kept as simple as possible. Also creating extra mappings can potentially influence other tests. In your parent process you can use whatever mechanism you want to report failures, you don't have to use the child exit code. -- Alexandre Julliard julli...@winehq.org
Re: [2/5] include/wine/test.h: Report child process failures using shared memory.
Alexandre Julliard julli...@winehq.org wrote: The standard test code should be kept as simple as possible. Also creating extra mappings can potentially influence other tests. I still think that this code can be used on a general base, and if needed mapping name could be made more unlikely to dulicate. Especially since it's already written and tested quite a bit. In your parent process you can use whatever mechanism you want to report failures, you don't have to use the child exit code. If you mean avoiding to use winetest_wait_child_process() then yes, I can certainly do that. -- Dmitry.
Re: [2/5] include/wine/test.h: Report child process failures using shared memory.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@winehq.org wrote: The standard test code should be kept as simple as possible. Also creating extra mappings can potentially influence other tests. I still think that this code can be used on a general base, and if needed mapping name could be made more unlikely to dulicate. Especially since it's already written and tested quite a bit. The right way is to duplicate the code into the tests that need it, until you can demonstrate that there are enough tests using it to justify refactoring it into the standard code. -- Alexandre Julliard julli...@winehq.org
Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.
Hi Ken, On 04/10/13 16:16, Ken Thomases wrote: Hi Jacek, On Apr 10, 2013, at 4:24 AM, Jacek Caban wrote: On 3/28/13 8:31 PM, Ken Thomases wrote: Mac OS X 10.8 introduced support for TLS 1.1 and 1.2. Can someone with Mac OS X 10.8 test the attached patch for me, please. All I need is to verify that it compiles and when running dlls/secur32/tests/secur32_test.exe.so schannel, TLS 1.1 and TLS 1.2 are listed as supported protocol. Thanks for doing this. I don't have a 10.8 build system handy, myself, or I would have done it or would test what you've done. However, Apple's guidance on using weak linking says that you must explicitly compare against NULL. They don't quite say that testing the symbol as a standalone boolean expression won't work, but they do say that using negation (the ! operator) isn't sufficient. https://developer.apple.com/library/mac/documentation/developertools/conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW4 I'm not sure what the rationale is, but I think there's a peculiarity of what the compiler thinks it knows versus what the linker actually knows. Basically, the compiler figures there's a symbol that will be resolved (or cause a link error), so the check can be optimized away somehow. I think. Oh, such restriction seem to indicate a broken design of this weak linking... Following this is fine, through, but perhaps we should use nil to be sure that NULL override in winnt.h won't confuse the heuristic? Other than that, the patch looks good to me. Thanks for the review. Cheers, Jacek
Re: user32: SetTimer should respect the minimum and maximum timeout limits.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=25036 Your paranoid android. === TEST64_W7SP1 (64 bit msg) === msg.c:8247: Test failed: did not get expected count for minimum timeout (57 != ~64).
Re: Fresh WineWiki Theme, Straight from the Farm
On Sun, Apr 7, 2013 at 8:43 AM, André Hentschel wrote: First: Wow! You did a great job! Finally our Wiki theme is up to date :) I had a look at some Pages already and they look perfect here with FF 20.0 What i wonder is how we want to proceed with tables, i've seen different tables already and we should maybe choose one style: http://wiki.winehq.org/FOSDEM2013 http://wiki.winehq.org/Gecko - Here we used a workaround for the missing boarders and spacing http://wiki.winehq.org/Recommended_Packages - strange HTML http://wiki.winehq.org/Portability Thank you for the compliment! I just pushed Dimi's changes (I reset the author flag to him used the time of his email for the date) and my own last set of changes to my repo. If everyone wants, we could probably put the upstream repo on WineHQ now. After a bit more testing, I was actually able to figure out the other problems. The overflow issue was coming from a subtlety with absolutely positioned elements (if no explicitly positioned container exists, the container defaults to the browser window, not the page). I also fixed the problem where any link in a message box was being rendered like the clear button. The other funky rendering I was seeing actually has nothing to do with IE or the CSS. I forgot but Moin 1.5 doesn't spit out strict HTML4 so my browsers were defaulting to quirks mode. I guess the standalone server injects a doctype declaration though, which is why I wasn't seeing the problems in testing. Those problems should go away once upgrading to Moin 1.9. And regarding the tables, I'm cool with whatever style everyone agrees on, but I don't know how everyone feels about setting styles in the wiki- markup. Moin (1.5 at least) doesn't use th elements so I created a custom CSS class for tr elements called heading. It just makes the text heavier in print view, but on screen, it's like a heading row on the other pages, only with a wine-red background instead of black. - Kyle
