bug#24066: icecat "mailto" handler does not work - and cannot be reconfigured by user

[Brendan Tildesley]

If I click the reply via email button in Icecat, it switches to icedove 
but does not open a reply email at all.
In ungoogled-chromium, it opens up a blank reply email, failing to fill 
the To, CC, Subject with anything.


If I click the equivalent mailto link on the issues page in Icecat, its 
the same
If I click the equivalent mailto link, but in chromium, it opens a 
new email, but only the Subject is filled out. No To or CC.


I've always thus replied to the mailing list by manually copy-pasting 
the the Subject, adding Re:, and trying to find the posters email 
address, and bug address to add in To/CC. Is this related to your bug?

bug#44027: 1.2-29a2eb3 Installer fails at final stage installing GRUB.

[Brendan Tildesley]

|Going through the GUI installer selecting all the defaults, and install 
with LVM and ecryption, AND for the normal option without encryption I 
get these errors on TWO different laptops, both ~10 years old with BIOS. 
Encrypted: Installing for i386-pc platform. grub-install: warning: this 
GPT partition label contains no BIOS Boot Partition; embedding won't be 
possible. grub-install: error: embedding is not possible, but this is 
required for RAID and LVM install. Unencrypted: ||Installing for i386-pc platform. grub-install: warning: this GPT 
partition label contains no BIOS Boot Partition; embedding won't be 
possible. grub-install: warning: Embedding is not possible. GRUB can 
only be installed in this setup by using blocklists. However, blocklists 
are UNRELIABLE and their use is discouraged.. grub-install: error: will 
not proceed with blocklists.|

||

bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

[Ludovic Courtès]

pkill9  skribis:

>> > Maybe if the length/version is different, then a symlink could be
>> > created in the store pointing to the new dependency, with a
>> > name/version that matches the length of the original dependency's
>> > store name? Perhaps this new name/version could be something like
>> > /gnu/store/...-original-dependency-name-gg, where 'g..' matches
>> > the length of the version of the original dependency. The many 'g's
>> > would make it clear that it is a graft. Then if someone looks in
>> > the store, they would see it's a symlink too.  
>> 
>> That only works if the new name is shorter than the old name though.
>> When the new name is longer (which is a more common case in our
>> experience when introducing package replacements, typically because
>> the new version string is longer), nothing can be done.
>
> I'm confused about what you mean. Why would it matter if the new
> name is longer than the old name?

All I’m saying is that nothing can be done when the new name is longer
than the old one: we just cannot graft.

Ludo’.

bug#26604: documentation: pdf generation is broken

[Ludovic Courtès]

Hi,

Andreas Enge  skribis:

> On Mon, Sep 28, 2020 at 09:57:43PM +0200, zimoun wrote:
>> [env]$ make doc/guix.pdf
>
> try this instead:
> make V=1 pdf
> which will print what happens.
>
> I have the monolithic texlive package in my profile and building the pdf
> "almost worked":
> ...
> doc/images/coreutils-size-map.png>
> !pdfTeX error: /home/andreas/.guix-profile/bin/pdftex (file 
> doc/images/coreutils-graph.png): reading image file failed
>  ==> Fatal error occurred, no output PDF file produced!
>
> It turns out there are a bunch of empty .png files in doc/images/, with
> corresponding non-empty .dot files. I deleted them and installed graphviz
> into my profile in the hope that "make pdf" would create the missing
> .png files, but it does not.
>
> However, the following "almost almost" worked:
> - remove the empty .png files and install graphviz
> - "make"
> - "make pdf"
> I obtained the English, German, French and Spanish pdf documentation, but
> then a lot of complaints about unicode characters for the Russian
> documentation (and "make doc/guix.zh_CN.pdf" also has unicode problems).

Simon, can you close the issue if this is fine on your side as well?

Maybe it’s a matter (as usual…) of choosing the right texlive-* packages.

Thanks,
Ludo’.

bug#26604: documentation: pdf generation is broken

[zimoun]

Hi,

On Fri, 16 Oct 2020 at 12:13, Ludovic Courtès  wrote:
> Andreas Enge  skribis:

> > On Mon, Sep 28, 2020 at 09:57:43PM +0200, zimoun wrote:
> >> [env]$ make doc/guix.pdf
> >
> > try this instead:
> > make V=1 pdf
> > which will print what happens.

Thanks for the tip.


> > I have the monolithic texlive package in my profile and building the pdf
> > "almost worked":
> > ...
> > doc/images/coreutils-size-map.png>
> > !pdfTeX error: /home/andreas/.guix-profile/bin/pdftex (file 
> > doc/images/coreutils-graph.png): reading image file failed
> >  ==> Fatal error occurred, no output PDF file produced!
> >
> > It turns out there are a bunch of empty .png files in doc/images/, with
> > corresponding non-empty .dot files. I deleted them and installed graphviz
> > into my profile in the hope that "make pdf" would create the missing
> > .png files, but it does not.
> >
> > However, the following "almost almost" worked:
> > - remove the empty .png files and install graphviz
> > - "make"
> > - "make pdf"
> > I obtained the English, German, French and Spanish pdf documentation, but
> > then a lot of complaints about unicode characters for the Russian
> > documentation (and "make doc/guix.zh_CN.pdf" also has unicode problems).
>
> Simon, can you close the issue if this is fine on your side as well?

