Re: [Guix Website] A Search Page for Packages

2020-07-13 Thread Marius Bakke
Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Heya Danjela,
>>
>> Daniela Lura  skribis:
>>
>>> Taking into consideration the suggestion made in this thread:
>>> https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00096.html, my
>>> mentor, Christopher Baines suggested me to write a script that serves a
>>> search page for packages using the search functionality within the Guix
>>> Data Service,
>>> https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages?search_query=git=version=synopsis_name=_results=100
>>> .
>>>
>>> The prototype page can be accessed through a test version of the Guix
>>> website that Chris deployed:
>>> http://guix-website-test.cbaines.net/packages/search
>>
>> Cool!  To be clear, guix-website-test actually makes a search query on a
>> Data Service instance, right?  I guess that explains part of the
>> slowness, but maybe we could tweak nginx to keep search results in cache
>> for a few hours.
>>
>> Florian raised an important issue regarding the possibility of denial of
>> service.  Ideas on how to mitigate that, either in the Data Service, or
>> nginx at guix.gnu.org?
>
> On this point specifically, I've used the rate limiting functionality in
> NGinx before, and that's probably a low cost approach to guarding
> against this. It's not going to stop a DDOS, but might help avoid lots
> of requests from one IP address causing load issues.

We also have Varnish, a web caching proxy that excels at tasks like
this, and is used by some CDNs such as Fastly.  I'm happy to help write
a configuration if that is desired.


signature.asc
Description: PGP signature


Re: How to package inputrc

2020-07-13 Thread Marius Bakke
Efraim Flashner  writes:

> On Mon, Jul 13, 2020 at 09:30:31PM +0300, Efraim Flashner wrote:
>> On Mon, Jul 13, 2020 at 11:26:59AM -0600, Jesse Gibbons wrote:
>> > > In order to achieve this more elegant I could write a simple service to
>> > > copy the file to /etc. Another option would be a small package.
>> > 
>> > I like the service idea a lot better. It appears to me that Guix is 
>> > designed for services to deal with the more customizable parts of the 
>> > installation, whereas packages are standard. /etc/inputrc is one of those 
>> > things each system admin would want to customize, just like most of the 
>> > things in /etc.
>> 
>> I'll go ahead and link to my os-release service here. It's a small
>> service that creates an /etc/os-release file. The service in action¹ and
>> the actual service itself. It would also be possible to create an even
>> simpler file than the one I made here², with something like this:
>> 
>> (define %inputrc
>>   (plain-file "inputrc"
>>   "set show-mode-in-prompt on\n"
>>   "set enable-bracketed-paste on\n"
>>   "set editing-mode vi\n"
>>   "Control-l: clear-screen\n"
>>   "set bell-style visible\n"))
>
> The above wouldn't actually work. It needs a string-append or to not be
> multiple strings.

Or use 'mixed-text-file' instead of 'plain-file'.  Though 'string-join'
might be clearer in this case.  :-)


signature.asc
Description: PGP signature


Re: [Guix Website] A Search Page for Packages

2020-07-13 Thread Christopher Baines

Ludovic Courtès  writes:

> Heya Danjela,
>
> Daniela Lura  skribis:
>
>> Taking into consideration the suggestion made in this thread:
>> https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00096.html, my
>> mentor, Christopher Baines suggested me to write a script that serves a
>> search page for packages using the search functionality within the Guix
>> Data Service,
>> https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages?search_query=git=version=synopsis_name=_results=100
>> .
>>
>> The prototype page can be accessed through a test version of the Guix
>> website that Chris deployed:
>> http://guix-website-test.cbaines.net/packages/search
>
> Cool!  To be clear, guix-website-test actually makes a search query on a
> Data Service instance, right?  I guess that explains part of the
> slowness, but maybe we could tweak nginx to keep search results in cache
> for a few hours.
>
> Florian raised an important issue regarding the possibility of denial of
> service.  Ideas on how to mitigate that, either in the Data Service, or
> nginx at guix.gnu.org?

On this point specifically, I've used the rate limiting functionality in
NGinx before, and that's probably a low cost approach to guarding
against this. It's not going to stop a DDOS, but might help avoid lots
of requests from one IP address causing load issues.


signature.asc
Description: PGP signature


Re: How to package inputrc

2020-07-13 Thread Efraim Flashner
On Mon, Jul 13, 2020 at 09:30:31PM +0300, Efraim Flashner wrote:
> On Mon, Jul 13, 2020 at 11:26:59AM -0600, Jesse Gibbons wrote:
> > > In order to achieve this more elegant I could write a simple service to
> > > copy the file to /etc. Another option would be a small package.
> > 
> > I like the service idea a lot better. It appears to me that Guix is 
> > designed for services to deal with the more customizable parts of the 
> > installation, whereas packages are standard. /etc/inputrc is one of those 
> > things each system admin would want to customize, just like most of the 
> > things in /etc.
> 
> I'll go ahead and link to my os-release service here. It's a small
> service that creates an /etc/os-release file. The service in action¹ and
> the actual service itself. It would also be possible to create an even
> simpler file than the one I made here², with something like this:
> 
> (define %inputrc
>   (plain-file "inputrc"
>   "set show-mode-in-prompt on\n"
>   "set enable-bracketed-paste on\n"
>   "set editing-mode vi\n"
>   "Control-l: clear-screen\n"
>   "set bell-style visible\n"))

The above wouldn't actually work. It needs a string-append or to not be
multiple strings.


> ¹ https://gitlab.com/Efraim/guix-config/-/blob/master/E5400_config.scm#L68
> ² https://gitlab.com/Efraim/guix-config/-/blob/master/config/os-release.scm
> 
> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted



-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


Re: How to package inputrc

2020-07-13 Thread Efraim Flashner
On Mon, Jul 13, 2020 at 11:26:59AM -0600, Jesse Gibbons wrote:
> > In order to achieve this more elegant I could write a simple service to
> > copy the file to /etc. Another option would be a small package.
> 
> I like the service idea a lot better. It appears to me that Guix is designed 
> for services to deal with the more customizable parts of the installation, 
> whereas packages are standard. /etc/inputrc is one of those things each 
> system admin would want to customize, just like most of the things in /etc.

I'll go ahead and link to my os-release service here. It's a small
service that creates an /etc/os-release file. The service in action¹ and
the actual service itself. It would also be possible to create an even
simpler file than the one I made here², with something like this:

(define %inputrc
  (plain-file "inputrc"
  "set show-mode-in-prompt on\n"
  "set enable-bracketed-paste on\n"
  "set editing-mode vi\n"
  "Control-l: clear-screen\n"
  "set bell-style visible\n"))

¹ https://gitlab.com/Efraim/guix-config/-/blob/master/E5400_config.scm#L68
² https://gitlab.com/Efraim/guix-config/-/blob/master/config/os-release.scm

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


Re: How to package inputrc

2020-07-13 Thread Jesse Gibbons

In order to achieve this more elegant I could write a simple service to
copy the file to /etc. Another option would be a small package.


I like the service idea a lot better. It appears to me that Guix is designed 
for services to deal with the more customizable parts of the installation, 
whereas packages are standard. /etc/inputrc is one of those things each system 
admin would want to customize, just like most of the things in /etc.




Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull

2020-07-13 Thread Ekaitz Zarraga
Hi,

On Monday, July 13, 2020 4:21 PM, Ludovic Courtès  wrote:
> Unfortunately I haven’t dug further. Help welcome!
>
> Thanks,
> Ludo’.

I'd like to help but I don't know where to start (yet).
I've found the same issue in older gcc-toolchains. 9.3.0 and 8.4.0 also fail.

Many functions are affected, strtol, stoi... all have the same issue.

Looks _GLIBCXX_USE_C99_STDLIB is not set as you said so it fails to make any of 
these conversions from std::string.

Do you know any gcc version where this works?

Thanks



Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull

2020-07-13 Thread Ludovic Courtès
Hi Erik,

Erik Garrison  skribis:

> Thanks for reproducing this. Did you take a look at a resolution beyond
> your analysis in this message? It would seem that the attempted compilation
> isn't working during the configure phase.

Unfortunately I haven’t dug further.  Help welcome!

Thanks,
Ludo’.



New Guix-Science mailing list!

2020-07-13 Thread Ludovic Courtès
Howdy!

"simon tournier"  skribis:

> This new post presents the work we did during the Reproducible Research
> hackathon day, the past week.  Thanks to everyone for joining! I hope
> it was an enjoying experience.
>
>   
> https://hpc.guix.info/blog/2020/07/reproducible-research-hackathon-experience-report/
>
> Let replicate soon this experiment. :-)

Yup, it was a pleasant and productive experience!

One of the things we discussed as a followup was the creation of a
proper mailing list (guix-...@gnu.org is just an alias, which was fine
when there was just a handful of people but doesn’t scale well…).

So… drum roll… here’s a new Guix-Science mailing list!

  https://lists.gnu.org/mailman/listinfo/guix-science

We can use it to discuss use cases for reproducible research, HPC, and
all that.  Broader discussions should still go to help-guix and
guix-devel.

As for other project communication channels, guix-science members are
subject to the code of conduct:

  https://git.savannah.gnu.org/cgit/guix.git/tree/CODE-OF-CONDUCT

I’ve shared the mailing list admin password with Ricardo and Tobias, but
if someone wants to fill that role, please let us know!

Ludo’.


signature.asc
Description: PGP signature


Re: [Guix Website] A Search Page for Packages

