[vlc-devel] Windows releases

Rafaël Carré funman at videolan.org
Sat Apr 9 12:41:59 CEST 2016

On 04/06/2016 08:55 AM, Jean-Baptiste Kempf wrote:
> Hello,
> On 05/04/2016 12:37, Rafaël Carré wrote:
>> Why are users on 2.2.1 not prompted to upgrade to 2.2.2
>> despite it fixing a bunch of vulnerabilities?
> Because of the green line regression, and the numerous bugs related to that.

Fair enough but why continue to propose 2.2.2 for download?
Is it broken enough for updaters but not enough for new installations?

>> Another question, why are win64 users still on 2.1.5 ???
> Because you did not update to 2.2.1.
>> I fixed that to 2.2.2 but I notice this has been
>> reverted without me being aware of it.
> See above, about greenline.

I was under the impression that it was your job to enable updates when
are synchronized.

Make up your mind, you can not both let me update that file under my own
and also complain
and/or revert my changes, especially without telling.

If you want to decide the time when update is enabled there is no point
on not enabling
both win32 and win64 builds and I've always been speedy on making win64
builds available.

So now I'll let you update both files at the same time, ok?

>> I think it's very much not collaborative and I am not
>> sure what to do there, thus I'm asking about these issues
>> in public.
> Sorry, but the problem is that you do your stuff on your own, you don't 
> listen to other and do the stuff in the way you want, even after we told 
> you to do differently. And you misuse your powers.
> So yes, I'm ignoring you on IRC for now, because I do not want to fight.
> Fighting takes too much time that I do not have.
> Note that I'm not saying you're doing the following because of malice or 
> evilness (we have elenril for that), but that you are careless and 
> that's annoying for build and releases.
> So, here are my explanations:
> 1) You do not care about Windows 64 and do not test it.
> You clearly do not use Windows 64, and you don't test VLC on it. And I 
> mean actual testing, not just launch VLC once.
> Related to that, you do listen to the users, not answer on the forum, do 
> not triage the trac tickets, do not answer on videolan at .

I'll remind you I am a volunteer and chose to dedicate my time the way I
like it.

> If you had, you'd see that they are many issues that are Win64 only and 
> are not fixed.
> For example:
> DVD do not seem to work in win64, but work in win32. You can see 
> numerous complaints on the forum, and on our videolan@ mailing list, in 
> the last weeks:
> [videolan] dvd stops playing
> [videolan] Your app refuses to open my cds or or dvds
> DVD is not a fringe feature...
> Other example:
> Left click Mouse not responsive on widgets!
> https://forum.videolan.org/viewtopic.php?t=131242
> https://forum.videolan.org/viewtopic.php?f=14&t=127765&p=429621&hilit=mouse#p429621
> https://forum.videolan.org/viewtopic.php?f=14&t=128656&p=431927&hilit=mouse#p431927
> https://forum.videolan.org/viewtopic.php?f=14&t=110241&p=427187&hilit=mouse#p427187
> People can't CLICK on the interface! That's like the most basic we could do.
> Solution: https://forum.videolan.org/viewtopic.php?t=131242#p438939 use 
> 32bits version

I not only test VLC for win64, I use it to watch movies.

If you know of win64 bugs why do you not guys tell me?

> Final example: in the 10 months where 2.2.1 was the official release, 
> you did not even test the update system, which was blocked on 2.1.5.
> Else, you would have asked/did the upgrade on the update system.
> And there are numerous examples of playback not working in 64bits. The 
> forum is full of those...
> 2) You miscompile VLC
> We discussed numerous times why we should use static libgcc for the VLC 
> build, because doing otherwise breaks any application using a different 
> working directory (C++ modules wouldn't load, because libgcc_s not in 
> the LoadLibrary path), and because it was breaking usage as 3rd party 
> application, as soon as they don't have the exact same compiler and 
> toolchain.
> Yet, you keep having libgcc_s_seh in the 64bit build, for no good reason.

If debian gcc is somehow broken you'll have to convince debian.

> 3) contribs, altair and buildbot
> We clearly said, during VDD, and on IRC, that we must keep gcc 4.9 for 
> all the 2.2.x builds, and upgrade to gcc5 for 3.0. Changing compiler can 
> bring regressions that are annoying. And gcc5 breaks the C++ ABI.
> Which is why I did pin gcc-mingw to 4.9.3 on altair.

Never heard about this before you complained.

I had been upgrading altair regularly before.

