Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Amirouche Boubekki  writes:

>> The problem is all users
>> that are not GNU followers (and some GNU followers like me) who need a
>> modern browser.
>
> Out of curiosity, please let us know what you need from the "modern
> browser"?
>
> On my side, I need a debugger for doing web frontends.

I need to browse all javascript bloated newspapers.

>> We definitely don't want to frighten them with our
>> nostalgic ideas about how the web should be and how a browser should be.
>
> I don't want to be rude at all, especially with who has been nice to me.
> But following that kind of logic cannot always be a good way forward.

:-)  If I sounded rude, I sincerely apologize.  I used the word
'nostalgic' because I do feel nostalgic: I miss the time when the web
wasn't that complicated.  And I really think some users might refuse to
install GuixSD just because it lacks Firefox or Chromium, which would be
sad.

>> They just want a browser that works.  As long as it's free software,
>> let's not complicate things for them.
>
> I agree. I am wondering what that browser make it the browser they
> want.

'They' possibly want anything that the main browsers (Firefox, Chromium,
Edge, IE, Safari) provide because a lot of sites are built based on
these 'modern' features.

>> Otherwise we'll never grow.
>
> Sorry again to disagree. I don't think the future of guix is in the
> desktop.  It has been said that GNU/Linux will kill windows on the
> desktop for a decade.  It did not happen. Nowadays, people use their
> computer only to run a browser whatever the OS... Given that, It seems
> to defy the de facto definition of a modern OS not to provide a "good
> enough" web experience.

There are people who need GuixSD features *and* a 'modern' browser.  I
don't think the choice should be either the OS or the browser.  I
personally need both.  (But maybe I misunderstood your point?)

> Ok. I will try to help  with
>
> a) chromium

About that, my point was that the actual state is good enough to be
pushed.  I've seen in another email that you succeeded in building it.
Of course any work on the TODO list is very welcome :-)  But I think we
should push it before those improvements are done, given the urgency.

> b) investigate what people are expecting from a modern web browser

Again, I believe that we should package every feature that are provided
by Firefox and Chromium, as long as they are ethical, because I think at
some point some Guix users will need them.

> c) See whether qtwebkit is follows upstream security updates and test
> it to see if it's stable
> d) do the same with webkit-gtk

Thank you!

Clément

Re: Firefox 52's end of life, packaging Chromium

[Ricardo Wurmus]

Hi Clément,

> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).

I’m surprised to hear that you’ve had problems with Epiphany.  I’m using
it daily for dozens of tabs and I recommend it to people who cannot use
Icecat.  It’s difficult to send good bug reports when the browser
freezes the computer, of course, but it would be helpful to get more
information about these crashes, if you can reproduce them.

> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].

The TODO list for convenience:

--8<---cut here---start->8---
* There is still some data transmitted when starting the browser for the
  first time.  It seems related to the "domain_reliability" component.
* Remove remaining "Web Store" links.  Currently I've only found it in
  settings, under "accessibility" and "fonts".
* Opening settings transmits a bunch of data, the next version will
  include the 'disable-translation-lang-fetch' patch from Inox.
* PDFium is built, but does not seem to work (the 'install' phase
  probably needs tweaking).  Might just disable it instead.
--8<---cut here---end--->8---

It would be *very* nice if the first and third items could be solved
before merging, but I don’t consider them blockers.  Would someone like
to investigate one of these problems?

As has been stated multiple times in the discussion of this evolving
patch set, we cannot guarantee privacy, but we can make attempts to
remove problems as they become known.  This will remain an uphill battle
and in future iterations of this package we should try to integrate more
patches provided by other groups working on removing anti-features from
Chromium.

Thanks to Marius for driving the evolution of this patch set through
multiple upgrades and bringing it to a usable state!

My personal recommendation is to use Epiphany if possible (and Icecat
once version 60 is ready) and to be careful with Chromium.

--
Ricardo

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Hi Ricardo,

Thank you for your reply.

Ricardo Wurmus  writes:

> Hi Clément,
>
>> Firefox 52 isn't supported anymore upstream[1] and we don't have a
>> package for Firefox 60.  Currently the only alternative is Epiphany but
>> it's close to unusable (it crashes every 5 minutes, and sometimes
>> freezes my computer).
>
> I’m surprised to hear that you’ve had problems with Epiphany.  I’m using
> it daily for dozens of tabs and I recommend it to people who cannot use
> Icecat.  It’s difficult to send good bug reports when the browser
> freezes the computer, of course, but it would be helpful to get more
> information about these crashes, if you can reproduce them.

Sure, I'll report them when I find the time.

>> So the question is: can we push the Chromium package?  I've read it's
>> almost ready[2].
>
> The TODO list for convenience:
>
> --8<---cut here---start->8---
> * There is still some data transmitted when starting the browser for the
>   first time.  It seems related to the "domain_reliability" component.
> * Remove remaining "Web Store" links.  Currently I've only found it in
>   settings, under "accessibility" and "fonts".
> * Opening settings transmits a bunch of data, the next version will
>   include the 'disable-translation-lang-fetch' patch from Inox.
> * PDFium is built, but does not seem to work (the 'install' phase
>   probably needs tweaking).  Might just disable it instead.
> --8<---cut here---end--->8---
>
> It would be *very* nice if the first and third items could be solved
> before merging, but I don’t consider them blockers.