2020-07-13 Thread Ludovic Courtès
Heya Danjela,

Daniela Lura  skribis:

> Taking into consideration the suggestion made in this thread:
> https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00096.html, my
> mentor, Christopher Baines suggested me to write a script that serves a
> search page for packages using the search functionality within the Guix
> Data Service,
> https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages?search_query=git=version=synopsis_name=_results=100
> .
>
> The prototype page can be accessed through a test version of the Guix
> website that Chris deployed:
> http://guix-website-test.cbaines.net/packages/search

Cool!  To be clear, guix-website-test actually makes a search query on a
Data Service instance, right?  I guess that explains part of the
slowness, but maybe we could tweak nginx to keep search results in cache
for a few hours.

Florian raised an important issue regarding the possibility of denial of
service.  Ideas on how to mitigate that, either in the Data Service, or
nginx at guix.gnu.org?

> I'd like to know if you find the page useful so that I can hopefully start
> working on incorporating the search functionality into this page:
> https://guix.gnu.org/packages/.

I’d be happy to see that happen!  We would need the changes against
guix-artwork.git as well as (maybe) changes to the nginx config in
maintenance.git.  How should we proceed?

Thanks!

Ludo’.



Re: [Guix Website] A Search Page for Packages

2020-07-13 Thread Ludovic Courtès
Hello,

YP  skribis:

> I always wondering why it was not integrated on guix.gnu.org, but this
> functionality is already available at https://hpc.guix.info/browse and
> seems to have many functionalities asked in comments :)

As discussed in the thread Danjela mentioned, the search feature at
hpc.guix.info requires JavaScript, and that’s the main reason why it’s
not available on guix.gnu.org: we wanted to have a JS-free option, or at
least “progressive enhancement” (JS-free for those who want it, and
JS-heavy for others).

Ludo’.



Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

2020-07-13 Thread Raghav Gururajan
Hey Ludo!

> Great job on all these packages, and great review by Danny, too!

Thank you!

> Danny, what’s your plan wrt. merging ‘wip-desktop’ in ‘master’ or
> ‘staging’?  It looks like there are loads of good stuff in there.

Btw, I initially planned to work on four DEs, but practically only one
was feasible. I am planning to finish-up gnome at the end of this month.
So starting August, I could start testing the wip-desktop branch
as-a-whole, in a VM and then work with Danny to merge it to master.

Regards,
RG.




signature.asc
Description: OpenPGP digital signature


Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

2020-07-13 Thread Ludovic Courtès
Hey Raghav,

Great job on all these packages, and great review by Danny, too!

Danny, what’s your plan wrt. merging ‘wip-desktop’ in ‘master’ or
‘staging’?  It looks like there are loads of good stuff in there.

Thanks,
Ludo’.



Re: Reproducible Research Hackathon: Friday, July 3rd

2020-07-13 Thread Ludovic Courtès
Hi Konrad,

Konrad Hinsen  skribis:

> There is an interesting issue left for me to explore, which is why
> Python 2.4 compiled with today's gcc has a bug that it definitely didn't
> have back then. It's probably related to the many intentional
> ambiguities in the C language standard, check out John Regehr's blog
> (https://blog.regehr.org/) for interesting examples. That could become a
> selling point for Guix because we have the option of compiling old
> software with old compilers, which is hard with other infrastructures.

Apologies for the delay.  What was this bug exactly?

I know Bonface addressed an issue related to how the Python 2.4 build
system would capture the kernel version via ‘uname’ a build time:

  
https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7

But presumably you’re referring to something else, right?

Thanks,
Ludo’.



Re: Internationalization Support for the Guix Data Service Outreachy Project

2020-07-13 Thread Ludovic Courtès
Hi Danjela,

I’m late to the party (as always when it comes to email :-)) but here’s
some feedback!

Daniela Lura  skribis:

> I'm following up to give an update on how the "Improve Internationalization
> Support for Guix Data Service" Outreachy project has been going.
> Translated versions of lint checkers and package synopsis and descriptions
> are now present in the database and they're also available through the Guix
> Data Service web interface.
> They can be accessed in these pages:
> Lint Warnings:
> -
> https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/lint-warnings

Nice!  Did you consider honoring the language HTTP headers of the client
to default to the user-chosen language?

[...]

> The availability of translated packages synopsis and descriptions for each
> locale can be found here:
> https://data.guix.gnu.org/revision/054153b28cea697d0439127ffdea4aadfd5c2e0a/packages-translation-availability

That’s really cool!  Well it also shows just how much translation work
is left.  ;-)

Is there a version of this URL pointing to the latest revision?  We
could link to it from the “Contributing” page of the web site.

> Here you can find an outline of the project:
> https://github.com/spf50/data-service/projects/1

Very nice to see you were able to go through all these items.

Thumbs up on the design and implementation of all these things!

Ludo’.