Recherche avancée

Sur d’autres sites (4714)

• Working directory in Dockerfile is not what is expected to be

  31 mai 2022, par user1765862

  I have following Dockerfile

  


  FROM public.ecr.aws/lambda/dotnet:6 AS base

FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim as build
WORKDIR /src
COPY ["AWSServerless.csproj", "AWSServerless/"]
RUN dotnet restore "AWSServerless/AWSServerless.csproj"

WORKDIR "/src/AWSServerless"
COPY . .
RUN dotnet build "AWSServerless.csproj" --configuration Release --output /app/build

FROM build AS publish

RUN apt-get update && apt-get install -y apt-utils libgdiplus libc6-dev

RUN apt-get install -y ffmpeg

RUN dotnet publish "AWSServerless.csproj" \
            --configuration Release \ 
            --runtime linux-x64 \
            --self-contained false \ 
            --output /app/publish \
            -p:PublishReadyToRun=true  

FROM base AS final
WORKDIR /var/task

CMD ["AWSServerless::AWSServerless.LambdaEntryPoint::FunctionHandlerAsync"]
COPY --from=publish /app/publish .


  


  As per ffmpeg docs In order to use ffmpeg I need to set its binary folder
for example with

  


  {
  "BinaryFolder": "/var/task",
  "TemporaryFilesFolder": "/tmp"
}


  


  Error

  


  


  An error occurred trying to start process './ffmpeg' with working
directory '/var/task'. No such file or directory

  


  


  What is the working directory here ?

  


  Update :
Actual error is being thrown when I try to execute following command (FFMpegCore package) from my api controller

  


  public class MyController : ControllerBase&#xA;{&#xA;    public async Task<string> Get()&#xA;    {    &#xA;         await FFMpegArguments&#xA;               .FromPipeInput(new StreamPipeSource(myfile))&#xA;               .OutputToPipe(new StreamPipeSink(outputStream), options => options&#xA;                  .WithVideoCodec("vp9")&#xA;                  .ForceFormat("webm"))&#xA;                  .ProcessAsynchronously();&#xA;         ...&#xA;    }    &#xA;}&#xA;</string>

  


• Support building C++ files with MSVC

  13 avril 2017, par Aaron Levinson

  Support building C++ files with MSVC
  Made appropriate changes to be able to successfully
  
  build C++ files using a Visual C++ build on Windows.
  Based on an earlier patch by Kyle Schwarz.
  Comments :
  — compat/w32pthreads.h : Made appropriate changes to w32pthreads.h to
  
     get it to build when it is being included in a C++ file and built
  
     with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
  
     described above.
  — configure :
  
  a) Now calling set_ccvars CXX to cause the various CXX_ variables to
  
     be setup properly.  For example, with MSVC (Microsoft Visual C++),
  
     this causes CXX_O to be set to -Fo$@ instead of using the default
  
     value.  The default value does not work with Visual C++.  This
  
     change will also have the impact of correcting CXX_O (and possibly
  
     CXX_C) for other compilers, although this is really only relevant
  
     for the Intel compiler, in addition to MSVC.
  
  b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
  
     currently only relevant for building the
  
     Blackmagic/Decklink-related files under avdevice.
  Signed-off-by : Hendrik Leppkes <h.leppkes@gmail.com>
  

  • [DH] compat/w32pthreads.h
  • [DH] configure

• Anomalie #3504 : anomalie dans cvt_autosave : les purges ne se font pas

  23 juillet 2015, par Peet du

  Tu as raison...une fois que tu valides ton formulaire (avec _autosave activé), les données de session concernant CE formulaire sont bien purgées. Pas de bug en l’état puisque ce traitement n’est pas basé sur la constante _AUTOSAVE_GB_DELAY

  Ce que j’avais oublié de préciser dans mon post, c’est que le bug signalé se situe dans la deuxième partie du traitement, celle qui "purge aussi toutes les vieilles autosave". C’est elle qui est basée sur _AUTOSAVE_GB_DELAY.
  Voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/cvt_autosave.php#L88

  Si j’ai bien compris, elle traite le cas où le site contient plusieurs formulaires CVT avec l’autosave activé. Dans ce cas on purge également ces sessions.
  Et c’est là que le bug sur le timestamp fait son office. Ces vieilles sessions ne seront jamais purgés.

  SUGGESTION
  Perso, je trouve que ce fonctionnement est astucieux, mais il induit un fonctionnement confus pour l’utilisateur et pour le développeur.
  Si le visiteur revient sur son formulaire, (même 1 an après) il trouve les champs remplis puisque _AUTOSAVE_GB_DELAY n’est pas pris en compte dans ce cas . Il valide son formulaire et sa session pour ce formulaire est purgé.
  Puis dans la foulée il arrive sur un autre formulaire et là....rien ?! (ben oui, il a validé le premier et la purge basée sur _AUTOSAVE_GB_DELAY a fonctionnée (si on corrige le bug hein ;-)

  Bref, perso j’ai modifié le core (je sais, c’est mal) en mettant les purges uniquement basée sur _AUTOSAVE_GB_DELAY dans la fonction cvtautosave_formulaire_charger. On (peut) garder la purge à la validation du formulaire.

  SUGGESTION 2
  L’idéal serait, selon moi, de garder cette dernière idée avec un ajout : on purge dans le répertoire /sessions toutes les données de tous les utilisateurs pour lesquels la valeurs _AUTOSAVE_GB_DELAY a été dépassé. Ça marche bien et de plus, d’un point de vue de sécurité, cela règle en partie le problème des personnes qui on mal lu la doc sur la partie "Vie privée" (voir http://www.spip.net/fr_article5428.html).

  SUGGESTION 3
  même si vous n’êtes pas d’accord avec mon analyse, serait-il possible de mettre

  • cvtautosave_formulaire_charger
  • cvtautosave_formulaire_traiter

  en _dist ?