It's not clear to me :-)  Does it mean we can merge?

> As has been stated multiple times in the discussion of this evolving
> patch set, we cannot guarantee privacy, but we can make attempts to
> remove problems as they become known.  This will remain an uphill battle
> and in future iterations of this package we should try to integrate more
> patches provided by other groups working on removing anti-features from
> Chromium.
>
> Thanks to Marius for driving the evolution of this patch set through
> multiple upgrades and bringing it to a usable state!
>
> My personal recommendation is to use Epiphany if possible (and Icecat
> once version 60 is ready) and to be careful with Chromium.

Thank you for this important information.

Clément

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Mike Gerwitz transcribed 1.8K bytes:
> On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote:
> > Firefox 52 isn't supported anymore upstream[1] and we don't have a
> > package for Firefox 60.  Currently the only alternative is Epiphany but
> > it's close to unusable (it crashes every 5 minutes, and sometimes
> > freezes my computer).
> 
> This is a big problem.  Thanks for keeping up with the status.
> 
> I'll get into contact with the necessary people on behalf of GNU to
> figure out the current status of IceCat.
> 
> But as was stated in another thread, once we _do_ have an updated IceCat
> source distribution, we need it packaged for Guix, and that is quite the
> undertaking.  Has anyone pursued packaging modern versions of vanilla FF
> in recent months?

Yes, I have. The outcome was not so much progress because Firefox
starting at a certain version does no longer allow disabling the build
of the rust crates. You then need a way to deal with the "breakage" in
the directory 'thirdparty/rust/' and its subdirectories.
Progress could be achieved with a phase which either records our changes
to the checksum related files or reverts our changes.

> -- 
> Mike Gerwitz
> Free Software Hacker+Activist | GNU Maintainer & Volunteer
> GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
> https://mikegerwitz.com

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Nils Gillmann transcribed 1.3K bytes:
> Mike Gerwitz transcribed 1.8K bytes:
> > On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote:
> > > Firefox 52 isn't supported anymore upstream[1] and we don't have a
> > > package for Firefox 60.  Currently the only alternative is Epiphany but
> > > it's close to unusable (it crashes every 5 minutes, and sometimes
> > > freezes my computer).
> > 
> > This is a big problem.  Thanks for keeping up with the status.
> > 
> > I'll get into contact with the necessary people on behalf of GNU to
> > figure out the current status of IceCat.
> > 
> > But as was stated in another thread, once we _do_ have an updated IceCat
> > source distribution, we need it packaged for Guix, and that is quite the
> > undertaking.  Has anyone pursued packaging modern versions of vanilla FF
> > in recent months?
> 
> Yes, I have. The outcome was not so much progress because Firefox
> starting at a certain version does no longer allow disabling the build
> of the rust crates. You then need a way to deal with the "breakage" in
> the directory 'thirdparty/rust/' and its subdirectories.
> Progress could be achieved with a phase which either records our changes
> to the checksum related files or reverts our changes.

Addition: Aurora 52.7.2 is the last version I have packaged without
the mandatory rust.

> > -- 
> > Mike Gerwitz
> > Free Software Hacker+Activist | GNU Maintainer & Volunteer
> > GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
> > https://mikegerwitz.com
> 
> 
> 

Re: Guix on aarch64

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> The 'guix publish' TTL is a secondary issue, because, as you say, the
> NARs are only deleted if the corresponding store item has been GC'd.
> The more important question is: what is the policy for deleting GC roots
> on Berlin?

As I wrote, there’s no policy other than “make sure there’s at least N
GiB free.”

I think the ‘guix publish’ TTL is not a secondary issue if the question
is “what does it take for substitutes to remain available?”  GC roots
allow us to retain substitutes regardless of their popularity (so it’s
definitely useful for releases), while the TTL allow us to retain
popular substitutes.

I think I already wrote that I acknowledge the issues you raised and
that we should fix Cuirass to create GC roots for evaluations when we
ask it to.

Ricardo Wurmus  skribis:

> I think our use of Hydra is not sustainable.  It requires regular manual
> intervention by Mark, careful tuning of SQL queries, conscientious
> clean up of old substitutes, and we have not a single person familiar
> with the Perl code.
>
> We do have people working on Cuirass, though.  Let’s add important
> missing features to Cuirass instead of making efforts to keep Hydra on
> life support.

+1

To be clear, I want us to switch to berlin as the main official
substitute server in the coming weeks.  Emacs-build-farm and the web
interface are becoming pretty nice.  There _are_ missing features and
rough edges, but I’d like us to focus on addressing those.

The Cuirass web interface code is nice and pleasant to work with, so I
encourage everyone to take a look and add whatever they deem important!

  
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/http.scm
  
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/templates.scm

I also think it’s important to be able to react calmly and
constructively to issues like the one Benjamin reported.  It’s not a
minor issue, but if we want to be address it in good conditions, we have
to keep cool and focus on concrete incremental steps we can take to
address it, while also keeping in mind our longer-term goals.

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hi,

Clément Lassieur  skribis:

> The problem is a technical problem.  We would have with Icecat 60 the
> same packaging difficulties we have with Firefox 60.  Whether we choose
> Icecat or Firefox is unrelated.

That means pulling a number of Rust dependencies, is that right?

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hello,

Clément Lassieur  skribis:

> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].  It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?

As long as the freedom issues and phone-home issues are addressed, which
appears to be the case, I’m all for it.

Marius?

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Ludovic Courtès transcribed 331 bytes:
> Hi,
> 
> Clément Lassieur  skribis:
> 
> > The problem is a technical problem.  We would have with Icecat 60 the
> > same packaging difficulties we have with Firefox 60.  Whether we choose
> > Icecat or Firefox is unrelated.
> 
> That means pulling a number of Rust dependencies, is that right?

No, they are bundled. Now rust itself is a problem on our side, so I
haven't even attempted to unbundle them.

> Thanks,
> Ludo’.
> 

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Ludovic Courtès  writes:

> Hi,
>
> Clément Lassieur  skribis:
>
>> The problem is a technical problem.  We would have with Icecat 60 the
>> same packaging difficulties we have with Firefox 60.  Whether we choose
>> Icecat or Firefox is unrelated.
>
> That means pulling a number of Rust dependencies, is that right?

Yes, if my understanding is correct.

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Nils Gillmann  writes:

> Ludovic Courtès transcribed 331 bytes:
>> Hi,
>> 
>> Clément Lassieur  skribis:
>> 
>> > The problem is a technical problem.  We would have with Icecat 60 the
>> > same packaging difficulties we have with Firefox 60.  Whether we choose
>> > Icecat or Firefox is unrelated.
>> 
>> That means pulling a number of Rust dependencies, is that right?
>
> No, they are bundled. Now rust itself is a problem on our side, so I
> haven't even attempted to unbundle them.

Oh right, ok.

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

> >> ** TODO “GuixSD” renamed to “Guix System”?
>
> Guix System is not good because "system" is a word that is too generic.
>
> What about "Guix OS"?
>
> >> ** TODO “Cuirass” renamed to “Guix CI”?
>
> OK

On the one hand, OS and CI are rather ubiquitous.

On the other hand, I've personally always been wary of excessive use of
abbreviations: newcomers will find documentation and communication cryptic,
while abbreviations proliferate, sometimes out of control.

But I don't think it's the case for Guix OS and even Apple went for "macOS" so I
guess "OS" is pretty safe (much more than "SD" at least).

Conversely, "Guix CI" is much less widespread, although I suppose many
developers are familiar with the term.  I personally prefer unique, easy names
to abbreviations.

- The name "Guix CI" tells developers what it is (continuous integration) while
  "Cuirass" does not.  This is mostly true, however, for almost all applications
  (mpv, firefox, chromium, emacs, ).

- If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
  will end up with a bunch Guix FS, Guix IP, Guix CD...

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Firefox 52's end of life, packaging Chromium

[Ricardo Wurmus]

Hi Clément,

>>> So the question is: can we push the Chromium package?  I've read it's
>>> almost ready[2].
>>
>> The TODO list for convenience:
>>
>> --8<---cut here---start->8---
>> * There is still some data transmitted when starting the browser for the
>>   first time.  It seems related to the "domain_reliability" component.
>> * Remove remaining "Web Store" links.  Currently I've only found it in
>>   settings, under "accessibility" and "fonts".
>> * Opening settings transmits a bunch of data, the next version will
>>   include the 'disable-translation-lang-fetch' patch from Inox.
>> * PDFium is built, but does not seem to work (the 'install' phase
>>   probably needs tweaking).  Might just disable it instead.
>> --8<---cut here---end--->8---
>>
>> It would be *very* nice if the first and third items could be solved
>> before merging, but I don’t consider them blockers.
>
> It's not clear to me :-)  Does it mean we can merge?

I’ll leave that up to Marius, because he is much more familiar with the
patch than I am.

I would not object to merging it, but I’d like to see these TODOs as
separate bug reports, with the first and third items at a higher
severity than “normal”.

--
Ricardo

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hello,

Pierre Neidhardt  skribis:

> Conversely, "Guix CI" is much less widespread, although I suppose many
> developers are familiar with the term.  I personally prefer unique, easy names
> to abbreviations.
>
> - The name "Guix CI" tells developers what it is (continuous integration) 
> while
>   "Cuirass" does not.  This is mostly true, however, for almost all 
> applications
>   (mpv, firefox, chromium, emacs, ).
>
> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>   will end up with a bunch Guix FS, Guix IP, Guix CD...

I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
is already the case, and when we need to disambiguate (for instance when
addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
using the Guix distro?”, and everything will be fine.  :-)

The motivation for this name change is that “SD” is obscure to most, as
you note, plus it creates confusion when people visit the web site: the
web site has a “GuixSD” logo, but then it talks about features of the
package manager.  Designating the whole tool set as “Guix” will simplify
this, and we can always be more specific when we need to.

For Cuirass, I think “Guix CI” (or “Guix Continuous”?) is good enough.
It remains a tool primarily for Guix developers anyway, and a secondary
tool in the Guix toolbox.

Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Nils Gillmann  skribis:

> Ludovic Courtès transcribed 331 bytes:
>> Hi,
>> 
>> Clément Lassieur  skribis:
>> 
>> > The problem is a technical problem.  We would have with Icecat 60 the
>> > same packaging difficulties we have with Firefox 60.  Whether we choose
>> > Icecat or Firefox is unrelated.
>> 
>> That means pulling a number of Rust dependencies, is that right?
>
> No, they are bundled.

OK.  Ideally we’d unbundle them but the point is moot since we probably
don’t have package for these currently.  IOW, I think we could keep
those bundled dependencies initially, and then incrementally unbundle
them as we add more Rust packages to our package collection.

> Now rust itself is a problem on our side, so I haven't even attempted
> to unbundle them.

Our Rust package is supposed to work fine thanks to the work of Nikolai,
Danny, and others, so I’m (naively?) confident.  :-)

Thanks,
Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hello Guix!

l...@gnu.org (Ludovic Courtès) skribis:

> Specifically there are two things we can implement:
>
>   1. A ‘guix run’ command along the lines of
>  .
>
>   2. A mechanism that would allow, say, ‘guix package -i PKG --pola’ to
>  automatically add “least-authority wrappers” around the binaries of
>  PKG, pretty much like ‘guix pack --relocatable’ does (see
>  ‘wrapped-package’ in (guix scripts pack)).

Speaking of which, a colleague of mine told me about Whalebrew
, which takes a somewhat similar
approach:

  Whalebrew creates aliases for Docker images so you can run them as if
  they were native commands. It's like Homebrew, but with Docker images.

  Docker works well for packaging up development environments, but there
  are lots of tools that aren't tied to a particular project: awscli for
  managing your AWS account, ffmpeg for converting video, wget for
  downloading files, and so on. Whalebrew makes those things work with
  Docker, too.

There’s this important difference:

  Packages are Docker images published on Docker Hub.

Ludo’.

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello,
>
> Pierre Neidhardt  skribis:
>
>> Conversely, "Guix CI" is much less widespread, although I suppose many
>> developers are familiar with the term.  I personally prefer unique, easy 
>> names
>> to abbreviations.
>>
>> - The name "Guix CI" tells developers what it is (continuous integration) 
>> while
>>   "Cuirass" does not.  This is mostly true, however, for almost all 
>> applications
>>   (mpv, firefox, chromium, emacs, ).
>>
>> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>>   will end up with a bunch Guix FS, Guix IP, Guix CD...
>
> I think “Guix System” is OK.

I think so too.

> Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)

Exactly.

I wrote this on IRC:

The name “GuixSD” is opaque and creates an arbitrary distinction between
the system running on bare metal and the systems you can create with the
“guix system” commands.  It makes it difficult to communicate about
Guix.  Do we really offer “a package manager” and a “distro” — or is it
really all one thing with various levels?

The “guix system” command can be used without GuixSD to create Guix
virtual machines or containers.  Describing “guix system” is difficult
when we think in terms of “package manager” vs “distro”.  Guix itself is
also a distro – none of the packages it provides link with the host
system, and the collection of packages is a distribution of free
software.

I think that simplifying the name by using “guix” as a category will
make communication easier.

> The motivation for this name change is that “SD” is obscure to most, as
> you note, plus it creates confusion when people visit the web site: the
> web site has a “GuixSD” logo, but then it talks about features of the
> package manager.  Designating the whole tool set as “Guix” will simplify
> this, and we can always be more specific when we need to.

I agree.

--
Ricardo

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Ludovic Courtès transcribed 990 bytes:
> Nils Gillmann  skribis:
> 
> > Ludovic Courtès transcribed 331 bytes:
> >> Hi,
> >> 
> >> Clément Lassieur  skribis:
> >> 
> >> > The problem is a technical problem.  We would have with Icecat 60 the
> >> > same packaging difficulties we have with Firefox 60.  Whether we choose
> >> > Icecat or Firefox is unrelated.
> >> 
> >> That means pulling a number of Rust dependencies, is that right?
> >
> > No, they are bundled.
> 
> OK.  Ideally we’d unbundle them but the point is moot since we probably
> don’t have package for these currently.  IOW, I think we could keep
> those bundled dependencies initially, and then incrementally unbundle
> them as we add more Rust packages to our package collection.
> 
> > Now rust itself is a problem on our side, so I haven't even attempted
> > to unbundle them.
> 
> Our Rust package is supposed to work fine thanks to the work of Nikolai,
> Danny, and others, so I’m (naively?) confident.  :-)

Rust alone yes, but rust crates beyond single package dependencies:
no.  At least I haven't seen a confirmation that all of the defects of
the build-system have been adressed in the last months (year).

> Thanks,
> Ludo’.
> 

Re: Roadmap for Guix 1.0

[Tobias Geerinckx-Rice]

Guix,

Ricardo Wurmus wrote:

Ludovic Courtès  writes:

I think “Guix System” is OK.


I think so too.


Big +1.

If you use 'guix system', you're using Guix System[0].

It doesn't get less confusing than that.

Kind regards,

T G-R

[0]: The only question left is 'on what?'. Everything, of course.

Re: Firefox 52's end of life, packaging Chromium

[Amin Bandali]

Ricardo Wurmus  writes:

>> So the question is: can we push the Chromium package?  I've read it's
>> almost ready[2].
>
> The TODO list for convenience:
>
> --8<---cut here---start->8---
> * There is still some data transmitted when starting the browser for the
>   first time.  It seems related to the "domain_reliability" component.
> * Remove remaining "Web Store" links.  Currently I've only found it in
>   settings, under "accessibility" and "fonts".
> * Opening settings transmits a bunch of data, the next version will
>   include the 'disable-translation-lang-fetch' patch from Inox.
> * PDFium is built, but does not seem to work (the 'install' phase
>   probably needs tweaking).  Might just disable it instead.
> --8<---cut here---end--->8---
>
> It would be *very* nice if the first and third items could be solved
> before merging, but I don’t consider them blockers.  Would someone like
> to investigate one of these problems?
>
> As has been stated multiple times in the discussion of this evolving
> patch set, we cannot guarantee privacy, but we can make attempts to
> remove problems as they become known.  This will remain an uphill battle
> and in future iterations of this package we should try to integrate more
> patches provided by other groups working on removing anti-features from
> Chromium.

I highly recommend looking into ungoogled-chromium [0], which
"modifies Google Chromium to remove Google integration and
enhance privacy, control, and transparency".  It's not exactly a
fork, but rather a series of patches and modifications they apply
to each Chromium release.

In terms of documentation, they have a high-level description of
the various components and patches [1], and build instructions
for a few platforms and distros [2].  There was also an attempt
to make a nix package a while ago [3], which may be helpful to
look at.

[0]: https://github.com/Eloston/ungoogled-chromium
[1]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md
[2]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md
[3]: https://github.com/NixOS/nixpkgs/pull/30916

-- 
Amin Bandali  |  GNU webmaster  | Grad student, UWaterloo
https://aminb.org | https://gnu.org |https://aminb.org/uw
GnuPG Key: CDDE 75F9 0353 8E71 813C  DA27 D1FB A366 27D6 5876

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Tobias Geerinckx-Rice transcribed 340 bytes:
> Guix,
> 
> Ricardo Wurmus wrote:
> > Ludovic Courtès  writes:
> > > I think “Guix System” is OK.
> > 
> > I think so too.
> 
> Big +1.
> 
> If you use 'guix system', you're using Guix System[0].
> 
> It doesn't get less confusing than that.
> 
> Kind regards,
> 
> T G-R
> 
> [0]: The only question left is 'on what?'. Everything, of course.
> 

Sounds good for me too.

Re: Roadmap for Guix 1.0

[George Clemmer]

Hi,

Ludovic Courtès  writes:

> Hello,
>
> Pierre Neidhardt  skribis:
>
>> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>>   will end up with a bunch Guix FS, Guix IP, Guix CD...
>
> I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)
>
> The motivation for this name change is that “SD” is obscure to most, as
> you note, plus it creates confusion when people visit the web site: the
> web site has a “GuixSD” logo, but then it talks about features of the
> package manager.  Designating the whole tool set as “Guix” will simplify
> this, and we can always be more specific when we need to.

This is good because it declutters the Guix-Verse for new users.

I suggest that the distinction between GuixOS, package manager, QEMU
image, and source can be re-positioned as download options.

We could simplify the choice of these by improving the download
page. For example ...

1) We could simplify the download labels/descriptions, e.g.,

   "GuixSD 0.15.0 QEMU Image QCOW2 virtual machine (VM) image. Download
   options: x86_64"

   ... might become ...

   "x86_64 VM (GuixSD 0.15.0 QEMU Image QCOW2 virtual machine image)"

2) We could add a feature check list that helps with download selection.

With such changes the support question is: what did you download?

IMO it would be desirable to pick a single term for each download option
and use it obsessively throughout the site and doc. This small thing can
be quite helpful to a noob because it eliminates any confusion that
might be caused by multiple terms meaning the same thing. So, IMO we
should settle on only one of Guix System, GuixSD, GuixOS, or maybe "Guix
bare metal".

- George

Re: Firefox 52's end of life, packaging Chromium

[Mike Gerwitz]

On Thu, Aug 30, 2018 at 09:07:39 +, Nils Gillmann wrote:
> Mike Gerwitz transcribed 1.8K bytes:
>> But as was stated in another thread, once we _do_ have an updated IceCat
>> source distribution, we need it packaged for Guix, and that is quite the
>> undertaking.  Has anyone pursued packaging modern versions of vanilla FF
>> in recent months?
>
> Yes, I have. The outcome was not so much progress because Firefox
> starting at a certain version does no longer allow disabling the build
> of the rust crates. You then need a way to deal with the "breakage" in
> the directory 'thirdparty/rust/' and its subdirectories.
> Progress could be achieved with a phase which either records our changes
> to the checksum related files or reverts our changes.

Thank you for your efforts!

-- 
Mike Gerwitz


signature.asc
Description: PGP signature

Re: Firefox 52's end of life, packaging Chromium

[Mike Gerwitz]

On Thu, Aug 30, 2018 at 07:14:37 +0200, Clément Lassieur wrote:
> The problem is a technical problem.  We would have with Icecat 60 the
> same packaging difficulties we have with Firefox 60.  Whether we choose
> Icecat or Firefox is unrelated.

Right, which is why I was curious if there were recent efforts with
vanilla Firefox, since those efforts would directly apply to IceCat.

-- 
Mike Gerwitz


signature.asc
Description: PGP signature

Re: Roadmap for Guix 1.0

[Hartmut Goebel]

Am 30.08.2018 um 14:04 schrieb Ludovic Courtès:
> “Guix Continuous”

For me this sounds like a fail-save system which will continue running,
and running, and running.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Roadmap for Guix 1.0

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)

Yes, I found that "SD" is often more confusing than not.

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: FOSDEM 2019

[Pjotr Prins]

Just to clarify, we will organize a two day Guix conference before
FOSDEM. That is pretty much in the box. We have room at ICAB, the place
we were last year. 

  http://icab.be/

In addition to the Guix conference there is the possibility to have a
dev-room at FOSDEM, but we need to apply for it. If the interest is as
underwhelming as it is now I think we better forget about it. These
things take effort to organize.

I think the 'minimalistic languages for big ideas' room has appeal to
a wider audience and some of our projects fit really well. Anyone
any project ideas? Or do we just forget about it? How about:

- Guile Guix build farm and Cuirass
- Sheperd (Guile)

Everyone, please think with us.

Pj.

On Mon, Aug 27, 2018 at 11:23:19AM +0200, Pjotr Prins wrote:
> * Minimalistic Languages 
> 
> Every year FOSDEM allows for dev-rooms that need to appeal to a wider
> audience and do not overlap with other dev-rooms. Programming
> languages are popular and some of the large languages get their own,
> such as Python and Rust. See the devrooms section on
> 
>   https://archive.fosdem.org/2018/schedule/
> 
> Manolis and I want to submit a plan for 'Minimalistic Languages - for
> big ideas' dev-room.  Good examples that fit the room are 
> 
> - mes and reproducible builds
> - Guile and Guix
> - Guile JIT
> - Lua JIT
> - Lua for scriptable projects (example?)
> 
> Anyone anything to add to this list? More ideas is better.
> 
> Other languages that could fit are Forth, Smalltalk, Tcl, Rebol.
> Provided they have a big idea.
> 
> Note that JVM languages and languages that compile to Javascript do
> not fit the room. They probably have their own dev-rooms anyway.
> Haskell and other Lisps may fit too (if they don't get their own
> room). We think with enough good projects our dev-room will be of
> interest.
> 
> Pj & Manolis
> 
> 
> 

Re: Roadmap for Guix 1.0

[George Clemmer]

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>
>> Hello,
>>
>> I think “Guix System” is OK.
>
> I think so too.

I recommend against renaming GuixSD >> "Guix System". Here is Why:

1) A noob would expect "guix system" to refer to the whole Guix
enchilada. If we use it to refer to GuixSD, a specific Guix deployment
mode, we have created a new, counter-intuitive thing we have to explain.

2) As Ricardo points out below, the "guix system" command clashes with
this use of Guix system. This is a second counter-intuitive thing we
would have to explain.

Bottom line: we shouln'd use the general term "Guix System" in any way
beyond, perhaps in a descriptway way, e.g., The Guix project develops
the Guix System, a set of tools that manage software environments.

>> Most of the time we’ll just say “Guix”, as
>> is already the case, and when we need to disambiguate (for instance when
>> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
>> using the Guix distro?”, and everything will be fine.  :-)
>
> Exactly.
>
> I wrote this on IRC:
>
> The name “GuixSD” is opaque and creates an arbitrary distinction between
> the system running on bare metal and the systems you can create with the
> “guix system” commands.  It makes it difficult to communicate about
> Guix.  Do we really offer “a package manager” and a “distro” — or is it
> really all one thing with various levels?
>
> The “guix system” command can be used without GuixSD to create Guix
> virtual machines or containers.  Describing “guix system” is difficult
> when we think in terms of “package manager” vs “distro”.  Guix itself is
> also a distro – none of the packages it provides link with the host
> system, and the collection of packages is a distribution of free
> software.
>
> I think that simplifying the name by using “guix” as a category will
> make communication easier.
>
>> The motivation for this name change is that “SD” is obscure to most, as
>> you note, plus it creates confusion when people visit the web site: the
>> web site has a “GuixSD” logo, but then it talks about features of the
>> package manager.  Designating the whole tool set as “Guix” will simplify
>> this, and we can always be more specific when we need to.
>
> I agree.

I agree too. You may recall that I recommendi this approach when we
discussed the web site in January. That thread includes a product
description [1] that might be a good place to start when describing the
"whole tool set".