Well, it is not satisfactory for me, yet.  It is still "almost almost"
and needs some wizardies to work.  At least the doc should be updated
and maybe a manifest file with the correct TeX packages.  I mean we
have modular texlive and we recommend to use it but we do not use it
for our own infrastructure and then we rely on the BIG texlive
package.  Hum?! :-)

> Maybe it’s a matter (as usual…) of choosing the right texlive-* packages.

They should be documented at least.  (How to find them is another story. ;-))


All the best,
simon

bug#44030: guix import pypi foo@1.2.3 breaks

[zimoun]

Dear,

The syntax across the different importers are not uniform.  Especially,
compare:

   guix import hackage mtl@2.1.3.1
   guix import pypi itsdangerous@1.1.0

and worse, the option ’--recursive’ leads to an error for the latter.
Note that instead:

   guix import pypi itsdangerous/1.1.0

perfectly works, even the option ’--recursive’.

All the information is there, and the UI has to be fixed.  It is a
perfect first contribution fixes.


All the best,
simon

PS:
Reported by Zelphir Kaltstahl.

bug#44025: haunt incompatible with package guix

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Well, does it make sense to drag gnu/packages/package-management.scm in
> guile-xyz.scm? and then replace with something like:
>
> (inputs
>  `(("guile" ,@(assoc-ref (package-native-inputs guix) "guile"
>
>
> Or create a haunt variant named ’haunt-guix’ keeping the compatibility?

Can we do that, but keep that variant in the web site’s ‘.guix.scm’
file?

Thanks!

Ludo’.

bug#44027: 1.2-29a2eb3 Installer fails at final stage installing GRUB.

[Ludovic Courtès]

Hi Brendan,

Brendan Tildesley  skribis:

> Going through the GUI installer selecting all the defaults, and install with 
> LVM and ecryption, AND for the normal option without encryption I get these 
> errors on TWO different laptops, both ~10 years old with BIOS.
>
> Encrypted:
>
> Installing for i386-pc  platform.
> grub-install: warning: this GPT partition label contains no BIOS Boot 
> Partition; embedding won't be possible.
> grub-install: error: embedding is not possible, but this is required for RAID 
> and LVM install.
>
> Unencrypted:
>
> Installing for i386-pc  platform.
> grub-install: warning: this GPT partition label contains no BIOS Boot 
> Partition; embedding won't be possible.
> grub-install: warning: Embedding is not possible. GRUB can only be installed 
> in this setup by using blocklists. However, blocklists are UNRELIABLE and 
> their use is discouraged..
> grub-install: error: will not proceed with blocklists.

Shouldn’t it create a “legacy” partition table rather than GPT since
we’re on an old, non-UEFI platform?

Ludo’.

bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong

[Taylan Kammer]

On 15.10.2020 09:42, Ludovic Courtès wrote:
> Ludovic Courtès  skribis:
> 
>> The problem is that the ‘cond-expand’ used to define ‘arch32bit?’ is a
>> expansion-time thing when (cross-)building Bytestructures itself, so
>> it’s incorrect from cross-building from 64-bit to 32-bit.
>>
>> I believe that changing it to:
>>
>>   (define arch32bit? (memq data-model '(ilp32 lp32)))
>>
>> would fix it because then the test would happen at run time.
> 
> I confirm that the attached patch for Bytestructures solves the problem
> (running ‘guix pull’ in my childhurd :-)).
> 
> Let’s see whether it needs to be adapted for inclusion upstream.

Hi Ludo,

Thanks for finding finding this bug and for the patch.

I'll try to include a portable version of the fix ASAP.  I should have
time for it tomorrow.

> 
> Ludo’.
> 


- Taylan

bug#44044: texlive-latex-oberdiek is incomplete

[Ricardo Wurmus]

The texlive-latex-oberdiek package does not provide all files that the
“oberdiek” TeX Live package is supposed to contain.

Notably, all of the tex/generic/oberdiek files are missing or at least
installed to the wrong directory (tex/latex/oberdiek).

-- 
Ricardo

bug#44027: 1.2-29a2eb3 Installer fails at final stage installing GRUB.

[Brett Gilio]

Ludovic Courtès  writes:
>
> Shouldn’t it create a “legacy” partition table rather than GPT since
> we’re on an old, non-UEFI platform?
>
> Ludo’.
>

That is my thinking as well, it should create a legacy MBR table.

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

[pkill9]

> All I’m saying is that nothing can be done when the new name is longer
> than the old one: we just cannot graft.

If a symlink is used though, it wouldn't matter if the new name is
longer, the symlink would point to the new package, and the name of the
symlink would match the length of the old package.