Re: Commit Access

[Amin Bandali]

Hello,

Leo Prikler writes:

> Hello everyone,
>
> earlier today, I was granted commit access to the repository [1].
[...]

Welcome, Leo!


signature.asc
Description: PGP signature

Re: Signing emails with mu4e (was Re: Hello, new committer here!)

[Amin Bandali]

Pierre Neidhardt writes:

> This is what I do to sign all my messages:
>
> (add-hook 'message-setup-hook 'mml-secure-sign-pgpmime)
>
[...]

A word of caution: at least with Gnus, doing something like this might
"downgrade" the security of a message, by changing it to only sign the
message you're composing when normally it would have been both signed
and encrypted.  It typically happens when replying to an encrypted
message.

For that reason, I set the message to be signed only when it's not being
signed+encrypted:

(add-hook 'gnus-message-setup-hook
  (lambda ()
(unless (mml-secure-is-encrypted-p)
  (mml-secure-message-sign

For non-Gnus users, I'd imagine replacing `gnus-message-setup-hook' with
`message-setup-hook' would work.


signature.asc
Description: PGP signature

Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.

[Amin Bandali]

Brett Gilio writes:

[...]
>
> Also, are we planning to keep emacs-next and have it track 28.x or
> remove it?
>
> Brett Gilio

I would like it if it's kept.  Though, if it is truly meant to track the
"next" release of Emacs, it should be pointed at the `emacs-27' branch,
as there will likely be one or more point releases in the 27 series.

On the other hand, as an Emacs developer, I would appreciate having a
package that tracks `master' that I could use.  Perhaps emacs-trunk
would be a more appropriate name for that package.  I know it's not
typical for guix.git to contain package definitions that point to
non-release commits; but perhaps Emacs could be an exception to that.

Thoughts?


signature.asc
Description: PGP signature

Re: Persian translation

[Amin Bandali]

Hi Ali Reza,

Ali Reza Hayati writes:

> Hey guys.
> I hope you all are well.
>
> I wanted to contribute to GNU and Guix but I'm not a programmer so I
> thought maybe I can translate Guix to Persian if it's needed. Can you
> guys help me to start? What should I do? Where should I start?
>
> I have a GNU Savannah account now. What's the next step?

Thanks for your interest and for volunteering to translate Guix into
Persian.  I'd be happy to help with translating and/or reviewing
yours/others' translations.

I believe the translation of Guix is done using the Translation Project,
consisting of the three "packages" guix [0], guix-manual [1], and
guix-packages [2] as of now.

[0]: 
[1]: 
[2]: 

We should probably start by emailing the "team lead" for the Persian
team  and ask to join the
team.  I don't think translating Guix requires a disclaimer, but you may
consider doing so anyway, if you may at some point in the future
contribute translations to other projects which require it.  It would
probably be a good idea to join the translation-team-fa mailing list as
well.

 contains general
instructions for translators.


signature.asc
Description: PGP signature

Re: 1.1.0rc1 available for test!

[Amin Bandali]

alex sassmannshausen  writes:

> Heya
>
> On Sat, 11 Apr 2020, 00:38 Ludovic Courtès,  wrote:
>
>> Hi Alex,
>>
>> Alex Sassmannshausen  skribis:
>>
>> > After successfully completing system setup from the ISO using that
>> > selection, rebooting the system launches GDM OK.  Signing in to GDM
>> > however causes the system to loop back to GDM, instead of starting a
>> > ratpoison session.  It is not clear to me what causes the issue, but I'm
>> > happy to help debug if someone can provide me with pointers on doing so.
>> >
>> > Intuitively, I would hazard a guess that the initialisation of ratpoison
>> > fails and the session is aborted, at which point GDM is restarted.
>>
>> Isn’t it just that GDM defaults to GNOME (not ratpoison), but since
>> GNOME isn’t available, it loops back?
>>
>> What if you click on the small gear and select ratpoison?
>>
>
> You are 100% correct! Thanks for that pointer - I hadn't considered it
> would still default to gnome! :)
>

Not sure if this was ever reported, but IMHO, that GDM defaults to a
(nonexistent) GNOME shell option by default even when e.g. Xfce is
installed rather than GNOME, is a bug.  I recall that for a default
installation, GDM would be correctly set to start Xfce by default, but
after the first upgrade and reboot, it would automatically be changed to
GNOME, which would obviously not work when trying to log in, and one
would have to set it back to Xfce once again.  I remember being puzzled
by this when it first occurred to me.

>
> Cheers,
>
> Alex
>
>
>
>> Thanks for your feedback!
>>
>> Ludo’.
>>


signature.asc
Description: PGP signature

Additional GPG key needed when verifying git-authenticate

[Amin Bandali]

Hello Guix,

I'll get right to the point: I goofed up earlier tonight, and pushed to
master a commit [0] modifying build-aux/git-authenticate.scm.  Since
we're all to sign our commits, as a result, in addition to Ludo’s key
you now need to add my GPG key to your keyring as well, before invoking
git-verify-commit on that file as shown in the manual.

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c2cf286c62933d2806ae17b8287520820bf87c7e

Backstory: as I myself had not yet started using git-authenticate, I had
not read the bit about it in the manual.  And it did not occur to me to
do a git-blame or git-log on the file before committing to it, in order
for me to notice that until that point only Ludo’ had committed to it.

Chatting with Ludo’ and others in #guix, it seems that it's not too far
fetched for committers to update their own keys and information in the
git-authenticate script, and I just happened to be the first person
walking into it. :-)

As such, the manual will be updated to clarify that keys other than
Ludo’s have been used to sign commits to build-aux/git-authenticate.scm,
and folks looking to verify and use the script need to fetch them from
the respective committers' Savannah profile in addition to Ludo’s key.
fishyfriend on #guix kindly volunteered to send a patch clarifying this.

For those looking to fetch my GPG key in order to verify the legitimacy
of my commit(s) to git-authenticate, you can get a copy of my key from
my Savannah profile [1]; or since I happen to be a GNU maintainer, from
the GNU maintainers keyring [2].  The key is the same one I have used to
sign my previous commits to guix.git with, and the one I have signed my
messages to this list with, including this very message, with primary
fingerprint  BE62 7373 8E61 6D6D 1B3A  08E8 A21A 0202 4881 6103, and
signing subkey  39B3 3C8D 9448 0D2D DCC2  A498 8B44 A0CD C7B9 56F2.

[1]: https://savannah.gnu.org/users/bandali
[2]: https://ftp.gnu.org/gnu/gnu-keyring.gpg

Sorry for any inconvenience or confusion this may have caused.

Best,
amin


signature.asc
Description: PGP signature

Re: New committer

[Amin Bandali]

Hi Ludo’,

Ludovic Courtès  writes:

> Hi,
>
> Amin Bandali  skribis:
>
>> You may have seen me post on the Guix lists, chat in #guix on freenode
>> (as bandali), or know me from my involvement with other areas of GNU.
>> I've been a happy user and occasional contributor to GNU Guix for some
>> time now.  As my contributions recently became more frequent, and since
>> I'd also like to help out with reviewing and merging patches, I decided
>> to apply for commit access to Guix, which I was kindly granted by the
>> Guix maintainers.
>
> Welcome aboard! :-)  It’s great to have you here.
>
> Ludo’.

Thank you very much!  It's great being here. ^_^

-mab


signature.asc
Description: PGP signature

New committer

[Amin Bandali]

Hello Guix,

You may have seen me post on the Guix lists, chat in #guix on freenode
(as bandali), or know me from my involvement with other areas of GNU.
I've been a happy user and occasional contributor to GNU Guix for some
time now.  As my contributions recently became more frequent, and since
I'd also like to help out with reviewing and merging patches, I decided
to apply for commit access to Guix, which I was kindly granted by the
Guix maintainers.

I'll be signing my commits with the GPG key I'm signing this email with,
with the fingerprint BE62 7373 8E61 6D6D 1B3A  08E8 A21A 0202 4881 6103.
You can get a copy of my key from my Savannah profile [0], or from the
GNU maintainers keyring [1].

[0]: https://savannah.gnu.org/users/mab
[1]: https://ftp.gnu.org/gnu/gnu-keyring.gpg

It's been very exciting seeing how far along GNU Guix has come so far,
and how it continues to grow even further.  Kudos to everyone involved
for their hard work, and I look forward to working with y'all on this
excellent GNU system.

Happy Hacking,

-mab


signature.asc
Description: PGP signature

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Amin Bandali]

Hi Ludo’, all,

Ludovic Courtès  writes:

> Hello!
>
> (Cc: maintainers.)
>
> Brett Gilio  skribis:
>
>> Dec 30, 2019 3:34:22 PM Ludovic Courtès :
>>
>>> Guix-HPC is “institutional”, that’s part of the reason behind this.
>>> Regarding gitlab.inria.fr, that’s because it used to be hosted at Inria.
>>> Also, is a channel developed
>>> by colleagues at Inria, so it’s more convenient to have it there.
>>
>>
>> Hey Ludo, thanks for the explanation.
>>
>> It makes sense why Guix-HPC lives somewhere else. Given this, what
>> do you propose for initiating the conversation on where the formal
>> methods haunt page should live with the other maintainers? I
>> personally think the repository should live on Savannah, but the
>> address needs to be discussed.
>
> It’s fine to host the repo on Savannah: we can ask for a new repo under
> the Guix umbrella, the downside being that access control will be the
> same as for the other repos (we can only grant access to all the repos
> or none of them.)  If you plan to open it more to formal methods people
> that do not yet contribute to Guix, it might be easier to use a separate
> repo.  You tell us!
>

Right.  Thinking about this, as I see it right now I think our use cases
for repos fall roughly into two categories:

- Closely Guix-related or small standalone things: this could be things
  like the Haunt sources for our site, or a Guix channel for additional
  package definitions, or anything closely related to Guix and/or small
  enough to fit under the Guix umbrella just fine.  For these, we should
  be able to get by with a very small number of repos in the short and
  long term.  Initially, we will only have one such repository, say,
  guix/guix-fm.git or guix/formal-methods.git, with its purpose being
  mainly to keep the sources for the site.

  For these repos we’ll happily accept patches from folks who aren’t
  Guix contributors via mailing list.  And I’d imagine once they have
  contributed enough patches, we could work out getting them commit
  access, especially if their gathered knowledge/experience extends to
  Guix directly (e.g. in form of familiarity with package definitions
  and writing them).

- Larger projects or ones that don’t quite fit the scope of Guix: for
  these, we might indeed consider registering separate Savannah projects
  rather than putting them under the Guix project.  I think the proposed
  bootstrapping ML compiler could be an example of such project.

All that said, I do wish Savannah supported finer access control at the
project level.  I just asked a fellow Savannah hacker for his opinion on
whether implementing that would be possible and feasible with the
current underlying infrastructure in mind.

>
> As for the domain name: I think it would be fine to use
> formal-methods.guix.gnu.org as long as the web site follows GNU and Guix
> policy, which mostly means referring only to free software, avoiding the
> phrase “open source” to describe it, and probably avoiding institution
> logos and such (I don’t think there’s any written policy but I would
> personally find it out of place on gnu.org.)  Anyway, the two of you are
> webmasters so you probably know this better than I do.  IOW, if you want
> to flatter your employers and labs, you might want to opt for a separate
> web site.  :-)
>

Most certainly; I wouldn’t expect anything less. :-)

As for institution logos, agreed.  If it ever comes such time that we
absolutely “have to” consider that, I’ll be sure to check with you and
the other Guix maintainers, fellow GNU webmasters, and of course rms.

As for the domain name, I think formal-methods.guix.gnu.org is a bit of
a mouthful to type or say on a regular basis, and I think an abbreviated
fm.guix.gnu.org would be more convenient; à la ci.guix.gnu.org.  For
what it’s worth, I’ve seen the FM abbreviation for Formal Methods used
fairly commonly around the community.

Lastly, I think it would be nice to have a guix...@gnu.org address for
Guix-FM.  Rather than a full-fledged Mailman list, I think a simple
alias, like with guix-...@gnu.org, will suffice.  Thoughts?

>
> Maintainers, what do you think?
>
> Anyway, step #1 is to get a web page ready.  :-)
>
> Ludo’.

I’ll work on putting one together over the next couple of days. :-)

Best,
amin


signature.asc
Description: PGP signature

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Amin Bandali]

Hi Ludo’, all,

Thanks for your vote(s) of confidence, Ludo’; it’s great to hear!

Ludovic Courtès  writes:

> Hi!
>
> Brett Gilio  skribis:
>
>> 100% Agreed. Amin is also working on packaging the Lean prover and I am
>> taking an interest in seeing if we can extend the OPAM importer to have
>> a subimporter for Coq.
>
> That’d be nice!
>

I just sent in the very first patch inspired (in part) by this proposal
to guix-patches: https://issues.guix.gnu.org/issue/38770 :-)

>
>> Ludo, what do you think about an https://fm.guix.gnu.org/ URL hosting a
>> haunt webpage designed by Amin and I (and maybe others) to detail the
>> purpose, goal, and maybe institutional use cases (research papers) of
>> GNU Guix in the formal methods community?
>
> The domain name would have to be discussed with others (other
> maintainers in particular; perhaps a better choice would be
> formal-methods.guix.info or fm.guix.info, next to hpc.guix.info), but
> the idea sounds great to me!
>

Sure!  I’d love to hear from others (esp. other maintainers) about this.

Personally, being a GNU maintainer, webmaster, and Savannah hacker, I’m
(almost by definition :-)) partial to using *.gnu.org and various pieces
of the GNU infra (lists, Savannah source repositories, …) for GNU work
whenever possible.  As such, I naturally like fm.guix.gnu.org better as
the domain, and would prefer to use Savannah for hosting our sources,
e.g. the Haunt sources for the Guix-FM site.

What do you think?

Like Brett, I’d be curious to hear the reasons for using *.guix.info and
a non-Savannah repository forge for Guix-HPC.

>
> Thanks,
> Ludo’.

Best,
amin


signature.asc
Description: PGP signature

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Amin Bandali]

Hello Guix!

Thank you Brett for taking initiative and putting this awesome proposal
together on all our behalves, and to everyone else for chiming in and
expressing your interest and support!

To share some of my (scattered) thoughts on this, as a researcher I
think reproducible and verifiable research is a crucially important
topic, yet traditionally and often a neglected one.  Throughout my
graduate studies, too many times I stumbled on papers with interesting
claims that I sadly could not reproduce or easily verify for myself.
And I think this is especially ironic and painful for those of us doing
research in formal methods, computing science, and software engineering;
and is where projects like GNU Guix with their awesome efforts in
reproducibility could act as role models and show what's possible.

For instance, for better or worse many of the tools I have worked with
over the last few years are primarily implemented in Java, often in form
Eclipse plugins.  Suffice to say that release management, bundling, and
distribution practices of most of these tools leave a lot to be desired.
As part of the Formal Methods in GNU Guix Working Group, I'd love for us
to try and get in touch with the developers of these tools and offer to
work with them to challenge and improve the status quo, resulting
ultimately in more readily and easily accessible tools, greatly useful
for verifying and reproducing existing literature.

As Brett and I alluded to, there's a large variety of tasks in all
shapes and sizes that could use your help, from more "researchy" work
like writing a bootstrapping SML '97 compiler, or exploring synthesis
and verification for GNU Guile and GNU Guix, to less researchy ones like
packaging (even more) formal methods-related software and helping their
developers improve their release and package qualities.

We would love to hear more from you about this in trying to gradually
put together actionable plans.  If you'd like to chat with us, please
come say hi to us in the #guix IRC channel on freenode.  My nick there
is bandali, and Brett is brettgilio.

Best,
amin


signature.asc
Description: PGP signature

Re: Emacs 27

[Amin Bandali]

Hi John,

John Soo  writes:

> Hi guix,
>
> Speaking of the next version of emacs, do you think we could add an
> emacs-next package? I have tried to build from head recently and the
> recent changes to the dumping mechanism does not work with our current
> package definition.
>
> - John

Perfect timing? :-) https://issues.guix.gnu.org/issue/38662

-amin


signature.asc
Description: PGP signature

Re: Add helper for .desktop file creation?

[Amin Bandali]

Hi Pierre, Nicolas,

Pierre Neidhardt  writes:

[...]

> Would you happen to know where this is implemented in Nix?
> Otherwise I'll look at the doc you've linked.
>

It seems to be implemented here [1].  For examples of use, look for
“makeDesktopItem”.

[1]: 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/make-desktopitem/default.nix

Best,
amin

Re: Documentation videos are being uploaded!

[Amin Bandali]

Seconding Tim’s sentiments :)  I think the videos will be fantastic
resources for newcomers and Guix enthusiasts in general, and we can’t
thank Laura, Paul, and everyone else involved enough!  I for one can’t
wait to find some free time on my hands to binge-watch the whole series.

Re: Documentation videos are being uploaded!

[Amin Bandali]

Pronaip  writes:

[...]

> The video is great but the introductory videos link
> (https://audio.video.gnu.org) seems to lead to nowhere. Has it not
> been set up?
>
>

That’s a typo; it should have been https://audio-video.gnu.org.

Re: Update on 1.0.1

[Amin Bandali]

Hi Ludo’,

> Any other really important bit people would like to address?

Not critical, but it would be nice to update guix-install.sh to mention
“ci.guix.gnu.org” instead of “ci.guix.info” for clarity, similar to this
previous commit of yours [0] from a while back.

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/etc/guix-install.sh?id=4a0b87f0ec5b6c2dcf82b372dd20ca7ea6acdd9c

Re: Deliver important Guix changes to users, please

[Amin Bandali]

Hi Ludo’, all,

On 2019-04-15  2:56 PM, Ludovic Courtès wrote:

[...]

>
> ‘guix pull’ already provides high-level “package news”, but I agree it’d
> be nice to have a way to convey “system news” and perhaps free-form
> messages like Debian’s change logs.
>
> I suppose we could use some specially-formatted Git commits to pass
> messages to users.  I’m afraid it would be hard to get those messages
> translated.
>
> Thoughts?
>

That’s an interesting idea.  Another alternative, perhaps, could be
having a “news” or “breaking changes” section/topic on the Guix blog,
ideally with a dedicated atom feed, where one could follow changes with
drastic change in system and/or package behaviour, or ones potentially
requiring a manual intervention of sorts.  Both Parabola and Hyperbola
have that section on their website, with latest news shown on the front
page.

Thoughts?

Best,
amin

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Amin Bandali]

Marius,

On 2019-02-16  5:33 PM, Marius Bakke wrote:

[...]

>
> Can you point out one or more files with an unclear license?  Do we have
> any reason to distrust what's written in the LICENSE file?
>

I don’t have a direct example of one such file off top of my head, but
looking at the large reported chromium issue[1], I see there are a
number of open blocking issues linked to that one.  Also, I was looking
at [2] and [3] from a little over a year ago, which included the results
of running licensecheck on the chromium tree, but I wasn’t able to
download any of the resulting txt files there.  So I thought I’d clone a
fresh copy of chromium and run licensecheck from the Debian Stretch repo
on all the files as follows:

git clone --depth 1 https://chromium.googlesource.com/chromium/src.git
cd src
git rev-parse HEAD  # result: eda06a0b859a08d15a1ab6a6850e42e667530f0b
licensecheck -c '.*' -r * > ../licensecheck-chromium-eda06a0b859a.txt

I’ve attached a gzipped version of the above text file.  Granted, there
are caveats: firstly, that the above invocation of licensecheck examines
/all/ of the files in the repo, including test html files which are not
relevant and should be filtered out; and secondly, the output contains a
very large number of “UNKNOWN” results which may be false positives.

Link [3] mentioned running FSD Script Aid on the chromium tree as well,
but I don’t have enough time at the moment to do so.

Hope this is of some help.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=28291
[2]: https://lists.gnu.org/r/directory-discuss/2017-11/msg00014.html
[3]: https://directory.fsf.org/wiki/Talk:Chromium

Best,
amin

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Amin Bandali]

Marius, if I understand correctly, you have summarized your patch with
respect to the following two issues:

1. Your patch strips out parts of Chromium that are /clearly/ nonfree
   and proprietary (e.g. unrar per your example), and

2. Your patch addresses (or tries to) privacy concerns.

But as far as I can tell, you have not addressed the concerns shared by
Bill and others about the situation with files in the Chromium codebase
that don’t have a clear license.  So I’ll try to repeat/rephrase their
question(s): does your patch address the files with unclear license?
Does it strip out those files that don’t have a clear license?  Can we
be certain that the Chromium built from your patch explicitly *only*
contained free software?

Best,
amin

Re: [PATCH] gnu: Add ungoogled-chromium.

[Amin Bandali]

Hello Marius,

Thanks for your work patching and packaging ungoogled-chromium!

I haven’t had a chance to have a closer look at your patch, but would
you mind elaborating on the “* Free software only.” part of your stated
feature-set and if/how it addresses licensing concerns raised previously
e.g. by bill-auger here[1] with respect to the FSDG status of Chromium,
as well as maintaining solidarity with other FSDG-complying distros?

[1]: https://lists.gnu.org/r/guix-devel/2018-09/msg00264.html

Best,
amin

Re: ‘nss-certs’ missing in the installation image

[Amin Bandali]

> Any other opinion?

I’d personally prefer if nss-certs were already available during
installation; but if not, having a link in “System Installation” to
instructions on how to safely install and set it up seems like a fair
compromise.

My 2¢.

Re: guix.gnu.org sub-domain

[Amin Bandali]

On 2018-12-15  3:20 PM, Chris Marusich wrote:
> Hi Ludo,
>
> Ludovic Courtès  writes:
>
>> I’m sure Julien wouldn’t mind getting some help or insight, so please do
>> get in touch!
>
> OK, I'll speak privately with Julien about the DNS setup to avoid adding
> noise to this email thread.
>
> -- 
> Chris
>

Hi Chris, Julien,

Any update on this?  I too had asked Ludo about DNS for guix.gnu.org a
couple of weeks ago, and he’d pointed me to the bayfront.scm [1] config
file, but I was swamped with work and only recently have found a bit of
free time on my hands.  While looking for information about Knot, I also
stumbled upon Julien’s configuration [2].  I was wondering if y’all were
able to spend any time on this, and if so, if you ended up committing
your progress anywhere?

Best,
amin

Footnotes:
[1]  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm

[2]  https://lepiller.eu/ma-configuration.html

Re: [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Amin Bandali]

Hi Ludo’,

On 2018-12-04  3:11 PM, Ludovic Courtès wrote:
> Hi Amin,
>
> Amin Bandali  skribis:
>
>>> For the domain name I initially wanted “ci.guix.gnu.org” but we failed
>>> to set that up.  Oh well, I think that’s OK.
>>
>> What was the failure about, if you don’t mind me asking?  I’m
>> curious if there might be a way to salvage it.
>
> I initially proposed to delegate subdomain handling for guix.gnu.org on
> the machine that guix.gnu.org currently points to (aka. “bayfront”).  To
> do that we’d need to coordinate with the FSF sysadmins and someone
> DNS-savvy (i.e., not me :-)) should amend the configuration at
> <https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm>
> to have a Knot service or similar.
>
> If you’d like to help, that’d be great!
>
> Ludo’.

Thanks for the reply and for the link.  I’m no DNS expert either :) but
I’ll look into the DNS services section of the Guix manual and will see
if I can amend bayfront.scm.  If I get anywhere, I’ll post here and we
could then reach out to the FSF sysadmins and ask them to delegate that
subdomain to bayfront.

Best,
amin

Re: [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Amin Bandali]

Hi Ludo’,

> For the domain name I initially wanted “ci.guix.gnu.org” but we failed
> to set that up.  Oh well, I think that’s OK.

What was the failure about, if you don’t mind me asking?  I’m
curious if there might be a way to salvage it.

-amin

Re: bootstrap: i686-linux now builds without binutils, gcc, and glibc seeds

[Amin Bandali]

Hello Jan,

> The wip-bootstrap branch now builds without binutils, gcc, and glibc seeds.
>
> Thanks to #bootstrappable and #glibc and a week's work of hammering and
> determination we succeeded in bootstrapping glibc-2.16.0.  This glibc is
> recent enough to bootstrap GuixSD!
> [...]
> We're now very close to have Guix x86 be the first GNU/Linux that was
> bootstrapped without the use of binary C compiler seed.

That's *awesome*!  Thank you (and everyone else involved) for all
your work on #bootstrappable, really exciting stuff!

  -amin

Re: https://issues.guix.info

[Amin Bandali]

Hi Ricardo,

> I went ahead and documented the supported query terms on
> https://issues.guix.info/help and linked to it from the start page.
>
> I also added support for “date:” (submission date) and “mdate:” (message
> date) filters, which should look familiar to users of mu/mu4e.

Wonderful, looks great!  Thanks again for all your work.

  -amin

Re: https://issues.guix.info

[Amin Bandali]

Hi Ricardo,

> I agree.  I don’t know how to present these things nicely, but I’ll play
> around with this.
>
> BTW: “submitter:who” should also work now.  Like “is:…” it’s a rather
> expensive query because the result set from Debbugs has to be filtered
> locally.

Cool, thanks!

>>> - make the search bar look good
>>
>> Adding class="form-control" would be a nice first step.  Also,
>> it'd probably be a good idea to wrap the  in a div with
>> class="row", and use bootstrap grids to make the search bar and
>> the button smaller (by putting them in a column), and display the
>> above information about the search syntax in another column to
>> the right of the form.
>
> Thanks for the suggestions.  I read the bootstrap CSS docs and came up
> with something that I hope is an improvement.

Thanks, that does looks better!  I'm not much of a UI person
either, but I'll see if I can manage to make a nice presentation
of the search syntax on the front page and will send a patch if
it turns out looking ok.

  -amin

Re: https://issues.guix.info

[Amin Bandali]

Hi Ricardo,

> Some of you know this already, but I think it’s time for a proper
> announcement here.  I made a little something:
>
> https://issues.guix.info

Awesome, it looks pretty neat!

> The search box accepts issue numbers (for *any* bug on the GNU instance
> of Debbugs), but it also supports a few special queries, such as
>
> is:open / is:pending –> only open issues
> is:done / is:closed  –> only completed issues
> title:foo -> issues containing “foo” in the title
> author:rekado –> issues that “rekado” contributed to
>
> Other supported terms are “severity”, “tag”, and “submitter”, but not
> all of them really work as they should, partly because of bugs in mumi,
> partly because of limitations in Debbugs.

I think It would be neat to present these to the user, right on
the website itself.

> - make the search bar look good

Adding class="form-control" would be a nice first step.  Also,
it'd probably be a good idea to wrap the  in a div with
class="row", and use bootstrap grids to make the search bar and
the button smaller (by putting them in a column), and display the
above information about the search syntax in another column to
the right of the form.

  -amin

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

[Amin Bandali]

Nils Gillmann  writes:

> Please read into the chromium thread or search locally through it -
> Marius already had some comments on ungoogled-chromium. Our chromium
> browser is not just chromium taken from upstream. Many (maintained)
> patches are taken and applied.

Thanks for mentioning this.  You seem to be referring to the [0]
message and the [1] package from last year, which I hadn't seen
before.

To quote Marius,

,[ Marius Bakke  ]
| I actually picked most of the patches from ungoogled-chromium (which
| includes inox and iridium), but skipped "high maintenance" ones. This
| started as an attempt to package that very project, but they were
| lagging too far behind upstream IMO.
| 
| FSDG problems is the reason I haven't advertised it. At the very least,
| the Google integrations should be disabled and analytics removed (but
| Chromium can't currently build without either). I think if most of the
| "FIXMEs" are resolved upstream, it might be eligible for a free distro.
| 
| Now that the cat is out of the box, feel free to send patches somewhere
| and I'll incorporate them in the branch :-)
`

With regards to FSDG problems, I wonder what the status is today,
considering that ungoogled-chromium's patch sets seem to have
grown a fair bit in number [2], and might be already addressing
some of the issues.

As for the "lagging too far behind upstream" issue, that doesn't
seem to be the case anymore: looking at releases on [3] and [4]
it looks like ungoogled-chromium's latest shipped release matches
the latest released chromium version.  Granted, I have noticed in
the past for ungoogled-chromium to lag behind the latest release
by a week or two, that'd still be better compared to the current
situation with respect to the current Firefox/IceWeasel release.

  -amin

[0]: https://lists.gnu.org/r/guix-devel/2017-01/msg00928.html
[1]: 
https://github.com/guix-users/guix-nonfree/blob/master/gnu/packages/chromium.scm
[2]: 
https://github.com/Eloston/ungoogled-chromium/tree/master/patches/ungoogled-chromium
[3]: https://ungoogled-software.github.io/ungoogled-chromium-binaries/
[4]: https://github.com/Eloston/ungoogled-chromium/releases/tag/68.0.3440.106-2

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: guix download and GitHub

[Amin Bandali]

Hello,

Looking at the manual entry for guix download [0], we can see:

guix download verifies HTTPS server certificates by loading
the certificates of X.509 authorities from the directory
pointed to by the SSL_CERT_DIR environment variable (see
X.509 Certificates), unless --no-check-certificate is used.

[0]: 
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-download.html

You can either use your operating system's certs directory
(usually /etc/ssl/certs), or install the nss-certs guix package,
as shown on the man page for X.509 Certificates [1] and export
the related environment variables to tell programs to use it:

$ guix package -i nss-certs
$ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
$ export 
SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
$ export GIT_SSL_CAINFO="$SSL_CERT_FILE"

[1]: 
https://www.gnu.org/software/guix/manual/en/html_node/X_002e509-Certificates.html

Hope that helps.

  -amin

Re: GNOME 3 screenshot for gnu.org

[Amin Bandali]

Hi Ludo,

Ludovic Courtès  writes:

> I think it’s fine to use the current one, though maybe we should
> consider making new screenshots too…

Sounds good!  If you do make new ones and want the one on the
front page updated, feel free to ping me or webmast...@gnu.org.

Thanks,
-amin

GNOME 3 screenshot for gnu.org

[Amin Bandali]

Hello Guix,

The FSF is looking to refresh the screenshot on www.gnu.org, and
add new ones showcasing Mate and GNOME 3.  I suggested taking the
GNOME 3 screenshot from GuixSD.

I see there's already a GNOME 3 screenshot [0] on the Guix page.
Given that the screenshot seems to be from 2016, would you like
to take a new one, or is it fine if we use the current one?

[0]: https://www.gnu.org/software/guix/screenshots/gnome/

-amin