#wine-staging

regarding removing old attachments, it's helpful to look at old logs too sometimes, i don't know if it's possible to automate, diffs should definitely stay

it will be more formalized in future using 'needinfo' status which automates this a bit ... getting rid of 'abandoned?' keyword way

nsivov: well, removing old attachments > 1 MB would probably be sufficient

if removed there's no way to tell if it was a duplicate of something. in case you search by application name for example

how often do you look at old log attachments from closed bugs? i could count that with fingers from one hand ... and i did a lot of bugs :). 99.9% nothing of value would be lost. that's also one of the reason to put short snippts of relevant log info into comment

maybe, i do look at those from time to time, if i'm interested in particular application, it's not necessary useful every time of course, but still something

is disk space really such a big problem? old attachments could even be moved to a separate server if disk space is so limited on the bugzilla host

maybe the backtrace and terminal txt could stay ... larger logs with specific debug channels are less useful afterwards.

warn+err logs are something i would blacklist for uploading :)

slackner: the upstream bug tracker has about 52000 attachments

DarkPlayer: increasing the maximum size will not automatically lead to flood of huge logs ;)

sure, but just to give you an impression

you can get a 3TB for a bit more than 100$, so I don't think it would be a problem anyway

+hdd

focht: ugh, even the game updater has race-conditions on multicore systems ^^

you mean the torrent mode? yes.

yep

i had a brief look some time ago ... suspecting wine's io completion ports being the problem. but not for certain since it's hard to debug/trace, changing timing behaviour and also producing gb of logs

focht: yeah, sometimes there still seem to be some weird things going on with wines completion ports ;)

there are one or two bugs in bugzilla related to completion ports (although not explicitly mentioned)... unfortunately i didn't comment on after brief look hence i don't remember the bug ids. those are real time stealers :|

i could put the light out here and the room is still illuminated ... crazy moon

focht: i also could put the light out and the room is still illuminated ... crazy lcd displays *g* ;)

okay, was a bad joke, but .. xD

well last time i looked .. it was still round shaped .)

focht: did you ever investigate the steam webhelper race-conditions ? they might also be related to completion ports

which bug?

i don't think there is a bug for it, but it crashes sometimes on exit

already since some time.. i first suspected that its a staging bug, but in fact it also occurs with upstream, just not that frequently

didn't encounter that .. there is a race with initial auth though that results in "network unavail" or so

focht: just tried again, and still present here.. can reproduce it very reliable

focht: crashes either with assertions in the webhelper code, or with write access faults

(always on exit, so not really critical for the functionality, but ...)

interesting ... just start steam and then exit?

yup

focht: here an example what you have to look for: http://ix.io/l2S (no clean prefix though)

this is the variant with the assertion

can you run with WINEDEBUG=+tid,+pid,+seh,+loaddll,+process pls

also +debugstr

focht: http://ix.io/l2T ... unfortunately a different error this time

i haven't spend much time to investigate the issue so far, thought you might already know it

focht: ah, here one log with int3 again: http://ix.io/l2U