Re: debbugs irritation Was: [WIP Patch] Adding an FHS container to guix shell

[jbranso]

August 18, 2022 11:01 AM, "zimoun"  wrote:

> Hi,
> 
> On Thu, 21 Jul 2022 at 22:22, Csepp  wrote:
> 
>> Mumi and Debbugs have different search interfaces and seem to use
>> different ordering.
> 
> Hum, I am confused because from my understanding, there is one Debbugs
> instance – which is quickly said some Perl scripts managing mailing
> lists and thus implementing a bug tracker database. This database is
> then manipulated via SOAP-interface.
> 
> This Debbugs instance is out of the control of the Guix project, AFAIK.
> 
> On the top of this instance, various front-ends are implemented:
> 
> + historical one running at: https://debbugs.gnu.org
> + Mumi running at: https://issues.guix.gnu.org
> + emacs-debbugs running locally
> 
> And even Debian folks provide many others, as python3-debianbts or
> reportbug coming with the CLI tool bts, mailscripts, etc.
> 
> https://git.spwhitton.name/mailscripts/tree
> 
>> IMHO these papercuts add up. Browsing and cross-referencing issues and
>> patches is way harder than it is with other forges.
> 
> Well, harder depends on the point of view. :-)
> 
> Indeed, you need more than just type bug#12345 to cross-link. Using a
> descent mailreader, it appears to me easy to have helper. For instance,
> using Emacs, I have a custom function [1] “M-x my/guix-issues“ which
> adds to the kill-ring an URL. Recently, Ricardo added Message-ID to
> Mumi which helps too; using emacs-notmuch, just "ci” for stashing and
> then pasting elsewhere.
> 
> 1: 
> 
> 
> About browsing, Mumi needs more love. :-)
> 
>> Not saying we need to switch, maybe it's easier to just add the missing
>> functionality. Or maybe it doesn't matter to anyone else.
> 
> Well, the GNU instance of Debbugs has many flaws. But the project will
> not switch from it, IMHO. That’s why Mumi as front-end tries to improve
> the situation by adding the missing functionalities.

I am actually working on a patch to emacs-debbugs that will provide:

debbugs-gnu-my-open-bugs   

https://issues.guix.gnu.org/56987

(I'm also fairly slow at submitting patches, so please be patient).  :)

Will show you the bugs, which you submitted that are still open.

At least the emacs guys seem fairly interested in improving emacs-debbugs.

:)

> 
> Cheers,
> simon

Re: A real-life test of long-term reproducibility

[zimoun]

Hi Konrad,

On lun., 08 août 2022 at 10:44, Konrad Hinsen  
wrote:

>> Besides, I recently added ‘etc/time-travel-manifest.scm’ and added a
>> corresponding jobset at 
>
> Nice! Guix will be certified for time travel!

[...]

>> For best practices, I do have one suggestion.  The Guix package
>> collection is not uniformly reproducible or archived.  The best thing
>> you can do to ensure the long-term prospects of your projects is to
>> actually check how much of the source code is archived and how many of
>> the builds are reproducible.  There is no turn-key solution for this
>
> Yes, that's a good idea, and I have done it for my most recent packages.
> Time will tell if this is enough.

Now, Guix is checking that “guix time-machine” does not break; i.e, be
able to rebuild a previous Guix using inferior.  That’s cool!

However, many things can be out of rail.  This claim about
reproducibility over the time assumes:

 1. compatibility of the Linux kernel
 2. availability of all the source code
 3. compatibility of the hardware

Well, until now, nothing had been reported about #1.  But, we have
examples of issues about #2 and #3.

For instance, about #2, Timothy reported the loss of the source code of
ImageMagick 6.9.9-30 – some time ago, I reported another issue with
another ImageMagick version from 2020
().  Although the
project is making many efforts to archive all the source, the coverage
is not 100%:

https://ngyro.com/pog-reports/latest/

and only one tiny loss of only one node in the graph of dependencies,
then all the efforts are ruined.

About #3, the new NVMe disks leads to an issue with bootstrapping; as
reported by .  It means that, if the
binary substitutes are lost and I have only a machine with NVMe, then I
cannot rebuild from scratch.


All that said, Guix is the best and most advanced solution on the market
for reproducible time-traveling. :-)  For most of the cases, it is
awesome to just type “guix time-machine” and rebuild a complete
computational environment exactly as it was 2 or 3 years ago.


On lun., 08 août 2022 at 10:49, Konrad Hinsen  
wrote:

> Even 1.0.0 isn't obvious:
>
>   $ guix time-machine --commit=version-1.0.0 -- environment guix
>   guix time-machine: error: Git error: unable to parse OID - contains invalid 
> characters
>
> OK, so let's try the commit hash:
>
>   $ guix time-machine --commit=48aa30ce73d45dc5f126f42f01e65f1be4a9b578 -- 
> environment guix
>   Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>   Authenticating channel 'guix', commits 9edb3f6 to 48aa30c (6 new commits)...
>   guix time-machine: error: commit
>   48aa30ce73d45dc5f126f42f01e65f1be4a9b578 is not a descendant of
>   introductory commit 9edb3f66fd807b096b48283debdcddccfea34bad

That’s because version-1.0.0 (48aa30ce73) is a branch and indeed not a
descendant.

