| |
| |
| |
|
Comments:
<0> where can i get an equalizer for xine?
<1> Hi all.
<1> Is anyone here using xine with nVidia XvMC?
<2> _ds, what are we waiting now?
<3> You mean "waiting for"?
<2> yes of course
<3> xine-lib release? Nothing, AFAIK.
<2> _ds, because amarok 1.4.1 will be released two days from now most likely, and needs 1.1.2 to work with flac files :P
<3> Then let's call it "ready" :-)
<3> The list archive needs to be checked for unapplied patches, but that can wait - and I'd prefer to have people resubmit.
<3> And gxine release? Well, there's a locking bug between play_exec() and js_queue_cb()...
<2> i'm preparing a new snapshot for my poor test monkeys in gentoo (xine-lib and xine-ui too) in the mean time :P
<3> Need to have an XSA written up for the security fixes too...
<2> _ds, well i don't have much things i can do about the release :P you need to be the release admin
<3> Do you want to write up the security advisory?
<2> i have no clue where to start but i can try if you give me the pointers :P i can always look up the glsa
<3> Well... you know the two fixes which were applied fairly recently... :-)
<3> The XSAs on the website should help wrt style & layout.
<2> let me try to dig them up because i have a bit of confusion in mind
<2> between xine-lib and xine-ui i had at least three false bugs reported to me directly in gentoo :P
<2> [because the xine-ui one for instance i fixed already last year in gentoo, and by the time the "exploit" was released the patched xine-ui was alreayd stable
<3> You've looked at the xine-lib changelog? Two CVE numbers there...
<3> Then there's the fix for an AVI problem which was reported to the list in (IIRC) April.
<2> fix that i have no clue what fixed it
<3> Which one? The AVI indexes problem?
<2> _ds, oh maybe was another
<2> but i'm sure there's one vulnerability that was fixed in CVS but i never found what and when actually fixed it :P
<3> Hmm. That'd be the alleged MPEG overflow.
<3> With the example which isn't an AVI - does "egg.mpg" ring any bells?
<2> yeah you're right
<2> _ds, where should the xsas be on the site?
<3> Module "xine_www", directory "documentation/security/".
<2> makes sense
<2> hmmm make distcheck failed on me
<3> Hmm?
<2> http://www.rafb.net/paste/results/lgpP7K68.html
<2> XINE_FONTDIR='${datarootdir}/xine/libxine1/fonts' yeah sounds likely
<3> Stick in a $(DESTDIR). You know that you want to :-)
<2> _ds, it is in a DESTDIR, that's what make distcheck does
<3> Hmm, right...
<2> the problem is that the makefile is wrongly mangled
<3> +h
<2> autoconf 2.60
<3> I have 2.59.cvs.2006.06.05-1 here.
<2> if XINE_FONTDIR is not used anywhere else, i would rather set it directly into the makefile
<3> Which is more or less 2.59d, I think.
<2> datadir = $(datadir)/xine/libxine@XINE_MAJOR@/fonts
<2> 2.60 is a refreshed version of 2.59d, just to break some more stuff :P
<3> :-)
<3> Hmm, 2.60 isn't in unstable yet...
<2> _ds, it's used only in src/xine-engine/osd.c a part that makeifle
<2> *makefile
<2> i'll fix it so that we don't have to put it in all places (and thus let it work fine without dirty hacks every time
<2> _ds, oh btw i've sent a few patches from our ffmpeg patch to upstream ffmpeg, so that the next sync would be simpler
<3> This is good...
<2> i'm thinking if instead of doing the whole #ifdef stuff to disable static unused functions it would be simpler to just put -Wno-unused-functions and be done with that
<2> if they are static and unused, gcc won't emit them anyway
<3> Seems reasonable.
<3> (I don't think that it is right now, or at least I need to check, but if not, well, at least it's a simple matter of hacking out inlines. Really, upstream needs to define before use, not just declare before use.)
<2> _ds, i build ffmpeg with -Os actually
<2> and i think the define before use thing is fixed already
<3> Ah, good...
<3> (and one ICE - m68k, IIRC)
<2> _ds, hm does anybody work on mingw right now?
<3> Not sure.
<2> because i think with latest autoconf changes it's no more possible to use the sed hack to move the / to \
<2> dnl polish paths (MinGW runtime accepts both \ and / anyway)
<2> hmm then just use / no? :P
<3> Probably, yes.
<2> damn that part of the code seems to rely quite a bit too much on the old autoconf behaviour
<3> I _think_ that Frantisek Dvorak is best placed to check.
<2> this autoconf release had a really bad timing
<3> I can use older autoconf without problem - sarge chroot :-)
<2> i could do that too, i have a local chroot and i can create one on the amd64 servers, but the problem will come when i'll have to patch configure.ac in gentoo :P
<3> Yes, there is that...
<3> I have to patch for VDR support.
<2> oh that famous patch
<2> hmm XINE_REL_* stuff is used only for win32 support
<2> who takes care of win32 portability?
<3> That'd be Frantisek Dvorak. Typical commit is a win32 build fix :-)
<2> well let me try and see not to break anything, maybe i can do that
<3> BTW, 'make distcheck' worked here.
<2> oh, think i found something
<2> XINE_FONTDIR='${datarootdir}/xine/libxine1/fonts'
<2> XINE_FONTPATH='/usr/local/share/xine/libxine1/fonts'
<2> it's using XINE_FONTDIR right now, instead of FONTPATH
<2> _ds, yeah but you work around it for the latter, while one Makefile.am used the former ;)
<3> Hmm. Must have missed that :-)
<2> _ds, you happen to know who takes care of this channel?
<3> Er, no, but I'd guess at jcdutton...
<2> i should try to get a hold of him when he's here then :P would help to have a CIA bot here
<3> http://ascii-wm.net/ for anybody who's interested
<2> _ds, i have already a few patches waiting for after 1.1.2 btw :P the visibility one (with proper check for gcc's supporting -fvisibility=hidden), the textrel one (that nobody still was able to find a crash with on x86)
<2> i would still ask for the m4b because users actually require it to be able to play the files correctly on both xine/amarok and itunes
<3> You may as well commit it then...
<2> i'm not sure on how xine behaves with protected m4{a,b} files, that's why i didn't
<2> if it dies gracefully (as in, doesn't crash but simply tell it's protected) i'd say it's fine to go
<3> Can you try it locally?
<2> if it does not, nop
<2> _ds, i tried with an unprotected file
<2> i don't have any protected one
<2> i should probably just buy something out of itms with the ibook
<3> Probably. Something that you actually want, of course :-)
<3> (2-0 to Italy, BTW)
<2> _ds, 3-0 for us :P
<2> argh reject
<2> one of my patches
<2> 237
<3> Oh, right.
<3> Nothing to worry about :-)
<2> the visibility one
<2> i think i was also the cause of a good deal of those rejects :P
<2> we should be using git, it would be simpler for me ;)
<3> Mercurial's quite nice...
<3> http://zap.tartarus.org/~ds/gxine/
<3> BTW, would be worth patching compositg manager
<3> ... compositor managers to take notice of _NET_WM_WINDOW_OPACITY_LOCKED - basically, "don't apply extra opacity effects, don't alter the setting".
<3> (xfwm4 SVN knows about this already.)
<2> _ds, that webinterface reminds me lot of gitweb :P
<2> [and of gitarella, fwiw]
<2> but i still prefer git, it's sh+c rather than python, quicker ;)
<3> True... "fast enough", though.
<2> _ds, actually it would be enough to me to use svn, i could use git-svn then ;)
<3> I'm not particularly keen on svn...
Return to
#xine
or
Go to some related
logs:
centos working slow
dhcp3D
mke2fs ubunti
noselinux boot parameter
#php
postfix popbefore
!!! /usr/local does not seem to have a valid PORTDIR structure.
#css
Cannot find a valid baseurl for repo: core
#oe
|
|