Re: Problem with Qt5::webEngineWidget
On Mon, Jul 01, 2019 at 12:39:07PM +0430, Fakhri Sajadi wrote: > I'm using Qt5::webEngineWidget in my application, I wanted to package it for > guix and face with a problem, apparently, Qt5::webEngineWidget is skipped in > Qt package > Link = > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n123 > > What is its status now? Is it solve in next version of Qt?(for now "5.11.3" > is packaged in upstream) I don't think the status of QtWebEngine in Guix is totally clear, but you should be optimistic :) In general, the requirements for software that is included in Guix are 1) the software must be free software and 2) it must fit within the Free System Distribution Guidelines: https://www.gnu.org/distros/free-system-distribution-guidelines.en.html As you may know, QtWebEngine is based on the Chromium codebase but is focused on rendering of web content rather than offering a complete web browser. There was some controversy about the addition of the ungoogled-chromium package to Guix, but the objections to it were unfounded. The QtWebEngine team says they take similar steps to avoid problems with upstream Chromium as we did with ungoogled-chromium: https://wiki.qt.io/QtWebEngine So, I bet that QtWebEngine will be fine for Guix. If there is more controversy about QtWebEngine we will moderate the discussion so that it remains respectful, focused, and without pointless tangents. A practical note: Building Chromium from source requires a very powerful computer, with lots of RAM, disk space, and the fastest CPU you can find. I bet that QtWebEngine is similar.
Re: PLEASE! Input Attach Service
> As for any service these values are already documented [1]. > Make sure that you are reading an up to date version of the manual. Ah I see. Sure, I can check. > The wacom device type is already the default. As inputattach can be > used > for many device types I would not want to change the default values > to > suit our specific needs. Oh no, I did not want to change the default values just so it works for me. :-) > I don't even know whether the /dev/ttyS4 port is a constant among > x200t thinkpads. It appears tyyS4 is constant among x200-t devices, as it worked for both of us. You could make it the default value and you could change if you encounter any new facts. Regards, RG.
Re: PLEASE! Input Attach Service
Raghav Gururajan writes: > Sure ☺. Btw, could you expand/update the "inputattach-service-type" of > the Guix Manual, to include "inputattach-configuration" scheme > parameters/procedures and it's possible cum default values? Thanks! As for any service these values are already documented [1]. Make sure that you are reading an up to date version of the manual. > Btw, would you be able to set the default vaules of "device" and > "device-type" to "/dev/ttyS4" and "wacom" respectively for > "inputattach-configuration"? The wacom device type is already the default. As inputattach can be used for many device types I would not want to change the default values to suit our specific needs. I don't even know whether the /dev/ttyS4 port is a constant among x200t thinkpads. Tim. [1] https://www.gnu.org/software/guix/manual/en/guix.html#Miscellaneous-Services
Re: Why reproducibility is breaking by metadata?
zna...@disroot.org writes: > Hello, Guix Help! I am translating Guix manual and found that the > author is entirely given to reproducibility. It leads to such phrases > that metadata breaks reproducibility when he describes > '--save-provenance' flag of 'guix pack' command here: > > 'This option is not enabled by default because, like timestamps, > provenance information contributes nothing to the build process. In > other words, there is an infinity of channel URLs and commit IDs that > can lead to the same pack. Recording such “silent” metadata in the > output thus potentially breaks the source-to-binary bitwise > reproducibility property. ' > > I did not expected such a categorical statement. I think, it does not > actually break reproducibility but only complicates checks. If we have > to talk about reproducibility to ignoramus, saying 'this option breaks > reproducibility option' have to have remark 'simply put' or 'plainly'. If you define reproducibility in a pragmatic way as something that can be verified without deep knowledge of file formats, then the only reasonable definition is bitwise identity. That's what anyone can check with generic tools. If you want to check that two outputs of 'guix pack' are equivalent, i.e. identical up to provenance data, then you need a separate tool for each output format (and you have to write those tools yourself because to the best of my knowledge they don't exist yet). In short, I agree with the statements made in the text. However, you are completely right that this paragraph is not written at the right level for the typical user. Here is a proposition for improving it: --save-provenance Save provenance information for the packages passed on the command line. Provenance information includes the URL and commit of the channels in use (see Channels), which permit the recipient to locate the source code of the package definitions that were used. Provenance information is saved in the /gnu/store/…-profile/manifest file in the pack, along with the usual package metadata—the name and version of each package, their propagated inputs, and so on. Note that inclusion of provenance information makes the resulting archive non-reproducible in the sense that two archives containing identical binaries can be different if they were built using different channels or different commits. Does this look better to you? Philosophical side note: the right way to store provenance information is outside of the data they refer to. Unfortunately, with file-based storage, there is no clean way to attach the provenance information securely to the data without putting it into the same file. Konrad.
Re: Why reproducibility is breaking by metadata?
Le 3 juillet 2019 06:05:02 GMT+02:00, zna...@disroot.org a écrit : >Hello, Guix Help! I am translating Guix manual and found that the >author is entirely given to reproducibility. It leads to such phrases >that metadata breaks reproducibility when he describes >'--save-provenance' flag of 'guix pack' command here: > >'This option is not enabled by default because, like timestamps, >provenance information contributes nothing to the build process. In >other words, there is an infinity of channel URLs and commit IDs that >can lead to the same pack. Recording such “silent” metadata in the >output thus potentially breaks the source-to-binary bitwise >reproducibility property. ' > >I did not expected such a categorical statement. I think, it does not >actually break reproducibility but only complicates checks. If we have >to talk about reproducibility to ignoramus, saying 'this option breaks >reproducibility option' have to have remark 'simply put' or 'plainly'. I think the key here is "bitwise": it breaks reproducibility in terms of the build results not having the same hash. Does it make sense?