[1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html

Re: FOSDEM 2019

[Amirouche Boubekki]

On 2018-08-30 20:20, Pjotr Prins wrote:

Just to clarify, we will organize a two day Guix conference before
FOSDEM. That is pretty much in the box. We have room at ICAB, the place
we were last year.

  http://icab.be/


About the specifically guix event, maybe it's a good time to organize
an install party. Also, let's be clear upfront if that the fringe event
can include those kind of work: poster, workshop, tutorial... anything
else to add?


In addition to the Guix conference there is the possibility to have a
dev-room at FOSDEM, but we need to apply for it. If the interest is as
underwhelming as it is now I think we better forget about it. These
things take effort to organize.

I think the 'minimalistic languages for big ideas' room has appeal to
a wider audience and some of our projects fit really well. Anyone
any project ideas? Or do we just forget about it? How about:

- Guile Guix build farm and Cuirass
- Sheperd (Guile)



Yes!

I posted previously a message on various Scheme related bulletin
boards, with not many responses except in Racket Group [0] that boils
down to "maybe we should do something".

[0] https://groups.google.com/forum/#!topic/racket-users/MehPv0ugBI4

I created a page at http://community.schemewiki.org/?FOSDEM2019

Like I wrote previously I was thinking out loud when I emailed 
guile-user

about a scheme dev room, with the hope more people would answer the call
but it did not happen.

What about the following names for the room:

- big fringe ideas
- define
- dev off
- off tracks

This names or others might allow even more developers (whatever that 
means...)
to join the event from a broad horizon. Let's remember the event is Free 
and

Open source Software Developers' European Meeting.

European make me think that about art, culture and history.

So this makes me think that it's about free. Art can be free. You feel 
free to dev

an art form like mezangelle / code poetry / executable poetry.

European is not the USA nor Asia maybe there is something interesting to 
find
to make it interesting for people from Europe and abroad to come to 
FOSDEM.

What about social / ethno / anthroposcene?

Well, I speak a lot about art. That's the way I think of coding. It's a 
way
(albeit new) to express oneself. It's a form of art and also a way to 
empower

others to create art and communicate. code imo is about communication.

What do other people think about the name that room must be?

I believe the schemewiki.org is more convenient because registration
is not required.

Another thing I'd like to stress, is that last year most talks I read 
about
were driven by big companies and stuff. And all the counter developer 
culture
was spread in various rooms. Let's make a room for alternatives maybe? 
No so big

communities that have a lot of potential or might just be moon shots.

I have a book called 'Open Space Technology' it's about organizing
meetings and events. I will read skim over it tonight. And (try) provide
feedback about the latest advancement in psychohistory engineering.

I hope to read some of your ideas.


Here is another one: #zehefyu93 undo s:/3nce 4 a peacefu/ prosperity.

Just to come back on the righteous track, maybe one can invite speakers.

Let's get inspiration from racketcon 2018 and 2017 or clojureconj or 
whatever..


stop brainwashing,
start brainstorming,
and have fun.

One has 6 months to prepare.

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Hi Chris,

> I'm not advocating that we change anything; I'm only advocating that we
> should make our stability promise (if any) clear by documenting it.  If
> you want to know my thoughts about what sort of stability promise we
> should provide, I'd be happy to talk about that also, but here I'm only
> saying that we should provide a promise.  The details of the promise are
> less important.
>
> If you agree, then perhaps we can proceed along the following lines:
>
> 1) Discuss what our stability promise should be.  It might be that we
>decide to simply stick with the status quo and document it.  But
>whatever the result, it should be something that hopefully everyone
>agrees on (especially maintainers and contributors).
>
> 2) Document it.  Put it on the website, in the manual, etc.
>
> 3) Follow it.  Mention it in the Contributing section of the manual, the
>README, etc., and require people to adhere to it when making changes.
>
> As a maintainer, what do you think?  Does it makes sense for the Guix
> project to set expectations by documenting our stability promise?

This is difficult.  The version jump signalizes that Guix is ready for
“productive” use; it really merely adjusts the version number in
accordance with how the community has been using Guix.

I’d be wary of putting something more than that in writing.  1.0 means
“this works pretty well” and “you shouldn’t expect sudden large changes
to how this works”.

I’d like to leave the discussion of a stability promise to a time when
we decide to maintain a “stable” branch.  The other kind of stability
applies only to using Guix as a library, which I don’t think is a very
popular use outside of Guix itself.

--
Ricardo

Re: Roadmap for Guix 1.0

[Taylan Kammer]

Pierre Neidhardt  writes:

> - The name "Guix CI" tells developers what it is (continuous integration) 
> while
>   "Cuirass" does not.  This is mostly true, however, for almost all 
> applications
>   (mpv, firefox, chromium, emacs, ).

Just an anecdote: I didn't know what Cuirass was until I read this
thread, though I saw the name many times. :-)

Taylan

Re: Haskel LTS 12.8.

[Timothy Sample]

Hi Again,

Timothy Sample  writes:

> Hello,
>
> Ricardo Wurmus  writes:
>
>> Hi Tim,
>>
>>> To avoid duplicating work, I wanted to let you know that I am working on
>>> updating the Haskell packages to their LTS 12.8 versions.  This will go
>>> nicely with the new GHC 8.4.3.
>>
>> Excellent!  I have a couple of new package definitions and a few minor
>> updates that I wanted to push to the master branch tomorrow.  (These
>> updates work fine with with GHC 8.0.x AFAICT, but I haven’t subjected
>> them to much testing.)
>
> There’s an issue with the new GHC.  The “--allow-newer=…” flags no
> longer work.  I can’t find any info on the Web or in any changelog.  It
> seems that nobody uses “runhaskell Setup.hs …” except for us.  Right
> now, I am working around this clumsily to avoid stalling (I am just
> patching the Cabal files).  It ought to be fixed before everything gets
> merged, though.  The best idea I’ve had so far is to update the build
> system to use the “cabal” command.  Hopefully I can find something
> simpler, though.

The change is here: , and it
is mentioned nicely in the Cabal changelog:

* Removed unused `--allow-newer`/`--allow-older` support from
  `Setup configure` (#4527).

If we use the “cabal” command like I proposed above, we need the
“cabal-install” package which is built with (wait for it) Cabal.  We
could add an argument like “#:cabal-install?” which when false would
cause the build system to use “runhaskell Setup.hs”.  This would let us
bootstrap “cabal-install”, but we would need to use it for every package
that “cabal-install” depends on, which is a pretty substantial set.
(This also means that all of those packages could not use
“--allow-newer”.)  I find this pretty clunky.

I’m starting to think that patching the Cabal files is not so bad after
all.  The main reason we change dependency constraints so often with
Hackage packages is because we do not use the latest constraints from
upstream.  Hackage has a Cabal file revision system separate from the
release tarballs, and it is used liberally by the Haskell community.
(In fact, it seems to cause developers to be very conservative with
their constraints, because they know they can be revised easily if
needed.)  Because we only ever see the unrevised constraints, we use
“--allow-newer” often to keep up.

If we could modify the build system or add a new downloader to use these
revisions, we would only rarely need to change the Cabal file dependency
constraints, and it would make doing it via patches much less
burdensome.

Another idea is to add an “#:allow-newer” argument to the build system,
and either use a clever regex or the Cabal parser to patch the files
automatically.

Thoughts?

>>> I am keeping the work on a WIP branch that I have here:
>>> .  All the updates
>>> have commits, but there is still a lot of testing to do and build issues
>>> to resolve.  I will keep you posted.
>>
>> Shall we push that to a wip-haskell branch in the Guix repository on
>> Savannah instead?  Then we could more easily let ci.guix.info build out
>> the branch.
>
> Yes!  This is a great idea.  However, maybe it’s best for a little later
> (tomorrow or the next day).  Right now, I am fixing more than my
> computer is building.  :)
>
>> --
>> Ricardo
>
>
> -- Tim

Re: Roadmap for Guix 1.0

[Gábor Boskovits]

George Clemmer  ezt írta (időpont: 2018. aug. 30., Cs,
21:14):

>
> Ricardo Wurmus  writes:
>
> > Ludovic Courtès  writes:
> >
> >> Hello,
> >>
> >> I think “Guix System” is OK.
> >
> > I think so too.
>
> I recommend against renaming GuixSD >> "Guix System". Here is Why:
>
> 1) A noob would expect "guix system" to refer to the whole Guix
> enchilada. If we use it to refer to GuixSD, a specific Guix deployment
> mode, we have created a new, counter-intuitive thing we have to explain.
>
> 2) As Ricardo points out below, the "guix system" command clashes with
> this use of Guix system. This is a second counter-intuitive thing we
> would have to explain.
>
> Bottom line: we shouln'd use the general term "Guix System" in any way
> beyond, perhaps in a descriptway way, e.g., The Guix project develops
> the Guix System, a set of tools that manage software environments.
>
> >> Most of the time we’ll just say “Guix”, as
> >> is already the case, and when we need to disambiguate (for instance when
> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> >> using the Guix distro?”, and everything will be fine.  :-)
> >
> > Exactly.
> >
> > I wrote this on IRC:
> >
> > The name “GuixSD” is opaque and creates an arbitrary distinction between
> > the system running on bare metal and the systems you can create with the
> > “guix system” commands.  It makes it difficult to communicate about
> > Guix.  Do we really offer “a package manager” and a “distro” — or is it
> > really all one thing with various levels?
> >
> > The “guix system” command can be used without GuixSD to create Guix
> > virtual machines or containers.  Describing “guix system” is difficult
> > when we think in terms of “package manager” vs “distro”.  Guix itself is
> > also a distro – none of the packages it provides link with the host
> > system, and the collection of packages is a distribution of free
> > software.
> >
> > I think that simplifying the name by using “guix” as a category will
> > make communication easier.
> >
> >> The motivation for this name change is that “SD” is obscure to most, as
> >> you note, plus it creates confusion when people visit the web site: the
> >> web site has a “GuixSD” logo, but then it talks about features of the
> >> package manager.  Designating the whole tool set as “Guix” will simplify
> >> this, and we can always be more specific when we need to.
> >
> > I agree.
>
> I agree too. You may recall that I recommendi this approach when we
> discussed the web site in January. That thread includes a product
> description [1] that might be a good place to start when describing the
> "whole tool set".
>
> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html
>
> What do you think about  GuixSD >> "Guix Distribution"? This naming seems
to resolve the ambiguities mentioned so far, and has a widespread
use, that exactly matches the intended meaning. WDYT?

Re: Guix on aarch64

[Ricardo Wurmus]

Hi Joshua,

>> I agree.  We need volunteers to pick a particular configuration (my
>> suggestion is to start with an Overdrive 3000 rack server[1]) and find a
>> place to host these servers.  We have not been successful in delegating
>> this to other people and unfortunately the maintainers cannot take care
>> of this themselves.
>>
>> [1]: https://shop.softiron.com/product/overdrive-3000/
>
> Just out of curiosity, would that server run libreboot?

No, this is an ARM server.

-- 
Ricardo

Re: FOSDEM 2019

[Amirouche Boubekki]

On 2018-08-30 21:38, Amirouche Boubekki wrote:

Open Space Technology (OST) is a method for organizing and running a 
meeting or multi-day conference, where participants have been invited in 
order to focus on a specific, important task or purpose. OST is a 
participant-driven process whose agenda is created by people attending. 
At the end of each OST meeting, a document is created summarizing the 
work of the group.


I already participated in such event as part of software craftman paris 
meetup and django cong 2012




I have a book called 'Open Space Technology' it's about organizing
meetings and events. I will read skim over it tonight. And (try) 
provide

feedback about the latest advancement in psychohistory engineering.



That book has a wikipedia page : 
https://en.wikipedia.org/wiki/Open_Space_Technology