Re: Guix video repository: First video script commited
Hi! Thank you very much for your feedback. I have just pushed the first part of the second video. May someone test it and give feedback too? Regards :) Laura
Re: Reverted: gnu: font-awesome: Update to 5.7.2.
Leo Famulari writes: > On Sat, Feb 23, 2019 at 09:03:10PM -0500, guix-comm...@gnu.org wrote: >> iyzsong pushed a commit to branch master >> in repository guix. >> >> commit 590b989c95f5b72dfe4b9928d1426fb7d35d1428 >> Author: Pkill -9 >> Date: Sat Feb 23 10:12:32 2019 + >> >> gnu: font-awesome: Update to 5.7.2. >> >> * gnu/packages/fonts.scm (font-awesome): Update to 5.7.2. >> [home-page]: Use HTTPS. >> >> Signed-off-by: 宋文武 > > If I understand correctly, Font Awesome 5 is incompatible with the Free > System Distribution Guidelines, specifically this section [0]: > > -- > “Information for practical use” includes software, documentation, fonts, > and other data that has direct functional applications. It does not > include artistic works that have an aesthetic (rather than functional) > purpose, or statements of opinion or judgment. > > All information for practical use in a free distribution must be > available in source form. (“Source” means the form of the information > that is preferred for making changes to it.) > -- > > The problem is that, in version 5, upstream stopped distributing the > build scripts and so the icons can no longer be built from source even > though the sources are distributed freely. Okay, a unfortunate situation. > > We discussed this previously in bug #32916 [1] but unfortunately forgot > to add a comment in the package definition warning of this issue. > > I've reverted this commit and added a comment about the issues in > version 5. > > [0] > https://www.gnu.org/distros/free-system-distribution-guidelines.en.html > [1] > https://bugs.gnu.org/32916 Thanks for the explanation!
Automatically building packages affected by submitted patches
Hey, In short, following on from some previous emails about Patchwork [1] and tracking and inspecting how Guix changes over time [2], I've got to the point where I have a very rough setup for building packages changed by patches sent to the guix-patches mailing list. 1: http://lists.gnu.org/archive/html/guix-devel/2018-10/msg00638.html 2: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00089.html If you want to see this in action, assuming for a given patch series that all goes to plan, patches sent to the guix-patches mailing list as normal should appear in the Patchwork web interface [3], and after some processing, a specification should be inserted in to this Cuirass instances [4] which builds the packages affected by the patch series. 3: https://patchwork.cbaines.net/project/guix-patches/list/ 4: https://cuirass.cbaines.net/ For a specific example, here [5] is series 700 (a Patchwork id). There are a number of intermediate steps, but this is the specification in Cuirass [6]. 5: https://patchwork.cbaines.net/project/guix-patches/list/?series=700 6: https://cuirass.cbaines.net/jobset/series-700 If you want to see how this is held together at the moment, the main script can be found here [7]. That script repeatedly in a loop: - Looks at patch series in the Patchwork database that have been processed through the patchwork-test-series job in Laminar. - Gets the recorded commits for the base commit and head commit. - Fetches the list of affected packages from the Guix Data Service. - Assuming the list is available, ensures that a Cuirass specification exists to build the affected packages. 7: https://laminar.cbaines.net/cfg/scripts/guix-patchwork-helper This is very much an initial prototype, and from this I've got a load of ideas about how better to set things up. In terms of features I'd like to work towards next, the main thing on my mind is doing something useful with the data from building these packages. With the goal of displaying a check in Patchwork about the build status of the affected packages, I need to compare what's been build by my Cuirass instance, with what https://ci.guix.info/ has built. To do this, my current plan is to have the Guix Data Service monitor a number of Cuirass instances somehow, extract information from them and store it. You'd then be able to get a comparison for the build status using the results gathered from the two Cuirass instances from the Guix Data Service. Going back to some of the aims I have with this, I think something like this could help people review and test there own patch submissions, as well as assisting those taking the time to review patches that others have submitted. There's a few more related things on my mind, but I'll end this email here. Chris signature.asc Description: PGP signature
Re: texlive-fetch instead of svn-fetch
Thanks for clarifying this. Then I 100% agree with your approach. I should have a little bit more free time in the coming days, so I'll (finally) get down to write the tlpdb importer :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: texlive-fetch instead of svn-fetch
Pierre Neidhardt writes: > Would that still be needed if we implement a tlpdb-based importer? The importer only helps you generate the initial package definition. A tlpdb-based importer cannot do magic. The tlpdb file tells it what files are expected to be provided by the package and what files are considered sources, but this doesn’t change the fact that these files come from different parts of the TeX Live SVN tree and somehow have to be added as inputs. The importer can automate this by adding the various native inputs, but you still end up with an ugly package definition. Think of all of the native inputs you’ll have to update when updating an existing package definition… Changing the way the input sources are represented is independent from the way this representation is generated. -- Ricardo
Re: texlive-fetch instead of svn-fetch
Hi, Would that still be needed if we implement a tlpdb-based importer? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Guix video repository: First video script commited
Hi Laura and sirgazil, I was able to build videos in 01-installation-from-script following the updated informations in the README, that is: 1. environment.sh 2. install-fonts.sh 3. cd 01-installation-from-script/ && buildall.sh the only "strange" message I see during the build is --8<---cut here---start->8--- convert: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG `01-installation-from-script/en_US/out/secondCli-0148.png' @ warning/png.c/MagickPNGWarningHandler/1667 --8<---cut here---end--->8--- but AFAIK we should ignore it https://github.com/ImageMagick/ImageMagick/issues/884#issuecomment-451084328 (or make it quiet?) sirgazil writes: [...] > + Text is not rendered with the appropriate font (known issue). with commit 1dd8478 font issues are gone: done! > + Firefox 65.0.1 says "Video can't be played because the file is > corrupt." same here: each video built in 01-installation-from-script/en_US/videos/ fails to be played in Firefox 60.3.0esr Chromium 72.0.3626.119 can play all them, but colours are altered like with Totem from sirgazil tests; chromium auto-rescales the different aspect ratio in cli and noCli videos [...] > As for the corrupted videos, in the Totem video player, the video plays > but black colors are displayed green instead (maybe result of the > corruption?). In VLC the video plays OK, and the colors are fine. mpv also plays the video with unaltered colours but is non able to manage the different aspect ratios: I have to switch to full-screen (so auto-rescales) in cli sessions video parts and switch back to normal screen when video svitches to noCli [...] about aspect ratio of videos, mediainfo reports: --8<---cut here---start->8--- [...] 01-installation-from-script/en_US/videos $ mediainfo * General Complete name: 01-installation-from-script.webm Format : WebM Format version : Version 4 / Version 2 File size: 8.80 MiB Duration : 3 min 47 s Overall bit rate : 324 kb/s Writing application : Lavf58.20.100 Writing library : Lavf58.20.100 / Lavf58.20.100 Video ID : 1 Format : VP9 Codec ID : V_VP9 Duration : 3 min 47 s Width: 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 30.000 FPS Writing library : Lavc58.35.100 libvpx-vp9 Default : Yes Forced : No DURATION : 00:03:47.82400 Audio ID : 2 Format : Opus Codec ID : A_OPUS Duration : 3 min 47 s Channel(s) : 1 channel Channel positions: Front: C Sampling rate: 48.0 kHz Bit depth: 32 bits Compression mode : Lossy Writing library : Lavc58.35.100 libopus Default : Yes Forced : No DURATION : 00:03:47.77800 General Complete name: 1.clino.01-installation-from-script.webm Format : WebM Format version : Version 4 / Version 2 File size: 2.41 MiB Duration : 56 s 973 ms Overall bit rate : 355 kb/s Writing application : Lavf58.20.100 Writing library : Lavf58.20.100 / Lavf58.20.100 Video ID : 1 Format : VP9 Codec ID : V_VP9 Duration : 56 s 967 ms Width: 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 30.000 FPS Writing library : Lavc58.35.100 libvpx-vp9 Default : Yes Forced : No DURATION : 00:00:56.97300 Audio ID : 2 Format
texlive-fetch instead of svn-fetch
Hey Guix, Tex Live packages often have a complicated source file layout. They don’t usually come in a nice self-contained tarball. Instead they are a mosaic of files that are sourced from different parts of the Tex Live SVN tree. For many Tex Live packages the “source” field is insufficient, so we add lots of additional origins as native inputs. This makes for very ugly package definitions. (See texlive-fonts-txfonts for an example.) What do you think about adding a new procedure that can fetch sources from different locations? This might be done by extending SVN-FETCH or by adding a special TEXLIVE-FETCH that fetches sources from different directories in the source tree, returning them as *one* origin with one simple hash. -- Ricardo
Re: Guix video repository: First video script commited
On Fri, 01 Mar 2019 12:01:45 +0100 Giovanni Biscuolo wrote: > my personal workflow in this case is to use the [env] to build and > "outside env" for editing and analisys (e.g. with rmlint), BTW I agree > with you ls and less are *very* useful inside the container Gábor presented today another solution, which is much better I think: The script will call the environment like: guix environment -C --ad-hoc ... -- ./build-video.sh 01-firstvideo Then the container is really just used to build video and will be left directly afterwards. I think he will push later/in the next days. Björn pgpUncwt8wnhf.pgp Description: OpenPGP digital signature
Re: Guix video repository: First video script commited
El 28/02/19 a las 4:52 p. m., Laura Lazzati escribió: Hi! Thanks for the steps! + Text is not rendered with the appropriate font (known issue). + Firefox 65.0.1 says "Video can't be played because the file is corrupt." We are currently testing everything with vlc and mpv, but thanks for this too. These are the steps I followed to build the videos: 1. $ git clone https://git.savannah.gnu.org/git/guix/videos.git (I got commit 03930dc) 2. Add missing fonts to $HOME/.fonts Are you creating the .fonts directory here? 3. $ fc-cache -f 4. $ fc-list ($HOME/.fonts is listed) 5. $ cd path/to/videos 6. $ ./environment.sh You should add the fonts inside the environment :) (2. and 3.) 7. [env]# cd 01-installation-from-script 8. [env]# ./buildall.sh After running these, the videos are available in: videos/01-installation-from-script/en_US/videos/ The resulting videos don't use the appropriate fonts in my case. Let me push some changes and answer back, but you should be able to create the videos after my next push. I should update the README with the order in which scripts should be run, so that there is no confusion. No wonder it didn't work for me :P I tried again with your changes, and text is displayed correctly in the videos. -- Luis Felipe López Acevedo http://sirgazil.bitbucket.io/
Re: Guix video repository: First video script commited
Ricardo Wurmus writes: [...] > There will be lots of files. That’s expected. They are frames for the > command line videos. Eventually all of them would be converted from txt > to png. OK I got it I've updated my repo with current master and restarted building, I'll report back ASAP Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Guix video repository: First video script commited
Hi Björn, Björn Höfling writes: [...] > since the environment is a CONTAINER, it contains really nothing > besides what you explicitly add to it. I was aware of this :-) > I added those variables. It is > really helpful to have at least "ls" and "less", and during development > some more tools. When everything is settled, we can shrink that down to > coreutils and less for example. my personal workflow in this case is to use the [env] to build and "outside env" for editing and analisys (e.g. with rmlint), BTW I agree with you ls and less are *very* useful inside the container anyway this is non at all a priority, just my personal wishlist :-) Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