> On 2015-12-28, you upgraded to 5.3.1.
> And of course, because of that, you broke all the builds for Win32 until 
> Feb 18 (50 days!), including all the nightly build.
> So, yeah, maybe that should have been more clear, like a post on the ml, 
> still this is really uncool, because you did not ask...

I couldn't guess to ask either

> 4) contribs, continued
> Because of that, you redid some contribs for Win32 on Feb 18: 
> ftp://ftp.videolan.org/pub/videolan/contrib/i686-w64-mingw32/vlc-contrib-i686-w64-mingw32-20160218.tar.bz2
> without telling me, who is still the defacto maintainer for win32...

It fixed the nightly builds though.

I'd have told you if you had dared answering me!

18:51 < Sean_McG> funman: any plans to fix the win32 buildbot soon?
18:52 < funman> Sean_McG: well j-b complained last time i touched the
18:52 < funman> and now he's ignoring me

I chose the path to fixing things.

> The other issues are:
> - they are built on a 64bits machine, which breaks compilation for 
> everyone on a 32bits machine, (moc 32bits can run on 64bits, not the 
> opposite). And the documentation to build was not updated to explain 
> this. 

contrib build used to generate 64 & 32 bits qt binaries.

Side note, someone doing development on a 32bits machine is not serious.

Also doing the build on a 32 bits machine would break compilation for
on a 64 bits machine without 32 bits layer, or someone with an
incompatible glibc...

> And I'm quite sure we mentioned that in the past.
> - gcc 5...
> - they are missing some libraries (not that important, but still)

If it's not important then don't mention it, if it is important then give
the libraries.

I do not run anything else than "make fetch" and "make" so I don't see
how libraries can go missing.

> 5) root mis-use and ftpmaster
> You asked for root access, at a VideoLAN meeting. Fine.
> Yet you've done almost nothing for roots. So why ask for it?

I made my case clear when I asked for it.

> And you keep misusing it.

That is news to me.

> For whatever reason, you refuse to use the ftp incoming like everyone 
> else (x265 people, jpsaman, Meuuh, hpi, Felix, me) and you insist on 
> copying files through sftp as root. And of course, almost always in the 
> wrong container or in the main host!

I do not refuse to use ftp, I was never asked about it.

What is wrong with sftp?

I have also been using wget, is it wrong too?

> Since the migration to goldeneye, I'm quite sure that we said this was 
> not the way to go. We spoke numerous time of the split and difference 
> between roots and ftpmasters and about the LXCs separation, at several 
> roots meeting.

I have no idea what you are talking about.

> And then, you did the same for the update.videolan.org, in a different 
> LXC!! And you copied status-win64 as root:root!
> First if you do those actions as roots, you did something wrong (you 
> should almost never do anything at root, unless necessary), but it did 
> not bother you that NOTHING else in the folder was owned by root...
> (and that is beside the fact that we said we should not do the update to 
> 2.2.2, as previously explained.)

Where was that said?

> Sure not everything is perfect on Goldeneye (including on the ftp 
> permissions), but we're working quite a bit on improving security and 
> having correct privilege separations, and you ignore that.

Yes, I ignore what's going on so please enlight me instead of keeping me in
the dark and complaining whenever I am doing something.

> 6) IRC ban abuse
> You kicked me out of channels, because I was not responding to you in 
> the timely fashion you wanted. You know, you can mail me, you can ask 
> other to speak to me if it is urgent, or you can even phone me.
> But that does not allow you to kick me of a chan.

That was a joke, I got kicked too.

> Windows Signature
> -----------------
> As explained already, the issue with the Windows certificate, is that 
> the cert does not and cannot have the password. So anyone with this cert 
> can sign any software and have it running full privilege on Windows. And 
> that's before the Centennial project, where we'd run full-trust.
> So, no, I don't transfer it lightly, even if you ask. And without a full 
> GPG setup, or IRL.
> So yes, I'm sorry, I have nothing against you, nor do I believe you are 
> mis-intentionned, nor do I dislike you, nor do I believe you hate me or 
> something.
> However, it is beyond me why you want to maintain the win64 port or want 
> to be root and manage those releases or buildsystem, because of the 
> points listed above.

You miss something simple, I do these things because I like it.
I worked on the win64 port and update system so I yeah I like doing it.

Besides I sometimes catch missing patches or misdone backports that you
did not catch building win32.

> Not to mention that you are extremely skilled in programming and we 
> deeply need programmers, and so your time would be more valuable 
> elsewhere, notably in VLC development.

Nice flattery but I chose my own duties and you should not be pissed because
it's not what you'd have like me to do.

Besides I have never refused to help a fellow developer asking for it.

> With my very best regards,

More information about the vlc-devel mailing list