--8<---cut here---start->8---
* 746ac457cc Merge branch 'version-1.0.0' 
|\ 
* | c457f109be gnu: php: Update to 7.3.5. 

[...]

* | 1a8984536f gnu: Add sdl2-net. 
| |  * 48aa30ce73 build: Add 'doc/build.scm' to build on-line copies of the 
manual.  (origin/version-1.0.0)
| |  * adf577dcc4 doc: Update htmlxref.cnf. 
| |  * 1a9fc8e228 doc: Warn about missing entries in htmlxref.cnf. 
| |  * 2921b6a611 doc: Adjust cross-references for GNU triplets. 
| |  * 3aa11dfbed doc: Provide the actual URL to the VM image. 
| |  * 542e7fb57f doc: Add note about . 
| | /  
| |/   
| * 3a3e9f2bb5 guix-install.sh: Update URL. 
| * 9c941364bf vm: Build ISOs and VM images in a UTF-8 environment. 
| * 17acc215bf gnu: guix: Update to 326dcbf. 
| * 326dcbf1b3 gnu: guix: Update to 1.0.0. 
| * 6298c3ffd9 Update NEWS.  (tag: v1.0.0)
--8<---cut here---end--->8---

What you want is tag v1.0.0 (6298c3ffd9).  Otherwise, you need the
option ’--disable-authentication’. 


Cheers,
simon

Re: A real-life test of long-term reproducibility

[zimoun]

Hi Blake,

I am late to the party. :-)

On jeu., 04 août 2022 at 15:35, bl...@reproduciblemedia.com wrote:
> August 4, 2022 8:43 AM, "Konrad Hinsen"  wrote:

>> One of our claims is that Guix can rebuild code identically as long as
>> we have a machine with a Linux kernel and a POSIX filesystem.

This claim is correct, AFAIU.


> This actually isn't the claim. Reproducibility is only guaranteed on
> Guix systems. It's important that you reproduce the entire system, which
> means you will have needed to have saved the commit of your version of
> the Guix package manager in order to return to that system.

It is possible to rebuild identically on any foreign GNU/Linux distro
running the Guix package manager.  The assumptions, between the 2 points
in time, are:

 1. compatibility of the Linux kernel
 2. availability of all the source code
 3. compatibility of the hardware

AFAIK, #1 and #3 are satisfied.  About #2, it depends and many corner
cases are around.

Running Guix System would allow to easily satisfy #1, but, AFAIK, no one
reported an incompatibility of the Linux kernel defeating “guix
time-machine -- build”, and thus, it appears to me still hypothetical
(although possible on the paper) that, in this case, Guix System would
still allow the travel back in time.


> See the section of the Guix manual "Replicating Guix" for more info.
> https://guix.gnu.org/en/manual/devel/en/html_node/Replicating-Guix.html

Guix System is not mentioned, IIRC. :-)


Cheers,
simon

Re: Building, packaging and updating Guix with confidence

[Josselin Poiret]

Hi zimoun,

zimoun  writes:

> Now #53210 [1] is closed, it improves the situation, right?  Is it
> enough for the C extension you are working on?
>
> 1: 

Well, wrt. the C extension, it doesn't really improve much, there's
still the issue of having both build systems that Ludo summarized work
the same, and also the guix snapshot is still used for the system-wide
guix, so the issue remains.

Best,
-- 
Josselin Poiret

Re: (ice-9 base64)?

[Maxime Devos]

On 19-08-2022 02:20, Aleix Conchillo Flaqué wrote:

So, what do you think would be the way to proceed in order to include 
a base64 implementation in Guile itself?


For example:

1. Add (ice-9 base64) (or (encoding base64)) to Guile and let new 
projects and existing projects to update with conditional module 
loading to support old versions of Guile.
2. Do unbundling in Guix packages both for projects that have not 
updated upstream and for projects in (1). The unbundling would be done 
by pointing to Guix's (or guile-gcrypt) base64 implementation, or is 
there a way they could point to Guile's implementation?


If the canonical location of base64 becomes Guile itself instead of 
guile-gcrypt, then it needs to be pointed at Guile's base64. Likewise, 
Guix' base64 implementation would need to be replaced by Guile's, with a 
fallback.


I don't see why we would point to Guix' implementation, it's missing 
some bug fixes.




Does that make sense or am I still missing something (I'm about to 
catch a cold so my brain is not working quite well this week)? 
Originally, I was thinking only in (1).


Except for the remark about (1), I think so.  I think the following list 
is a bit more clear though:


1. Add (ice-9 base64) to Guile (or another name (encoding base64)).
2. Inform a few upstreams that used to include a copy of base64 that it
   is now part of Guile itself -- those upstreams can then remove their
   local copy and use Guile's base64, and do conditional module loading
   if they cannot increase their minimal Guile version yet.
3. In Guix, we will have to update Guile to a new version that has the
   base64 module and remove the local fallback copies.  And if upstream
   refuses patches to use Guile's base64 (maybe with a fallback), then
   it will need to be patched locally in Guix.

On (2): I don't think it's necessary to contact _all_ the upstreams, 
though to give a good example it would be nice to contact some of them.


(3) is a Guix concern, not really a Guile concern.

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature