Temporarily stepping back from Guix

[Kei Kebreau]

Hello all,


FYI, I'll be turning in my commit access this week! I'm caught in the 
middle of many different transition periods in my life and will be 
taking some time away from the GNU Guix project as a result. Perhaps in 
the mid-term future (a year or so?) I'll be able to return, but for now, 
as a matter of security, I'm backing away. I'll still be using Guix and 
admiring all the great progress we have made and will make in the 
future! This project has been a great introduction to the world of free 
software, and I hope to work with you all again sooner rather than later.



Thanks as always,

Kei

Re: 02/05: gnu: libmad: Install pkg-config file.

[Kei Kebreau]

Ludovic Courtès  writes:

> Hi Kei,
>
> Perhaps we can keep the .pc file for libmad, adding a comment mentioning
> what you wrote above, but remove it in those cases where it’s not needed
> (as in: not required by Audacity & co., and not done in other distros)?
>
> Thanks,
> Ludo’.

This sounds good to me.  I take this message as permission to push some
changes with those comments?


signature.asc
Description: PGP signature

Re: Commit access

[Kei Kebreau]

Miguel Ángel Arruga Vivas  writes:

> Hello, everybody!
>
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits.  This text has been signed with
> it, which has the following information and fingerprint:
>
> pub   rsa3072 2020-09-09 [SC] [expires: 2022-01-01]
>   888784C41459ACCB83E7E84C634C6E8979FABEC2
> uid   [ultimate] Miguel Ángel Arruga Vivas 
> sub   rsa3072 2020-09-09 [E] [expires: 2022-01-01]
>
> Happy hacking!
> Miguel

Good key and good signature.  Great to have you with us, Miguel!

Kind regards,
Kei


signature.asc
Description: PGP signature

Re: Packaging audacious

[Kei Kebreau]

On Sat, 14 Mar 2020 02:14:45 +0100
Jan Wielkiewicz  wrote:

> Hello,
> 
Hi Jan,

> I'm trying to package the audacious music player, but I encountered a
> problem - in the source directory there are libraries used by
> audacious that is: libaudgui, libaudtag, audtool, libaudcore,
> libaudqt and libguess.
> 
> When build without modifying the source, I get the following error:
> validating RUNPATH of 3 binaries in
> "/gnu/store/6ihw9w6ibs33k6v9dyqxblddwdvyx11m-audacious-3.10.1/lib"...
> /gnu/store/6ihw9w6ibs33k6v9dyqxblddwdvyx11m-audacious-3.10.1/lib/libaudgui.so:
> error: depends on 'libaudcore.so.5', which cannot be found in RUNPATH
> 
> So I tried decoupling it, by making libaudcore package, packaging
> libguess and adding it as libaudcore's input, but it still wants
> to have the file there:
> 
> g++: error: ../libguess/libguess.a: No such file or directory
> Failed to link libaudcore.so!
> 
> How to do this correctly?
> 

You can see my own attempt at packaging audacious a few months ago here
[0].  In the list of configure flags, you'll note that I included a
configure flag that roughly equates to
"LDFLAGS=-Wl,-rpath=/gnu/store/...audacious-3.10.1/lib".  This configure
flag passes a flag ("-rpath") to the linker (through "-Wl") which ensures
that any libraries in the given folder are included in the RUNPATH of any
binaries or libraries.  If you do this, your error *should* disappear.

> P.S. Still waiting for pjproject in Jami to be bumped, they're also
> fixing some annoying bugs.
> 
> 
> Jan Wielkiewicz
> 

[0]: https://issues.guix.gnu.org/issue/37329

Kei Kebreau

Re: Status of Gnome upgrade?

[Kei Kebreau]

Timothy Sample  writes:

> Hi all,
>
> I’ve CC’d Kei who has been looking after this.  Thanks Kei!
>
> Brett Gilio  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> Hi Guix,
>>>
>>> does anyone know what’s holding up the Gnome upgrade?  It’s sad to see
>>> the upgrade languish when it was almost ready for a merge into master.
>>>
>>> Are there any open issues?  Any problems that need solving?  I think
>>> this is a high priority item for Guix.  I’d love to help getting it
>>> done.
>>>
>>> Any ideas?
>>>
>>> --
>>> Ricardo
>>>
>>>
>>
>> I do not know of any open issues, but I agree with Ricardo fully. This
>> is a high priority issue for Guix that needs to get done sooner rather
>> than later.
>>
>> I am also willing to throw my weight behind it, even though I am not a
>> regular GNOME user.
>
> I’m also willing to help.  :)
>
>
> -- Tim

I've been more busy than I'd like over the past few weeks, but I've been
using the "wip-gnome-updates" branch for a while now.  Up to November 27
(the "master" branch hasn't been merged into "wip-gnome-updates" since
then), I haven't noticed any regressions in GNOME's functionality.  I'd
be delighted to merge "wip-gnome-updates" into "master" and begin work
on GNOME 3.34 updates starting late next week.

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Hello again Miguel,

I apologize for the delay.  My semester at university is becoming
busier as final exams get closer!

On Fri, 2019-11-08 at 01:58 +0100, Miguel Arruga Vivas wrote:
> Hi Kei,
...
> > >  - The patch for gedit contains a reference to libgd, wouldn't it
> > > be
> > >clearer for the reader/updater to have it defined in a let
> > > over
> > > the package definition and use the name in native-inputs?
> > >  
> > 
> > I'm not sure.  I don't know if there is an explicit convention for
> > packaging software that is distributed like this, and the examples
> > of
> > this in the code base (that I've seen, at least) define the
> > third-party library the way I've done it here.  I'm open to change
> > on
> > this point though.
> 
> This actually should have been an open question, as I have a patch on
> libosinfo, related with gnome-boxes (patches coming soon) and it
> doesn't feel right for me having usb.ids and pci.ids hidden there, so
> I've put another origin needed (osinfo-db) out there.
> 

After some thought, I believe it is clearer to someone reading the
package to see the origin object defined in the "native-inputs" field
rather than a let over the whole package.  The extra "let" adds a layer
of indirection in reading the code that I'm not sure pays off.  Also,
such a bound variable could be accessed both directly and through the
"native-inputs" field, so that could be confusing as well.

> > >  - Is there any reason to not patch-out the gtk-icon-update-cache
> > >invocations?  If I understand it correctly, this is performed
> > > at
> > >profile level, so makes no sense creating a cache at package
> > > level, isn't it? The patches for quadrapassel, gnome-klotski,
> > > ghex,
> > >gnome-sudoku, gnome-mines, five-or-more and gedit contain
> > > references to it.  Maybe creating a package like
> > > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to
> > > "true" from coreutils would help in the long term.
> > >  
> > 
> > I don't think such a reason exists.  I could add changes that
> > substitute calls to "gtk-icon-update-cache" with "true" for these
> > packages, but I agree that a better solution may be possible.
> > Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache'
> > phase in the relevant build systems?
> 
> Some of these packages already have phases for it on master.  I
> rebased
> your branch onto it (1a9df94cec..fb936351d3), I had to solve two
> merge
> conflicts: devhelp and totem.
> 
> devhelp's patch has only a trivial conflict, as there was no
> arguments
> parameter before.  OTOH, I did not check as much as I should totem's
> last day, as now I have one question here: Who kills the Xvfb server
> on display :1 after the tests?  I see it's a common idiom, but I
> don't
> get why shouldn't the daemon treat it like from any other process and
> wait for it to reach completion (other than technical means, I mean).
> This could be a great place for a #:xorg-for-tests?, should I try?
> 

I really like the idea of an #:xorg-for-tests? flag!  If you can
attempt a patch, I'll do my best to help.

> > > As a final comment, the gnome release cycle and the amount of
> > > packages involved is quite big, so again, thank you.
> > > 
> > > Happy hacking!
> > > Miguel  
> > 
> > Thanks Miguel!  This comment and review means a lot!
> > Kei
> 
> Thank you too
> 
> Best regards,
> Miguel

Re: 'core-updates' Q4 2019

[Kei Kebreau]

On Wed, 2019-11-06 at 12:46 -0500, Leo Famulari wrote:
> On Tue, Nov 05, 2019 at 06:38:05PM -0500, Kei Kebreau wrote:
> > >  - The patch for libdazzle only changes the xorg-server, as it
> > > already
> > >is at version 3.33.90 in master.  It still makes sense as a
> > > patch,
> > >but the title indicates a version downgrade.
> > > 
> > 
> > Good catch!  I'd correct this commit message, but I don't know what
> > the
> > rules are for rewriting commit history on Guix WIP branches.  For
> > now
> > I'll note your comment and leave the message alone.
> 
> You can feel free to rewrite history completely on the WIP branches,
> including commit messages.

`git push --force-with-lease` doesn't seem to work on the WIP branch.
This is a good thing in general, but how do I rewrite history? Do I
just delete the remote WIP branch and recreate a new one with the
appropriate changes?

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Miguel Arruga Vivas  writes:

> Hi Kei,
>
> Kei Kebreau  writes:
>> Update: Please check out the new wip-gnome-updates branch of the Guix
>> git repository for continued updates.  The contents of the notabug.org
>> link given above will be changed to a notice that says to do this.
>
> Thank you very much for this huge effort.  I've been playing with the
> branch and I have a working system, both X11 with GDM and Wayland with
> SDDM (I haven't tried hard enough to set up gdm with wayland as only a
> change to gdm-configuration doesn't seem to have any effect) and your
> branch works great on my machine, do you still have the issue during
> boot?  I haven't found any (new) problem on the applications I've
> tested (x86_64, normal use with almost all of the gnome applications,
> not the games though.)
>

Boot and login worked properly for me after I cleared the contents of my
/var/lib/gdm directory (if it's unclear why that directory matters, see
https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html for
a quick overview).

> Nevertheless, I've been reading the patches and I have a couple of
> comments about them:
>
>  - The patch for libdazzle only changes the xorg-server, as it already
>is at version 3.33.90 in master.  It still makes sense as a patch,
>but the title indicates a version downgrade.
>

Good catch!  I'd correct this commit message, but I don't know what the
rules are for rewriting commit history on Guix WIP branches.  For now
I'll note your comment and leave the message alone.

>  - The patch for gedit contains a reference to libgd, wouldn't it be
>clearer for the reader/updater to have it defined in a let over the
>package definition and use the name in native-inputs?
>

I'm not sure.  I don't know if there is an explicit convention for
packaging software that is distributed like this, and the examples of
this in the code base (that I've seen, at least) define the third-party
library the way I've done it here.  I'm open to change on this point
though.

>  - Is there any reason to not patch-out the gtk-icon-update-cache
>invocations?  If I understand it correctly, this is performed at
>profile level, so makes no sense creating a cache at package level,
>isn't it? The patches for quadrapassel, gnome-klotski, ghex,
>gnome-sudoku, gnome-mines, five-or-more and gedit contain references
>to it.  Maybe creating a package like xorg-server-for-tests
>(perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would
>help in the long term.
>

I don't think such a reason exists.  I could add changes that substitute
calls to "gtk-icon-update-cache" with "true" for these packages, but I
agree that a better solution may be possible.  Perhaps not a package;
maybe a new 'patch-gtk-icon-update-cache' phase in the relevant build
systems?

> As a final comment, the gnome release cycle and the amount of packages
> involved is quite big, so again, thank you.
>
> Happy hacking!
> Miguel

Thanks Miguel!  This comment and review means a lot!
Kei

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Kei Kebreau  writes:

> Timothy Sample  writes:
>
>> Hi Kei,
>>
>> Kei Kebreau  writes:
>>
>>> Anyone want to see the 54 patches and possibly help me root around for
>>> the issue?
>>
>> I would love to take a look at it!  I’ve been a little tied up, but I
>> should have some time tomorrow or the next day.  I think it would be
>> easiest to push it to some world-readable Git repository rather than
>> post all 54 patches here, but I can work with whatever suits you.
>>
>>
>> -- Tim
>
> I've pushed my changes to the following repository for anyone who wants
> to take a look:
>
> https://notabug.org/kei/guix-gnome-updates

Update: Please check out the new wip-gnome-updates branch of the Guix
git repository for continued updates.  The contents of the notabug.org
link given above will be changed to a notice that says to do this.

Thanks,
Kei


signature.asc
Description: PGP signature

Re: 'core-updates' Q4 2019

[Kei Kebreau]

"pelzflorian (Florian Pelz)"  writes:

> On Tue, Oct 22, 2019 at 11:07:06PM -0400, Timothy Sample wrote:
>> There’s a “glib-or-gtk?” flag for the Meson build system.  Setting it to
>> “#t” in the “mutter” package makes GDM and GNOME work in a VM.
>
> Thank you for investigating, I suppose this fixes your issue.
> webkitgtk failed again for me the same way, so I will not test and
> just wait for substitutes.  I am not interested in investigating my
> error.
>
> Regards,
> Florian

With some of the changes mentioned in this email thread, I'm able to
build and log in to GNOME desktop! I've force pushed (sorry!) the
changes to my NotABug git repository today.

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Timothy Sample  writes:

> Hi Kei,
>
> Kei Kebreau  writes:
>
>> Anyone want to see the 54 patches and possibly help me root around for
>> the issue?
>
> I would love to take a look at it!  I’ve been a little tied up, but I
> should have some time tomorrow or the next day.  I think it would be
> easiest to push it to some world-readable Git repository rather than
> post all 54 patches here, but I can work with whatever suits you.
>
>
> -- Tim

I've pushed my changes to the following repository for anyone who wants
to take a look:

https://notabug.org/kei/guix-gnome-updates


signature.asc
Description: PGP signature

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Ricardo Wurmus  writes:

> Kei Kebreau  writes:
>
>> I have news! The good part is that I got 54 packages to build on top of
>> master. The bad part is that when I try to use the resulting packages as
>> my system configuration, my computer gets stuck in tty1, and attempting
>> to switch to Xorg on tty7 leaves my screen frozen though the system is
>> still responsive.
>
> Have you tried removing /var/lib/gdm and the contents of your user
> account’s .local/share/gnome* directories?

I just did, and now tty7 simply shows a copy of tty1 rather than
irreversibly freezing my screen. What files are in /var/lib/gdm and
$HOME/.local/share/gnome that would have such an effect?


signature.asc
Description: PGP signature

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Marius Bakke  writes:

> Kei Kebreau  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Hello Kei,
>>>
>>> Kei Kebreau  skribis:
>>>
>>>> I have the GNOME 3.32 branch! I'm building it on top of the new
>>>> core-updates as you read this message. If everything still builds, I'll
>>>> immediately send my changes to the guix-patches mailing list for review
>>>> and testing.
>>>
>>> Shouldn’t you instead base it on ‘master’ or ‘staging’?
>>>
>>> That may allow us to merge it more quickly, especially if these are only
>>> GNOME-related changes.
>>>
>>> Thanks for working on it!
>>>
>>> Ludo’.
>>
>> Hi Ludovic,
>>
>> Taken individually, most changes on the GNOME 3.32 branch could be
>> pushed to master without too much trouble. The only issues are big
>> changes like
>> upgrading Vala. The following changes would cause a large number of
>> rebuilds:
>>
>> At least 300 rebuilds: python-pygobject, gtk+
>>
>> At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized,
>> python-check-manifest, python-anytree
>>
>> I'll minimize the changes, isolate what I can, and submit the results
>> for review as time allows!
>
> Thanks!  Sounds like something we can handle in a 'staging' cycle.
>
> By the way, GNOME 3.34 is out, and 3.36 is slated for March.  So I think
> we will finally be able to catch up with GNOME again soon...
>
> (let's focus on 3.32 first though ;-))

I have news! The good part is that I got 54 packages to build on top of
master. The bad part is that when I try to use the resulting packages as
my system configuration, my computer gets stuck in tty1, and attempting
to switch to Xorg on tty7 leaves my screen frozen though the system is
still responsive.

Anyone want to see the 54 patches and possibly help me root around for
the issue?


signature.asc
Description: PGP signature

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Ludovic Courtès  writes:

> Hello Kei,
>
> Kei Kebreau  skribis:
>
>> I have the GNOME 3.32 branch! I'm building it on top of the new
>> core-updates as you read this message. If everything still builds, I'll
>> immediately send my changes to the guix-patches mailing list for review
>> and testing.
>
> Shouldn’t you instead base it on ‘master’ or ‘staging’?
>
> That may allow us to merge it more quickly, especially if these are only
> GNOME-related changes.
>
> Thanks for working on it!
>
> Ludo’.

Hi Ludovic,

Taken individually, most changes on the GNOME 3.32 branch could be
pushed to master without too much trouble. The only issues are big changes like
upgrading Vala. The following changes would cause a large number of
rebuilds:

At least 300 rebuilds: python-pygobject, gtk+

At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized,
python-check-manifest, python-anytree

I'll minimize the changes, isolate what I can, and submit the results
for review as time allows!

Thanks,
Kei


signature.asc
Description: PGP signature

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Marius Bakke  writes:

> Guix,
>
> As you know, the "quarterly" core-updates rebuild took almost a full
> year this previous cycle.  There are already 35 commits on the
> 'core-updates-next' branch, and I've heard rumors of a GNOME 3.32 branch
> lurking somewhere.
>
> To prevent this work from rotting away, I propose that we start the
> branch as early as next month.  With luck, users will be able to
> cross-compile Guix System for arbitrary toys come December ;-)
>
> Thoughts?

Hi Marius,

I have the GNOME 3.32 branch! I'm building it on top of the new
core-updates as you read this message. If everything still builds, I'll
immediately send my changes to the guix-patches mailing list for review
and testing.

Thanks,
Kei


signature.asc
Description: PGP signature

Re: Let’s merge ‘core-updates’!

[Kei Kebreau]

Kei Kebreau  writes:

> Jelle Licht  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Hello Guix!
>>>
>>> The ‘core-updates’ branch is in a good shape now, and I think we should
>>> go ahead and merge in the coming days!
>>>
>>> Please try to upgrade your system and your user profile to see if
>>> anything’s wrong for you (I did that a few days ago and I’m happy!).
>>>
>>> You can test, for example, with:
>>>
>>>   guix pull --branch=core-updates -p /tmp/new
>>>   /tmp/new/bin/guix upgrade
>>
>> Building gnucash using core-updates fails:
>>
>> building /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv...
>> \ 'configure' phasebuilder for
>> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
>> with exit code 1
>> build of /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv failed
>> View build log at
>> '/var/log/guix/drvs/zs/x2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv.bz2'.
>> guix upgrade: error: build of
>> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
>>
>> The specific error message is: Unknown CMake command "check_symbol_exists".
>> Relevant part of build log:
>> https://paste.debian.net/1103105/
>>
>> reconfiguring my system and upgrading the other packages in my profile
>> seems to work very well.
>
> I ran into this issue as well. Gnucash verison 3.7 fixes this issue
> [0]. I have a preliminary patch that may be pushed on master. My
> computer is currently attempting to build it on core-updates, but it has
> to build WebKitGTK first.
>
> [0]:
> https://github.com/Gnucash/gnucash/commit/ce6c3c22a15102341ca41ddba2a46ea7daf63f17#diff-e816f3fb553eba8e15e25d30f14cff0d

The patch seems to work. Please see the following issue to try it out:
<https://issues.guix.gnu.org/issue/37554>


signature.asc
Description: PGP signature

Re: Let’s merge ‘core-updates’!

[Kei Kebreau]

Jelle Licht  writes:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> The ‘core-updates’ branch is in a good shape now, and I think we should
>> go ahead and merge in the coming days!
>>
>> Please try to upgrade your system and your user profile to see if
>> anything’s wrong for you (I did that a few days ago and I’m happy!).
>>
>> You can test, for example, with:
>>
>>   guix pull --branch=core-updates -p /tmp/new
>>   /tmp/new/bin/guix upgrade
>
> Building gnucash using core-updates fails:
>
> building /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv...
> \ 'configure' phasebuilder for
> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
> with exit code 1
> build of /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv failed
> View build log at
> '/var/log/guix/drvs/zs/x2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv.bz2'.
> guix upgrade: error: build of
> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
>
> The specific error message is: Unknown CMake command "check_symbol_exists".
> Relevant part of build log:
> https://paste.debian.net/1103105/
>
> reconfiguring my system and upgrading the other packages in my profile
> seems to work very well.

I ran into this issue as well. Gnucash verison 3.7 fixes this issue
[0]. I have a preliminary patch that may be pushed on master. My
computer is currently attempting to build it on core-updates, but it has
to build WebKitGTK first.

[0]: 
https://github.com/Gnucash/gnucash/commit/ce6c3c22a15102341ca41ddba2a46ea7daf63f17#diff-e816f3fb553eba8e15e25d30f14cff0d


signature.asc
Description: PGP signature

Re: core-updates freeze

[Kei Kebreau]

Kei Kebreau  writes:

> Marius Bakke  writes:
>
>> Kei Kebreau  writes:
>>
>>> Ludovic Courtès  writes:
>>>
>>>> Hello!
>>>>
>>>> Marius Bakke  skribis:
>>>>
>>>>> The core-updates branch is now (almost!) ready for prime time.
>>>>
>>>> Yay!
>>>>
>>>>> This is turning out to be one of the biggest merges ever[*], currently
>>>>> representing 433 commits from 15 people, with commits dating back to
>>>>> September last year(!).
>>>>
>>>> Ouch!  This is both impressive and… frightening.  :-)
>>>>
>>>>> Some of the highlights from this branch include:
>>>>>
>>>>> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
>>>>> * GCC7 is now the default compiler
>>>>> * The 'CMake' package comes with full documentation
>>>>> * OpenSSL 1.1 is now the default 'openssl' package
>>>>> * GNOME 3.30
>>>>> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...
>>>>
>>>> Exciting!
>>>>
>>>>> To give everyone a little time to brush up any last-minute patches, as
>>>>> well as let the CI catch up with 'master' and 'staging', I suggest we
>>>>> set a final date for starting the full CI build on *July 9th*, i.e six
>>>>> days from now.  At which point the branch becomes bugfix-only, no new
>>>>> updates or features.
>>>>>
>>>>> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
>>>>> which comes with desirable security and OpenSSL 1.1 compatibility fixes.
>>>>
>>>> July 9th is now behind us, where are we?  I’m currently running:
>>>>
>>>>   guix pull --branch=core-updates -p /tmp/core-updates
>>>>
>>>> so I can give it a shot with my profile and my system.
>>>>
>>>> Is there anything people should pay attention to, or any specific tests
>>>> we should make?
>>>>
>>>> Thank you!
>>>>
>>>> Ludo’.
>>>
>>> I must say, the GNOME 3.30 changes haven't been pushed to core-updates
>>> yet.  There were a number of issues with the updated GNOME desktop as I
>>> last built it.  For example, the displayed time was incorrect, and the
>>> "night light" feature didn't work.  Other issues included failing tests
>>> that I couldn't figure out and just disabled to get the building to
>>> finish.
>>
>> I think many of the failing tests should be fixed with commit
>> ee46474d54a661e87cd501c3fde6e572b3423a60.
>>
>
> Some recent core-updates commits (possibly including this one) fixed at
> least one package's tests.  I'll re-enable a few others and see where
> that leads.
>
>> Wrt the time zone issue, it appears recent Glib refuses to function if
>> /etc/localtime is not a symbolic link, reminiscent of 
>> <https://issues.guix.gnu.org/issue/35746>:
>>
>> https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/glib/gtimezone.c#L443
>>
>> I'm not sure what we should do about it.  Thoughts?
>>
>> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
>> Alternatively, you could make /etc/localtime a symbolic link to
>> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
>> reboot.
>
> I can confirm that both of these methods work, so crude work-arounds
> include
>
>   1.  Setting the system's configured time zone in /etc/timezone
>   2.  Making /etc/localtime a symbolic link to the correct tzdata files
>   3.  Patching glib to read from /etc/localtime if it is a symlink or a
>   file
>
> There are some other issues that I run into immediately, such as an
> Emacs that fails to start when run under X.org (error log attached) and
> a Gnome Control Center that crashes almost immediately after running.
> Any ideas what may be going on here?  I've attached error logs for
> both.
>

The locale issues went away when I updated my profile that was still
based on glibc version 2.28.  Still investigating other issues.

> Thanks,
> Kei


signature.asc
Description: PGP signature

Re: core-updates freeze

[Kei Kebreau]

Marius Bakke  writes:

> Kei Kebreau  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Hello!
>>>
>>> Marius Bakke  skribis:
>>>
>>>> The core-updates branch is now (almost!) ready for prime time.
>>>
>>> Yay!
>>>
>>>> This is turning out to be one of the biggest merges ever[*], currently
>>>> representing 433 commits from 15 people, with commits dating back to
>>>> September last year(!).
>>>
>>> Ouch!  This is both impressive and… frightening.  :-)
>>>
>>>> Some of the highlights from this branch include:
>>>>
>>>> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
>>>> * GCC7 is now the default compiler
>>>> * The 'CMake' package comes with full documentation
>>>> * OpenSSL 1.1 is now the default 'openssl' package
>>>> * GNOME 3.30
>>>> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...
>>>
>>> Exciting!
>>>
>>>> To give everyone a little time to brush up any last-minute patches, as
>>>> well as let the CI catch up with 'master' and 'staging', I suggest we
>>>> set a final date for starting the full CI build on *July 9th*, i.e six
>>>> days from now.  At which point the branch becomes bugfix-only, no new
>>>> updates or features.
>>>>
>>>> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
>>>> which comes with desirable security and OpenSSL 1.1 compatibility fixes.
>>>
>>> July 9th is now behind us, where are we?  I’m currently running:
>>>
>>>   guix pull --branch=core-updates -p /tmp/core-updates
>>>
>>> so I can give it a shot with my profile and my system.
>>>
>>> Is there anything people should pay attention to, or any specific tests
>>> we should make?
>>>
>>> Thank you!
>>>
>>> Ludo’.
>>
>> I must say, the GNOME 3.30 changes haven't been pushed to core-updates
>> yet.  There were a number of issues with the updated GNOME desktop as I
>> last built it.  For example, the displayed time was incorrect, and the
>> "night light" feature didn't work.  Other issues included failing tests
>> that I couldn't figure out and just disabled to get the building to
>> finish.
>
> I think many of the failing tests should be fixed with commit
> ee46474d54a661e87cd501c3fde6e572b3423a60.
>

Some recent core-updates commits (possibly including this one) fixed at
least one package's tests.  I'll re-enable a few others and see where
that leads.

> Wrt the time zone issue, it appears recent Glib refuses to function if
> /etc/localtime is not a symbolic link, reminiscent of 
> <https://issues.guix.gnu.org/issue/35746>:
>
> https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/glib/gtimezone.c#L443
>
> I'm not sure what we should do about it.  Thoughts?
>
> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
> Alternatively, you could make /etc/localtime a symbolic link to
> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
> reboot.

I can confirm that both of these methods work, so crude work-arounds
include

  1.  Setting the system's configured time zone in /etc/timezone
  2.  Making /etc/localtime a symbolic link to the correct tzdata files
  3.  Patching glib to read from /etc/localtime if it is a symlink or a
  file

There are some other issues that I run into immediately, such as an
Emacs that fails to start when run under X.org (error log attached) and
a Gnome Control Center that crashes almost immediately after running.
Any ideas what may be going on here?  I've attached error logs for
both.

Thanks,
Kei

/gnu/store/z2nfaaya7spyji777xn9af9zf5zc6c9k-emacs-26.2/bin/emacs-26.2: 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libm.so.6: version 
`GLIBC_2.29' not found (required by 
/gnu/store/rnck7i21ir6ghvbldk31v0gdyb77g8f6-librsvg-2.40.20/lib/librsvg-2.so.2)
#0  0x7638d8a1 in free ()
   from /gnu/store/n0zcbqrv8fmhgmi6k6mg57kvy19wfdzz-glibc-2.29/lib/libc.so.6
#1  0x77ecf1a5 in g_unix_mount_free ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgio-2.0.so.0
#2  0x00481020 in get_primary_disc_info_start ()
#3  0x00481c93 in cc_info_overview_panel_init ()
#4  0x77de1603 in g_type_create_instance ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#5  0x77dc20a8 in g_object_new_internal ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#6  0x77dc3e00 in g_object_new_

Re: core-updates freeze

[Kei Kebreau]

Ludovic Courtès  writes:

> Hello!
>
> Marius Bakke  skribis:
>
>> The core-updates branch is now (almost!) ready for prime time.
>
> Yay!
>
>> This is turning out to be one of the biggest merges ever[*], currently
>> representing 433 commits from 15 people, with commits dating back to
>> September last year(!).
>
> Ouch!  This is both impressive and… frightening.  :-)
>
>> Some of the highlights from this branch include:
>>
>> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
>> * GCC7 is now the default compiler
>> * The 'CMake' package comes with full documentation
>> * OpenSSL 1.1 is now the default 'openssl' package
>> * GNOME 3.30
>> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...
>
> Exciting!
>
>> To give everyone a little time to brush up any last-minute patches, as
>> well as let the CI catch up with 'master' and 'staging', I suggest we
>> set a final date for starting the full CI build on *July 9th*, i.e six
>> days from now.  At which point the branch becomes bugfix-only, no new
>> updates or features.
>>
>> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
>> which comes with desirable security and OpenSSL 1.1 compatibility fixes.
>
> July 9th is now behind us, where are we?  I’m currently running:
>
>   guix pull --branch=core-updates -p /tmp/core-updates
>
> so I can give it a shot with my profile and my system.
>
> Is there anything people should pay attention to, or any specific tests
> we should make?
>
> Thank you!
>
> Ludo’.

I must say, the GNOME 3.30 changes haven't been pushed to core-updates
yet.  There were a number of issues with the updated GNOME desktop as I
last built it.  For example, the displayed time was incorrect, and the
"night light" feature didn't work.  Other issues included failing tests
that I couldn't figure out and just disabled to get the building to
finish.

If people would like to see my progress, I can send a patch series to
the guix-patches list, but working on this alone has been a slow process
thanks to the long rebuilds that come from working on this branch.  I'd
rather not push a partially-working GNOME, but I also don't want to
hinder the merging of core-updates, so please let me know what course of
action is preferred here.

Thanks,
Kei

Re: GNOME 3.30.x

[Kei Kebreau]

Raghav Gururajan  writes:

> Hello Guix!
>
> I wanted let folks know that, whoever is/will-be working on gnome
> 3.30.x, could try to integrate with the report #35586 (https://issues.g
> uix.gnu.org/issue/35586)? Just a suggestion. ☺
>
> Thank you!
>
> Regards,
> RG.

Hi Raghav!

I'm currently working with a few others to get GNOME 3.30.x in some
working order on core-updates. I'll keep this issue in mind while
testing. Thanks for bringing this issue to our attention!

Kindly,
Kei

Re: Shall we merge wip-gnome3.30 to core-updates?

[Kei Kebreau]

Ricardo Wurmus  writes:

> Hi Kei,
>
>> This could be partly caused by the fact that only some of the GNOME
>> packages were updated to their 3.30 versions, but I don't know how GNOME
>> works well enough to diagnose the issue right away.
>
> What GNOME packages that should be updated haven’t been updated ?
>
>> If this is okay, I can push the updates tomorrow.
>
> That’s fine.  Then we’ll have to add the missing updates in the days
> after that.
>
> --
> Ricardo

Alright! I've pushed the existing GNOME updates to core-updates.

Below is a list of GNOME packages that are propagated in the "gnome"
package definition that aren't at their highest 3.30 bug fix
number or aren't updated to version 3.30 (or for differently-versioned
packages, their latest stable version from what I can tell at a glance):

baobab (gnome.scm)
font-cantarell (fonts.scm)
epiphany (gnome.scm)
file-roller (gnome.scm)
gedit (gnome.scm)
glib-networking (gnome.scm)
gnome-backgrounds (gnome.scm)
gnome-calculator (gnome.scm)
gnome-control-center (gnome.scm)
gnome-online-accounts (gnome.scm)
gnome-session (gnome.scm)
gnome-settings-daemon (gnome.scm)
gnome-terminal (gnome.scm)
gucharmap (gnome.scm)
gvfs (gnome.scm)
nautilus (gnome.scm)
shared-mime-info (gnome.scm)
totem (gnome.scm)
zenity (gnome.scm)

Perhaps there's something there (mismatch between gnome-shell and
gnome-control-center?) that affects the clock.

Re: Shall we merge wip-gnome3.30 to core-updates?

[Kei Kebreau]

Kei Kebreau  writes:

> Marius Bakke  writes:
>
>> @Kei: If you have tested this branch elsewhere, I think it's okay to
>> merge even if it does not yet build on 'core-updates'.
>
> Great! I'll give the branch a test on top of "master" first.

Update on the GNOME updates: while most things seem to be working as they
were before, others may be off in subtle ways. For example, the time
display is UTC and seemingly unchangeable.

This could be partly caused by the fact that only some of the GNOME
packages were updated to their 3.30 versions, but I don't know how GNOME
works well enough to diagnose the issue right away.

If this is okay, I can push the updates tomorrow.


signature.asc
Description: PGP signature

Re: Shall we merge wip-gnome3.30 to core-updates?

[Kei Kebreau]

Marius Bakke  writes:

> Efraim Flashner  writes:
>
>> On Thu, Jun 13, 2019 at 07:09:47PM -0400, Kei Kebreau wrote:
>>> Hello again Marius,
>>> 
>>> Marius Bakke  writes:
>>> 
>>> > Hi Kei,
>>> >
>>> > Kei Kebreau  writes:
>>> >
>> <...>
>>> 
>>> * The samba package seems to require the "rpcgen" binary as part of its
>>> build process, but I don't know which package includes that binary. I
>>> know it appears somewhere in the process of building the "gcc-toolchain"
>>> package, but I'd rather not include that whole package if it isn't
>>> necessary.
>>
>>
>> rpcgen seems to be in glibc

I saw that too, but running "guix build glibc" gives a glibc without the
"rpcgen" binary.

>
> Not since commit 3670ea70e2e932969a3ffc0acf75a714c7b42540 ;-)

Aha!

>
> This patch allows Samba to build.  Other distributions seem to give
> Samba libtirpc as input too, so I haven't finished investigating yet:
>
...
> @Kei: If you have tested this branch elsewhere, I think it's okay to
> merge even if it does not yet build on 'core-updates'.

Great! I'll give the branch a test on top of "master" first.


signature.asc
Description: PGP signature

Re: Shall we merge wip-gnome3.30 to core-updates?

[Kei Kebreau]

Hello again Marius,

Marius Bakke  writes:

> Hi Kei,
>
> Kei Kebreau  writes:
>
>> Hi Marius,
>>
>> Would it be okay to merge the wip-gnome3.30 branch into core-updates
>> after I do some local testing? I'd like to help out with updating GNOME
>> to 3.32, and I'm told that this is the first step towards that goal.
>
> That sounds great, thanks :-)
>
> I suggest we 'freeze' core-updates next weekend and start working on
> merging it.  It has been sitting idle for way too long already!

Some very brief updates:

* I've updated (on my own computer) the perl-net-ssleay package because
tests would freeze indefinitely due to a zombified perl process.

* I've also updated the perl-io-socket-ssl-openssl package because of a
plethora of test failures.

* The samba package seems to require the "rpcgen" binary as part of its
build process, but I don't know which package includes that binary. I
know it appears somewhere in the process of building the "gcc-toolchain"
package, but I'd rather not include that whole package if it isn't
necessary.


signature.asc
Description: PGP signature

Shall we merge wip-gnome3.30 to core-updates?

[Kei Kebreau]

Hi Marius,

Would it be okay to merge the wip-gnome3.30 branch into core-updates
after I do some local testing? I'd like to help out with updating GNOME
to 3.32, and I'm told that this is the first step towards that goal.

Thanks,
Kei

Re: Libre games that might be worth packaging :)

[Kei Kebreau]

swedebugia  writes:

> Hi!
>
> I just went through Julie Marchants excellent list of libre games:
> https://onpon4.github.io/articles/libre-games.html
>
> There are so many! :)
>

I have packages for Adanaxis, Alex the Allegator 4, B.A.L.L.Z.,
Criticalmass and Dopewars. I'll clean them up and upload them when I can.


signature.asc
Description: PGP signature

Re: 01/01: gnu: mit-scheme: Update to 10.1.3.

[Kei Kebreau]

Kei Kebreau  writes:

> Danny Milosavljevic  writes:
>
>> Hi Kei,
>>
>> On Sat, 15 Dec 2018 13:51:43 -0500
>> Kei Kebreau  wrote:
>>
>>> Understood. Thanks to you and Ludovic for cleaning up my small mess.
>>
>> I think it's only a workaround.
>>
>> What happened to the MIT scheme C fallback?  I tried to fix it for
>> good but then
>> the armhf-linux build still didn't work:
>>
>
> I pull the following quote from "Stable Release 10.1" on
> https://www.gnu.org/software/mit-scheme/release.html:
>
> "The portable C version is not included in this release because we were
> unable to get it working in time."
>
> Based on the above quote I'm assuming the C fallback is coming back, so
> according to Mark's evaluation I shouldn't have removed armhf-linux from
> the supported-systems.
>
>> If there was once a architecture-independent MIT scheme, let's use that one 
>> to
>> bootstrap the newer version, if possible.
>>
>
> It is possible. The architecture-independent version is the C-based
> one. I'll look into your patch and follow changes upstream to see about
> repairing the situation ASAP.

This patch gives an error related to an attempt to subtract two
incompatible pointers. The MIT/GNU Scheme home page mentions that the
SVM build is for 64-bit unix systems, however.

From c3a7491dceb7cb81651a3c7a83cea0bb736c6738 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Mon, 17 Dec 2018 09:37:46 -0500
Subject: [PATCH] gnu: mit-scheme: Add SVM build.

* gnu/packages/scheme.scm (mit-scheme-source-directory): Adjust for the time
being.
* gnu/packages/scheme.scm (mit-scheme)[arguments]: Adjust 'build' phase
accordingly.
[inputs]: Adjust catch-all case in "source" input accordingly.
[supported-systems]: Add armhf-linux.
---
 gnu/packages/scheme.scm | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/scheme.scm b/gnu/packages/scheme.scm
index 3c688e120..06812e2ef 100644
--- a/gnu/packages/scheme.scm
+++ b/gnu/packages/scheme.scm
@@ -74,7 +74,7 @@
  (if (or (string-prefix? "x86_64" system)
  (string-prefix? "i686" system))
  ""
- "c-")
+ "")
  version))
 
 (define-public mit-scheme
@@ -113,8 +113,7 @@
(if (or (string-prefix? "x86_64" system)
(string-prefix? "i686" system))
(invoke "make" "compile-microcode")
-   (invoke "./etc/make-liarc.sh"
-   (string-append "--prefix=" out)))
+   (invoke "make"))
#t)))
  (add-after 'configure 'configure-doc
(lambda* (#:key outputs inputs #:allow-other-keys)
@@ -173,7 +172,7 @@
 ("i686-linux"
  (string-append version "-i386"))
 (_
- (string-append "c-" version)))
+ (string-append version "-svm1")))
   ".tar.gz"))
   (sha256
(match (%current-system)
@@ -184,13 +183,11 @@
   (base32
"05sjyz90xxfnmi87qv8x0yx0fcallnzl1dciygdafp317pn489is"))
  (_
-   (base32
-""
+  (base32
+   "0ka3l1m2jlyszm8kkv9pw33izmhw5j52rbfxx4zfqmwn7a5b3ays"
 
 ;; Fails to build on MIPS, see <http://bugs.gnu.org/18221>.
-;; Also, the portable C version of MIT/GNU Scheme did not work in time for
-;; release in version 10.1.
-(supported-systems '("x86_64-linux" "i686-linux"))
+(supported-systems '("x86_64-linux" "i686-linux" "armhf-linux"))
 
 (home-page "https://www.gnu.org/software/mit-scheme/;)
 (synopsis "A Scheme implementation with integrated editor and debugger")
-- 
2.19.2



signature.asc
Description: PGP signature

Re: 01/01: gnu: mit-scheme: Update to 10.1.3.

[Kei Kebreau]

Danny Milosavljevic  writes:

> Hi Kei,
>
> On Sat, 15 Dec 2018 13:51:43 -0500
> Kei Kebreau  wrote:
>
>> Understood. Thanks to you and Ludovic for cleaning up my small mess.
>
> I think it's only a workaround.
>
> What happened to the MIT scheme C fallback?  I tried to fix it for good but 
> then
> the armhf-linux build still didn't work:
>

I pull the following quote from "Stable Release 10.1" on
https://www.gnu.org/software/mit-scheme/release.html:

"The portable C version is not included in this release because we were
unable to get it working in time."

Based on the above quote I'm assuming the C fallback is coming back, so
according to Mark's evaluation I shouldn't have removed armhf-linux from
the supported-systems.

> If there was once a architecture-independent MIT scheme, let's use that one to
> bootstrap the newer version, if possible.
>

It is possible. The architecture-independent version is the C-based
one. I'll look into your patch and follow changes upstream to see about
repairing the situation ASAP.


signature.asc
Description: PGP signature

Re: 01/01: gnu: mit-scheme: Update to 10.1.3.

[Kei Kebreau]

Mark H Weaver  writes:

> Hi Kei,
>
> guix-comm...@gnu.org writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit d870cc5e8acfed6fee318a66c3ffc7244aa376a1
>> Author: Kei Kebreau 
>> Date:   Thu Dec 13 08:32:50 2018 -0500
>>
>> gnu: mit-scheme: Update to 10.1.3.
>> 
>> * gnu/packages/scheme.scm (mit-scheme): Update to 10.1.3.
>> [arguments]: Update 'unpack', 'configure-doc', and 'install-doc' phases
>> accordingly.
>> [supported-systems]: Limit to i686-linux and x86_64-linux.
>
> [...]
>
>> @@ -177,24 +171,21 @@
>>  ("x86_64-linux"
>>   (string-append version "-x86-64"))
>>  ("i686-linux"
>> - (string-append version "-i386"))
>> -(_
>> - (string-append "c-" version)))
>> + (string-append version "-i386")))
>>".tar.gz"))
>>(sha256
>> (match (%current-system)
>>   ("x86_64-linux"
>>(base32
>> -   "1skzxxhr0iq96bf0j5m7mvf3i4sppfyfa6gpqn34mwgkw1fx8274"))
>> +   "03m7cc035w3avs91j2pcz9f15ssgvgp3rm045d1vbydqrkzfyw8k"))
>>   ("i686-linux"
>>(base32
>> -   "1fmlpnhf5a75db93phajh4ysbdgrgl72v45lk3kznriprl0a7jc6"))
>> - (_
>> -  (base32
>> -   
>> "0w5ib5vsidihb4hb6fma3sp596ykr8izagm57axvgd6lqzwicsjg"
>> +   
>> "05sjyz90xxfnmi87qv8x0yx0fcallnzl1dciygdafp317pn489is"
>
> Without the fallback cases in these 'match' forms, this package
> definition raises an exception when asked to generate the derivation on
> non-Intel systems.  Ludovic partly reverted your changes here:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=966629a114fd90153784dfdbe5e332e0ac94f1bc
>
> This commit also broke the 'guix' package on armhf-linux, and probably
> on other non-Intel systems as well,
>
>   https://hydra.gnu.org/build/3281991
>
> although admittedly I found this surprising.
>

For some reason, the removing the fallback case from the 'match' forms
didn't set off any alarm bells in my mind. My apologies.

>>  ;; Fails to build on MIPS, see <http://bugs.gnu.org/18221>.
>> -(supported-systems '("x86_64-linux" "i686-linux" "armhf-linux"))
>> + ;; Also, the portable C version of MIT/GNU Scheme did not work in
>> time for
>> +;; release in version 10.1.
>> +(supported-systems '("x86_64-linux" "i686-linux"))
>
> In general, please do not remove a system from 'supported-systems'
> unless there is good reason to believe that it would be prohibitively
> difficult to support the package on that system.  If there is merely a
> bug or some minor unfinished work that prevents a package from building
> on a given system, that is not sufficient grounds to remove it from
> 'supported-systems'.
>
>Thanks,
>  Mark

Understood. Thanks to you and Ludovic for cleaning up my small mess.

Re: Octave & QtOctave

[Kei Kebreau]

Kei Kebreau  writes:

> Alex Vong  writes:
>
>> Kei Kebreau  writes:
>>
>>> Alex Vong  writes:
>>>
>>>> Kei Kebreau  writes:
>>>>
>>>>> Alex Vong  writes:
>>>>>
>>>>>> Hello Kei,
>>>>>>
>>>>>> Kei Kebreau  writes:
>>>>>>
>>>>>> [...]
>>>>>>>
>>>>>>> Here are two tentative patches that make the changes we've discussed.
>>>>>>> Also, should we make a deprecated-package definition for qtoctave?
>>>>>>
>>>>>> I think some additional changes related to "(assoc-ref inputs ..."
>>>>>> needed to be made. Otherwise, looks good to me! Here is a patch I made
>>>>>> earlier but it was not tested, feel free to cherry-pick what is needed:
>>>>>>
>>>>>> From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001
>>>>>> From: Alex Vong 
>>>>>> Date: Mon, 3 Dec 2018 03:39:40 +0800
>>>>>> Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to
>>>>>>  "octave".
>>>>>>
>>>>>> * gnu/packages/maths.scm (octave): Rename to octave-cli.
>>>>>> [name]: Change to "octave-cli".
>>>>>> (qtoctave): Rename to octave.
>>>>>> [name]: Change to "octave".
>>>>>> [inherit]: Inherit from octave-cli.
>>>>>> [source]: Likewise.
>>>>>> [inputs]: Likewise.
>>>>>> [native-inputs]: Likewise.
>>>>>> [arguments]: Likewise.
>>>>>> (flann): Update accordingly.
>>>>>> * gnu/packages/engineering.scm (qucs): Likewise.
>>>>>> (qucs-s): Likewise.
>>>>>> * gnu/packages/machine-learning.scm (shogun): Likewise.
>>>>>
>>>>> ...
>>>>>
>>>>>> - ("octave" ,octave)
>>>>>> + ("octave-cli" ,octave-cli)
>>>>>
>>>>> I see the main difference is that you've replace the package's
>>>>> associated string to "octave-cli" as well as the name, whereas I've only
>>>>> replaced the package name. Should I replace the associated package
>>>>> string, too?
>>>>
>>>> According to the manual "6.7.2 Package Naming", the associated string is
>>>> used for package management commands such as 'guix package' and 'guix
>>>> build'. Therefore, I think we should change them as well, so that the
>>>> users can install the packages using the command
>>>> "guix package -i octave-cli" and "guix package -i octave"
>>>> respectively. What do you think?
>>>
>>> Maybe this is true when manipulating the package definition, but that
>>> doesn't seem to be the case in general. When I run
>>> "./pre-inst-env guix package --show=shogun", for example,
>>> "octave-cli@4.4.1" is listed as a dependency, even though "octave" is
>>> the associated name in shogun's input list.
>>>
>>> To be clear, I've changed the string for octave's and octave-cli's
>>> package name in their respective package definitions, but I haven't
>>> changed the string in the input lists of octave-cli's dependent
>>> packages.
>>>
>>> I'm inclined to follow convention when it comes to this, and other
>>> packages in input lists seem to omit extensions to the base name of the
>>> package in their assoc-lists. For example, ("gettext", gettext-minimal)
>>> and ("python", python-minimal-wrapper) are common inputs for packages.
>>
>> I think you are right! This was a misunderstanding on my part. I thought
>> the association string in the input lists must be the same as the
>> package name, but appraently this is not the case.
>>
>> Take gettext-minimal as an example,
>> its variable name is 'gettext-minimal',
>> its package name is "gettext-minimal",
>> but its input name is "gettext".
>
> Precisely! Unless anyone else has concerns that should be brought to
> light, I'll be committing this within the next 2 days.
>
> Thank you to all involved so far.

I've pushed this to master. Thanks again!


signature.asc
Description: PGP signature

Re: Octave & QtOctave

[Kei Kebreau]

Alex Vong  writes:

> Kei Kebreau  writes:
>
>> Alex Vong  writes:
>>
>>> Kei Kebreau  writes:
>>>
>>>> Alex Vong  writes:
>>>>
>>>>> Hello Kei,
>>>>>
>>>>> Kei Kebreau  writes:
>>>>>
>>>>> [...]
>>>>>>
>>>>>> Here are two tentative patches that make the changes we've discussed.
>>>>>> Also, should we make a deprecated-package definition for qtoctave?
>>>>>
>>>>> I think some additional changes related to "(assoc-ref inputs ..."
>>>>> needed to be made. Otherwise, looks good to me! Here is a patch I made
>>>>> earlier but it was not tested, feel free to cherry-pick what is needed:
>>>>>
>>>>> From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001
>>>>> From: Alex Vong 
>>>>> Date: Mon, 3 Dec 2018 03:39:40 +0800
>>>>> Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to
>>>>>  "octave".
>>>>>
>>>>> * gnu/packages/maths.scm (octave): Rename to octave-cli.
>>>>> [name]: Change to "octave-cli".
>>>>> (qtoctave): Rename to octave.
>>>>> [name]: Change to "octave".
>>>>> [inherit]: Inherit from octave-cli.
>>>>> [source]: Likewise.
>>>>> [inputs]: Likewise.
>>>>> [native-inputs]: Likewise.
>>>>> [arguments]: Likewise.
>>>>> (flann): Update accordingly.
>>>>> * gnu/packages/engineering.scm (qucs): Likewise.
>>>>> (qucs-s): Likewise.
>>>>> * gnu/packages/machine-learning.scm (shogun): Likewise.
>>>>
>>>> ...
>>>>
>>>>> - ("octave" ,octave)
>>>>> + ("octave-cli" ,octave-cli)
>>>>
>>>> I see the main difference is that you've replace the package's
>>>> associated string to "octave-cli" as well as the name, whereas I've only
>>>> replaced the package name. Should I replace the associated package
>>>> string, too?
>>>
>>> According to the manual "6.7.2 Package Naming", the associated string is
>>> used for package management commands such as 'guix package' and 'guix
>>> build'. Therefore, I think we should change them as well, so that the
>>> users can install the packages using the command
>>> "guix package -i octave-cli" and "guix package -i octave"
>>> respectively. What do you think?
>>
>> Maybe this is true when manipulating the package definition, but that
>> doesn't seem to be the case in general. When I run
>> "./pre-inst-env guix package --show=shogun", for example,
>> "octave-cli@4.4.1" is listed as a dependency, even though "octave" is
>> the associated name in shogun's input list.
>>
>> To be clear, I've changed the string for octave's and octave-cli's
>> package name in their respective package definitions, but I haven't
>> changed the string in the input lists of octave-cli's dependent
>> packages.
>>
>> I'm inclined to follow convention when it comes to this, and other
>> packages in input lists seem to omit extensions to the base name of the
>> package in their assoc-lists. For example, ("gettext", gettext-minimal)
>> and ("python", python-minimal-wrapper) are common inputs for packages.
>
> I think you are right! This was a misunderstanding on my part. I thought
> the association string in the input lists must be the same as the
> package name, but appraently this is not the case.
>
> Take gettext-minimal as an example,
> its variable name is 'gettext-minimal',
> its package name is "gettext-minimal",
> but its input name is "gettext".

Precisely! Unless anyone else has concerns that should be brought to
light, I'll be committing this within the next 2 days.

Thank you to all involved so far.


signature.asc
Description: PGP signature

Re: Octave & QtOctave

[Kei Kebreau]

Alex Vong  writes:

> Kei Kebreau  writes:
>
>> Alex Vong  writes:
>>
>>> Hello Kei,
>>>
>>> Kei Kebreau  writes:
>>>
>>> [...]
>>>>
>>>> Here are two tentative patches that make the changes we've discussed.
>>>> Also, should we make a deprecated-package definition for qtoctave?
>>>
>>> I think some additional changes related to "(assoc-ref inputs ..."
>>> needed to be made. Otherwise, looks good to me! Here is a patch I made
>>> earlier but it was not tested, feel free to cherry-pick what is needed:
>>>
>>> From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001
>>> From: Alex Vong 
>>> Date: Mon, 3 Dec 2018 03:39:40 +0800
>>> Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to
>>>  "octave".
>>>
>>> * gnu/packages/maths.scm (octave): Rename to octave-cli.
>>> [name]: Change to "octave-cli".
>>> (qtoctave): Rename to octave.
>>> [name]: Change to "octave".
>>> [inherit]: Inherit from octave-cli.
>>> [source]: Likewise.
>>> [inputs]: Likewise.
>>> [native-inputs]: Likewise.
>>> [arguments]: Likewise.
>>> (flann): Update accordingly.
>>> * gnu/packages/engineering.scm (qucs): Likewise.
>>> (qucs-s): Likewise.
>>> * gnu/packages/machine-learning.scm (shogun): Likewise.
>>
>> ...
>>
>>> - ("octave" ,octave)
>>> + ("octave-cli" ,octave-cli)
>>
>> I see the main difference is that you've replace the package's
>> associated string to "octave-cli" as well as the name, whereas I've only
>> replaced the package name. Should I replace the associated package
>> string, too?
>
> According to the manual "6.7.2 Package Naming", the associated string is
> used for package management commands such as 'guix package' and 'guix
> build'. Therefore, I think we should change them as well, so that the
> users can install the packages using the command
> "guix package -i octave-cli" and "guix package -i octave"
> respectively. What do you think?

Maybe this is true when manipulating the package definition, but that
doesn't seem to be the case in general. When I run
"./pre-inst-env guix package --show=shogun", for example,
"octave-cli@4.4.1" is listed as a dependency, even though "octave" is
the associated name in shogun's input list.

To be clear, I've changed the string for octave's and octave-cli's
package name in their respective package definitions, but I haven't
changed the string in the input lists of octave-cli's dependent
packages.

I'm inclined to follow convention when it comes to this, and other
packages in input lists seem to omit extensions to the base name of the
package in their assoc-lists. For example, ("gettext", gettext-minimal)
and ("python", python-minimal-wrapper) are common inputs for packages.


signature.asc
Description: PGP signature

Re: Octave & QtOctave

[Kei Kebreau]

Alex Vong  writes:

> Hello Kei,
>
> Kei Kebreau  writes:
>
> [...]
>>
>> Here are two tentative patches that make the changes we've discussed.
>> Also, should we make a deprecated-package definition for qtoctave?
>
> I think some additional changes related to "(assoc-ref inputs ..."
> needed to be made. Otherwise, looks good to me! Here is a patch I made
> earlier but it was not tested, feel free to cherry-pick what is needed:
>
> From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001
> From: Alex Vong 
> Date: Mon, 3 Dec 2018 03:39:40 +0800
> Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to
>  "octave".
>
> * gnu/packages/maths.scm (octave): Rename to octave-cli.
> [name]: Change to "octave-cli".
> (qtoctave): Rename to octave.
> [name]: Change to "octave".
> [inherit]: Inherit from octave-cli.
> [source]: Likewise.
> [inputs]: Likewise.
> [native-inputs]: Likewise.
> [arguments]: Likewise.
> (flann): Update accordingly.
> * gnu/packages/engineering.scm (qucs): Likewise.
> (qucs-s): Likewise.
> * gnu/packages/machine-learning.scm (shogun): Likewise.

...

> - ("octave" ,octave)
> + ("octave-cli" ,octave-cli)

I see the main difference is that you've replace the package's
associated string to "octave-cli" as well as the name, whereas I've only
replaced the package name. Should I replace the associated package
string, too?


signature.asc
Description: PGP signature

Re: Octave & QtOctave

[Kei Kebreau]

swedebugia  writes:

> On 2018-12-02 20:28, Kei Kebreau wrote:
> snip
>
>> Here are two tentative patches that make the changes we've discussed.
>
> Nice
>
>> Also, should we make a deprecated-package definition for qtoctave?
>
> Yes, that sounds like a good idea to me.

Here's the new second patch, then.

>From 663441af034b6bd7a3bd24866d3721cac21be221 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:37:50 -0500
Subject: [PATCH 2/2] gnu: Rename "qtoctave" to "octave".

* gnu/packages/maths.scm (qtoctave): Define in terms of 'deprectated-package'.
(octave): New variable, formerly known as "qtoctave".
---
 gnu/packages/maths.scm | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index bcd70232f..67be8b807 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1497,9 +1497,9 @@ Work may be performed both at the interactive command-line as well as via
 script files.")
 (license license:gpl3+)))
 
-(define-public qtoctave
+(define-public octave
   (package (inherit octave-cli)
-(name "qtoctave")
+(name "octave")
 (source (origin
   (inherit (package-source octave-cli
 (inputs
@@ -1525,6 +1525,9 @@ script files.")
   "qscintilla2_qt5"))
#t
 
+(define-public qtoctave
+  (deprecated-package "qtoctave" octave))
+
 (define-public opencascade-oce
   (package
 (name "opencascade-oce")
-- 
2.19.2

Re: Octave & QtOctave

[Kei Kebreau]

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

> Kei Kebreau  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hello,
>>>
>>> n...@n0.is skribis:
>>>
>>>> names for packages are (mostly) random, although in some
>>>> cases following classiifcations (see python-*, r-*, ...).
>>>
>>> That randomness is very limited in practice, if I may.  :-)
>>>
>>>   https://gnu.org/software/guix/manual/en/html_node/Package-Naming.html
>>>
>>> “qtoctave” was added by Kei.  WDYT about the naming issue, Kei?
>>>
>>> Ludo’.
>>
>> I agree with ng0 that Octave and its GUI interface should be kept in
>> separate packages, as the difference in size is more than 5000 MiB.
>> I also agree that the GUI package should be named "octave", but I don't
>> know whether the CLI package should be named "octave-minimal" or
>> "octave-cli".  I find myself leaning toward "octave-cli" because the CLI
>> package does include some non-essential dependencies.
>
> Makes sense to me.  If others agree with this (“octave-cli” rather than
> “octave-minimal”), go ahead!
>
> Ludo’.

Sorry, the last message didn't include the earlier contributors to this
thread.

Here are two tentative patches that make the changes we've discussed.
Also, should we make a deprecated-package definition for qtoctave?

>From f31adbdaa5582e1c2d02adc2e7fc6afa2fc6e171 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:15:14 -0500
Subject: [PATCH 1/2] gnu: Rename "octave" to "octave-cli".

* gnu/packages/maths.scm (octave): Rename to...
(octave-cli): ...this.
[name]: Change to "octave-cli".
(qtoctave): Inherit from octave-cli.
(flann)[inputs]: Adjust accordingly.
* gnu/packages/engineering.scm (qucs)[inputs]: Likewise.
(qucs-s)[inputs]: Likewise.
* gnu/packages/machine-learning.scm (shogun)[inputs]: Likewise.
---
 gnu/packages/engineering.scm  |  4 ++--
 gnu/packages/machine-learning.scm |  2 +-
 gnu/packages/maths.scm| 16 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 008035649..761cc1282 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -1702,7 +1702,7 @@ parallel computing platforms.  It also supports serial execution.")
  ("gcc-toolchain" ,gcc-toolchain)
  ("iverilog" ,iverilog)
  ("libtool" ,libtool)
- ("octave" ,octave)
+ ("octave" ,octave-cli)
  ("qt4" ,qt-4)
  ("sed" ,sed)))
   (home-page "http://qucs.sourceforge.net/;)
@@ -1832,7 +1832,7 @@ simulations are also supported.")
("libtool" ,libtool)
("mpi" ,openmpi)
("ngspice" ,ngspice)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("qt4" ,qt-4)
("qucs" ,qucs)
("sed" ,sed)
diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm
index a7df9dce0..c4a25eabd 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -493,7 +493,7 @@ sample proximities between pairs of cases.")
  `(("python" ,python)
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("swig" ,swig)
("eigen" ,eigen)
("hdf5" ,hdf5)
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 3dabef441..bcd70232f 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1413,9 +1413,9 @@ can solve two kinds of problems:
 
 ;; For a fully featured Octave, users are strongly recommended also to install
 ;; the following packages: less, ghostscript, gnuplot.
-(define-public octave
+(define-public octave-cli
   (package
-(name "octave")
+(name "octave-cli")
 (version "4.4.1")
 (source
  (origin
@@ -1498,20 +1498,20 @@ script files.")
 (license license:gpl3+)))
 
 (define-public qtoctave
-  (package (inherit octave)
+  (package (inherit octave-cli)
 (name "qtoctave")
 (source (origin
-  (inherit (package-source octave
+  (inherit (package-source octave-cli
 (inputs
  `(("qscintilla" ,qscintilla)
("qt" ,qtbase)
-   ,@(package-inputs octave)))
+   ,@(package-inputs octave-cli)))
 (native-inputs
  `(("qttools" , qttools) ;for lrelease
("texlive" ,texlive) ;for texi2dvi
-   ,@(package-native-inputs octa

Re: Octave & QtOctave

[Kei Kebreau]

swedebugia  writes:

> On 2018-11-28 11:47, Ludovic Courtès wrote:
>> Kei Kebreau  skribis:
> snip
>
>>>
>>> I agree with ng0 that Octave and its GUI interface should be kept in
>>> separate packages, as the difference in size is more than 5000 MiB.
>>> I also agree that the GUI package should be named "octave", but I don't
>>> know whether the CLI package should be named "octave-minimal" or
>>> "octave-cli".  I find myself leaning toward "octave-cli" because the CLI
>>> package does include some non-essential dependencies.
>>
>> Makes sense to me.  If others agree with this (“octave-cli” rather than
>> “octave-minimal”), go ahead!
>
> I agree.

Here are two tentative patches that make the changes we've discussed.
Also, should we make a deprecated-package definition for qtoctave?

>From f31adbdaa5582e1c2d02adc2e7fc6afa2fc6e171 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:15:14 -0500
Subject: [PATCH 1/2] gnu: Rename "octave" to "octave-cli".

* gnu/packages/maths.scm (octave): Rename to...
(octave-cli): ...this.
[name]: Change to "octave-cli".
(qtoctave): Inherit from octave-cli.
(flann)[inputs]: Adjust accordingly.
* gnu/packages/engineering.scm (qucs)[inputs]: Likewise.
(qucs-s)[inputs]: Likewise.
* gnu/packages/machine-learning.scm (shogun)[inputs]: Likewise.
---
 gnu/packages/engineering.scm  |  4 ++--
 gnu/packages/machine-learning.scm |  2 +-
 gnu/packages/maths.scm| 16 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 008035649..761cc1282 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -1702,7 +1702,7 @@ parallel computing platforms.  It also supports serial execution.")
  ("gcc-toolchain" ,gcc-toolchain)
  ("iverilog" ,iverilog)
  ("libtool" ,libtool)
- ("octave" ,octave)
+ ("octave" ,octave-cli)
  ("qt4" ,qt-4)
  ("sed" ,sed)))
   (home-page "http://qucs.sourceforge.net/;)
@@ -1832,7 +1832,7 @@ simulations are also supported.")
("libtool" ,libtool)
("mpi" ,openmpi)
("ngspice" ,ngspice)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("qt4" ,qt-4)
("qucs" ,qucs)
("sed" ,sed)
diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm
index a7df9dce0..c4a25eabd 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -493,7 +493,7 @@ sample proximities between pairs of cases.")
  `(("python" ,python)
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("swig" ,swig)
("eigen" ,eigen)
("hdf5" ,hdf5)
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 3dabef441..bcd70232f 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1413,9 +1413,9 @@ can solve two kinds of problems:
 
 ;; For a fully featured Octave, users are strongly recommended also to install
 ;; the following packages: less, ghostscript, gnuplot.
-(define-public octave
+(define-public octave-cli
   (package
-(name "octave")
+(name "octave-cli")
 (version "4.4.1")
 (source
  (origin
@@ -1498,20 +1498,20 @@ script files.")
 (license license:gpl3+)))
 
 (define-public qtoctave
-  (package (inherit octave)
+  (package (inherit octave-cli)
 (name "qtoctave")
 (source (origin
-  (inherit (package-source octave
+  (inherit (package-source octave-cli
 (inputs
  `(("qscintilla" ,qscintilla)
("qt" ,qtbase)
-   ,@(package-inputs octave)))
+   ,@(package-inputs octave-cli)))
 (native-inputs
  `(("qttools" , qttools) ;for lrelease
("texlive" ,texlive) ;for texi2dvi
-   ,@(package-native-inputs octave)))
+   ,@(package-native-inputs octave-cli)))
 (arguments
- (substitute-keyword-arguments (package-arguments octave)
+ (substitute-keyword-arguments (package-arguments octave-cli)
((#:phases phases)
     `(modify-phases ,phases
(add-before 'configure 'patch-qscintilla-library-name
@@ -3577,7 +3577,7 @@ in finite element programs.")
  `(("unzip" ,unzip)))
 (inputs
  `(("hdf5" ,hdf5)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("python" ,python-2) ; print

Re: Octave & QtOctave

[Kei Kebreau]

Hello all,

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

> Hello,
>
> n...@n0.is skribis:
>
>> names for packages are (mostly) random, although in some
>> cases following classiifcations (see python-*, r-*, ...).
>
> That randomness is very limited in practice, if I may.  :-)
>
>   https://gnu.org/software/guix/manual/en/html_node/Package-Naming.html
>
> “qtoctave” was added by Kei.  WDYT about the naming issue, Kei?
>
> Ludo’.

I agree with ng0 that Octave and its GUI interface should be kept in
separate packages, as the difference in size is more than 5000 MiB.
I also agree that the GUI package should be named "octave", but I don't
know whether the CLI package should be named "octave-minimal" or
"octave-cli".  I find myself leaning toward "octave-cli" because the CLI
package does include some non-essential dependencies.

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Kei Kebreau]

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

> Hello Kei,
>
> Kei Kebreau  skribis:
>
>> I am interested in helping with non-x86_64 issues. Particularly, helping
>> with i686-related changes should be just a change in workflow, but I'm
>> interested in obtaining freedom-respecting non-x86 hardware (or at least
>> using a virtual machine as close as possible to real hardware
>> configurations). Any recommendation or links for where I can get a
>> Yeeloong laptop or what freedom-respecting armhf computers are
>> available?
>
> Without having actual hardware, you can use the qemu-binfmt service on
> your machine (info "(guix) Virtualization Services").  It’s slow, but it
> allows you to reproduce and debug issues for other architectures.
>
> Thanks,
> Ludo’.

Wow, this is excellent! Thanks for the tip.


signature.asc
Description: PGP signature

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Kei Kebreau]

Mark H Weaver  writes:

> Hi Ludovic,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver  skribis:
>>
>>> The end result is that the wishes of the x86_64-using majority are the
>>> only ones that seem to matter in this community, and other users are
>>> frequently left in a bad spot.  This makes it increasingly unlikely that
>>> we'll ever gain a significant number of non-x86_64 users.
>>
>> This kind of rant is really unhelpful.  You’re shouting at someone who
>> *is* doing the work of keeping things running.
>
> I wasn't actually shouting, but in retrospect I can see how it came off
> that way.  I apologize for any hurt feelings that I caused.
>
> This is not Marius' fault, and I didn't intend to target him
> specifically.  I'm grateful for the large amount of important work that
> he does on Guix.
>
> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.
>
> Portability is important to the long-term health of the free software
> movement.  Especially given that fact that Intel has long ago stopped
> producing processors that can be used without large amounts of nonfree
> software (including the Intel Management Engine), I think we should work
> to ensure that Guix works well for users of non-x86_64 systems.
>
> The origin of this problem is not in the Guix project.  Ultimately, it's
> due to the fact that x86_64 has far too much market share among
> GNU/Linux developers, and therefore the upstream projects upon which
> Guix depends are not being sufficiently tested on other platforms.
>
> However, there is one aspect of Guix that is greatly exacerbating this
> problem: our impatience to always have the latest software, even if it
> breaks other systems, is a serious problem in my view.
>
> It means that if I want to ensure that Guix works well for i686 or armhf
> users, then I would need to start trying to use Guix on those systems
> for real work, which at the present time would entail almost
> single-handedly fixing all of the portability bugs in all of the
> software that I use, at the full pace of upstream development.  I would
> need to keep this up for long enough to make Guix appear to be a safe
> choice for i686 or armhf users, so that some of them might help work on
> these portability issues in the future.
>
> Another problem is that Guile 2.2's compiler has become so heavy that
> it's nearly unbearable to use on slower hardware.  Simply running "make"
> in my Guix git checkout after updating on my mips-based Yeeloong is so
> slow that I'm in the habit of letting it run overnight.
>
> So again, and I'm saying this calmly but with great concern: given the
> current priorities of the project, I could not recommend Guix to users
> of non-x86_64 architectures, and I don't see how we can fix that without
> attracting more developers who use those architectures.  However, I
> don't see how we could attract those developers if we continue to
> prioritize "moving forward" at full speed for x86_64 users, even when it
> breaks other systems.
>
>> Generalizations about “this community” obviously make no sense.  You are
>> a part of “this community” so it cares just as much as you do.
>
> By that reasoning, since I'm part of the community of humans on planet
> Earth, the community of humans on planet Earth therefore cares as much
> about free software as I do.
>
> When I suggest that the community would not take certain suggestions
> seriously, e.g. the suggestion to block upgrades or merges that would
> break non-x86_64 systems, that statement has some meaning.  I means that
> I expect that most people here would disagree, and that the maintainers
> would rule in favor of "moving forward" at full speed, and that it will
> be the responsibility of the tiny number of non-x86_64 Guix users to fix
> portability bugs as quickly as needed so that the x86_64-using majority
> need not suffer any delays.  The problem is, we would need a *lot* more
> non-x86_64 developers in our community to make that work, and we cannot
> attract those developers given the current policies.
>
>> Please let’s work in a friendly manner towards finding solutions to the
>> problems.
>
> I'm open to suggestions.  Do you see any solution to the problem of how
> to attract more non-x86_64 users, given our current policies?
>
>  Thanks,
>Mark

I am interested in helping with non-x86_64 issues. Particularly, helping
with i686-related changes should be just a change in workflow, but I'm
interested in obtaining freedom-respecting non-x86 hardware (or at least
using a virtual machine as close as possible to real hardware
configurations). Any recommendation or links for where I can get a
Yeeloong laptop or what freedom-respecting armhf computers are
available?


signature.asc
Description: PGP signature

Re: Broken alsa-utils?

[Kei Kebreau]

Pierre Neidhardt  writes:

> Since about a week or two ago, the alsa-utils tools such as amixer and
> alsamixer fail to start:
>
>> amixer
> ALSA lib dlmisc.c:292:(snd1_dlobj_cache_get) Cannot open shared library 
> /gnu/store/5cbff8yc8f8qgcjrikmdf32pg4jy7inp-alsa-lib-1.1.6/lib/alsa-lib/libasound_module_ctl_pulse.so
>  ((null): 
> /gnu/store/5cbff8yc8f8qgcjrikmdf32pg4jy7inp-alsa-lib-1.1.6/lib/alsa-lib/libasound_module_ctl_pulse.so:
>  cannot open shared object file: No such file or directory)
> amixer: Mixer attach default error: No such device or address
>
> And the aforementioned file is missing indeed.
>
> I see that in commit 2101cc3fb691f443b830fdf5f846ded5fa018739 Julien
> patched alsa-lib to use ALSA_PLUGIN_DIR.  Could be the culprit?

Hi Pierre,

I just noticed that there are some commits on the staging branch that
might take care of this issue (specifically commits 1e3861eb and 3272bcfd).


signature.asc
Description: PGP signature

Re: Python package gaupol: Namespace Gdk not available

[Kei Kebreau]

Pierre Neidhardt  writes:

> Hi there,
>
> I'm trying to package gaupol (https://otsaloma.io/gaupol/), a subtitle
> editor.
>
> (define-public gaupol

[...]

>  (replace 'install
>(lambda* (#:key outputs #:allow-other-keys)
>  (zero?
>   (system* "python" "setup.py" "install"
>(string-append "--prefix=" (assoc-ref outputs "out"))
>"--root=/")))

You can use 'invoke' here instead of 'zero?' with 'system*' for the same
effect.

> (synopsis "Editor for text-based subtitles")
> (description
>  "Gaupol supports multiple subtitle file formats and provides means of
> creating subtitles, editing texts and timing subtitles to match video.  The
> user interface features a builtin video player and is designed with attention
> to convenience of translating and batch processing of multiple documents.")
> (home-page "http://otsaloma.io/gaupol/;)
> (license license:gpl3+)))
>
>
> The build runs fine, or so it seems.  But when I try to start it:
>
>> /gnu/store/gh44n7nfc7x3w8bbmq5l1glvlvycymdw-gaupol-1.4/bin/gaupol 
> Traceback (most recent call last):
>   File 
> "/gnu/store/gh44n7nfc7x3w8bbmq5l1glvlvycymdw-gaupol-1.4/bin/.gaupol-real", 
> line 17, in 
> import gaupol
>   File 
> "/gnu/store/gh44n7nfc7x3w8bbmq5l1glvlvycymdw-gaupol-1.4/lib/python3.6/site-packages/gaupol/__init__.py",
>  line 34, in 
> gi.require_version("Gdk", "3.0")
>   File 
> "/gnu/store/7p24q6jbkzwp7cp44543mi9zzn4czgig-python-pygobject-3.28.2/lib/python3.6/site-packages/gi/__init__.py",
>  line 130, in require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace Gdk not available
>
> I suppose I'm missing a dependency but I can't find any reference to
> python+gdk anywhere beside python-pygobject... Must be something else.
>
> Anyone?

My first guess would be that you need to wrap gaupol with the
environment variable "GI_TYPELIB_PATH". Take a look at the sonata
package in gnu/packages/mpd.scm for an example.

Hope this helps,
Kei


signature.asc
Description: PGP signature

Re: preparing the next release v0.15.0

[Kei Kebreau]

swedebugia  writes:

> On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau  
> wrote:
>
>  Marius Bakke  writes:
>
>   On the NEWS side, here is what springs to mind:
>
> [...]
>
>   * Packages can specify that some CVEs don't apply to them
>
> Around when (or what commit) was this feature introduced?
>
> f4007b25476dfd97885f358d2dabbd463f6f6017
> Nov 30th. By efraim. 

I see, thank you both.


signature.asc
Description: PGP signature

Re: preparing the next release v0.15.0

[Kei Kebreau]

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

> Hello Guix!
>
> Thanks for all the ideas, I’ve updated NEWS accordingly.  I’m sure we’re
> still missing a number things (so much has happened!) so more ideas are
> still welcome.  :-)
>
> Ludo’.

Hi Ludo,

Looking at your changes to the log file increases my confidence that I
was on the right track with updating it. You covered what I'd added and
more, but I do have a quick question: I take it that there exists a
script for determining the new packages and updates for each release?
Maybe I've missed it in the repository or in discussion.

Thanks,
Kei


signature.asc
Description: PGP signature

Re: preparing the next release v0.15.0

[Kei Kebreau]

Marius Bakke  writes:

> On the NEWS side, here is what springs to mind:
>
[...]
> * Packages can specify that some CVEs don't apply to them

Around when (or what commit) was this feature introduced?


signature.asc
Description: PGP signature

Re: preparing the next release v0.15.0

[Kei Kebreau]

Ricardo Wurmus  writes:

> Hi Guix,
>
> I wrote almost 6 days ago:
>
>> Here are a bunch of things that we should look into:
>>
>> * Outstanding patches.  There are many patches in the queue at
>>   guix-patches[1] that we should go through, comment on, and/or apply
>>   before the release.  Who would like to join a task force to do that
>>   together?  Let’s pick 5 patches each and review them so that we can
>>   either comment to ask for changes or to apply them.
>>
>>   [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
>>
>> * breakage since the last core-updates merge.  Since the long overdue
>>   merge of the “core-updates” branch we have a few serious problems on
>>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>>   lead an effort to investigate and fix these problems?  (Note: you
>>   obviously don’t need to fix them yourself, just keep track of these
>>   things and coordinate with others who investigate them.)
>>
>> * collecting new features and big changes in NEWS.  The NEWS file
>>   already lists some of the changes that the next release would provide
>>   compared to 0.14.0, but we all know that there are more.  Who would
>>   like to take charge of the NEWS file?  This involves asking people for
>>   changes they would really like to be mentioned and coordinating with
>>   other volunteers to search through all commits since v0.14.0 to find
>>   noteworthy changes.
>>
> […]
>> Did I miss anything?  Who wants to help?
>
> We aim for a release on June 30, 2018.  Unfortunately, so far nobody has
> come forward to help us coordinate one of these three tasks.
>
> Any volunteers?
>
> --
> Ricardo

I suppose I could give working on the NEWS file a shot. If I have my
schedule right, I can start work on it within the next 24 hours.


signature.asc
Description: PGP signature

Re: 04/05: gnu: swig: Patch for Octave 4.4.

[Kei Kebreau]

Kei Kebreau  writes:

> Kei Kebreau  writes:
>
>> Other than Shogun's Python/SWIG-related build failure (attached), this
>> patch seems to work fairly well. There appears to be an upstream issue
>> related to the invalid conversion mentioned in the build failure. I'm
>> keeping an eye on it for any new developments.
>
> FYI, this is an updated patch that bypasses the Python interface issue
> and runs into an issue with R.

I haven't been able to crack the issue with Shogun and R.  The attached
patch explicitly disables the R interface which allows shogun to build
properly while the R problem is resolved.

From a364bc3122ac9d3903a0d84a579d477334a59ac8 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.

* gnu/packages/swig.scm (swig-git): New variable
* gnu/packages/machine-learning.scm (shogun)[arguments]: Add
'fix-python-compiler-flags' phase.  Disable R interface.
[inputs]: Replace swig with swig-git.  Remove r-minimal.
---
 gnu/packages/machine-learning.scm | 13 +---
 gnu/packages/swig.scm | 34 +++
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index 15e4d4574..65dd9d31b 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -469,6 +469,13 @@ sample proximities between pairs of cases.")
(mkdir-p rxcpp-dir)
(install-file (assoc-ref inputs "rxcpp") rxcpp-dir)
#t)))
+ (add-after 'unpack 'fix-python-compiler-flags
+   (lambda _
+ ;; This prevents a set of function conversions from stopping the
+ ;; build with an error.
+ (substitute* "src/interfaces/python/CMakeLists.txt"
+   (("Wno-c\\+\\+11-narrowing") "fpermissive"))
+ #t))
  (add-before 'build 'set-HOME
;; $HOME needs to be set at some point during the build phase
(lambda _ (setenv "HOME" "/tmp") #t)))
@@ -482,13 +489,13 @@ sample proximities between pairs of cases.")
  ;;"-DINTERFACE_LUA=ON"  ;fails because lua doesn't build 
pkgconfig file
  "-DINTERFACE_OCTAVE=ON"
  "-DINTERFACE_PYTHON=ON"
- "-DINTERFACE_R=ON")))
+ "-DINTERFACE_R=OFF")))  ;temporarily off due to unknown issues.
 (inputs
  `(("python" ,python)
("numpy" ,python-numpy)
-   ("r-minimal" ,r-minimal)
+   ;;("r-minimal" ,r-minimal) ;re-enable when interface issues are resolved
("octave" ,octave)
-   ("swig" ,swig)
+   ("swig" ,swig-git)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/swig.scm b/gnu/packages/swig.scm
index b931db412..3a1139dbb 100644
--- a/gnu/packages/swig.scm
+++ b/gnu/packages/swig.scm
@@ -20,8 +20,12 @@
 (define-module (gnu packages swig)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix licenses)
+  #:use-module (guix utils)
   #:use-module (guix build-system gnu)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages bison)
   #:use-module (gnu packages pcre)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages boost)
@@ -74,3 +78,33 @@ you tailor the wrapping process to suit your application.")
 
 ;; See http://www.swig.org/Release/LICENSE for details.
 (license gpl3+)))
+
+;; This package contains upstream fixes that haven't been released as part of a
+;; stable version of SWIG.  This is necessary for software that uses SWIG to
+;; compile the correct and up-to-date programming language interfaces.
+(define-public swig-git
+  (let ((commit "12c66f9b7d884020e896ce92b9783bc3bac95d2d")
+(revision "1"))
+(package/inherit swig
+  (name "swig-git")
+  (version (git-version "4.0.0" revision commit))
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/swig/swig.git;)
+   (commit commit)))
+ (sha256 (base32 
"1367y47kdkly9cwyp4d60cm5d660am83g4p52k1hmzvimghwgvlp"))
+ (file-name (git-file-name name version
+  (arguments
+   (substitute-keyword-arguments (package-arguments swig)
+ ((#:phases phases)
+  `(modify-phases ,phases
+ (add-after 'unpack 'autogen
+   (lambda _
+ (invoke "sh" "autogen.sh")))
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("bison" ,bison)
+ ,@(package-native-inputs swig))
-- 
2.17.1



signature.asc
Description: PGP signature

Re: my latest blog post [everyone, please take a cooldown break]

[Kei Kebreau]

Gábor Boskovits  writes:

> +1
>
> 2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber :
>
>  Nils Gillmann writes:
>
>  > Hi,
>  >
>  > I think it would be best if everyone involved would cool down for a couple 
> of
>  > days, restructure their thoughts and reflect on this thread. Look at what
>  > they are doing, and at how they are reacting to other peoples reaction.
>  > This topic is getting quiet heated, and other than the maintainers we
>  > do not have established some kind of mderation. It can be hard to discuss
>  > some topics online.
>  > Text can sometimes fail to transport what we attampt to express, and
>  > I have seen people step away from projects because of this.
>
>  +1000

+1


signature.asc
Description: PGP signature

Re: 04/05: gnu: swig: Patch for Octave 4.4.

[Kei Kebreau]

Kei Kebreau  writes:

> Other than Shogun's Python/SWIG-related build failure (attached), this
> patch seems to work fairly well. There appears to be an upstream issue
> related to the invalid conversion mentioned in the build failure. I'm
> keeping an eye on it for any new developments.

FYI, this is an updated patch that bypasses the Python interface issue
and runs into an issue with R.

From f4fa63249bec73a385bba1b95bc53cac8f96420c Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.

* gnu/packages/swig.scm (swig-git): New variable
* gnu/packages/machine-learning.scm (shogun)[arguments]: Add
'fix-python-compiler-flags' phase.
[inputs]: Replace swig with swig-git.
---
 gnu/packages/machine-learning.scm |  9 +++-
 gnu/packages/swig.scm | 34 +++
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index 15e4d4574..d992a2fe5 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -469,6 +469,13 @@ sample proximities between pairs of cases.")
(mkdir-p rxcpp-dir)
(install-file (assoc-ref inputs "rxcpp") rxcpp-dir)
#t)))
+ (add-after 'unpack 'fix-python-compiler-flags
+   (lambda _
+ ;; This prevents a set of function conversions from stopping the
+ ;; build with an error.
+ (substitute* "src/interfaces/python/CMakeLists.txt"
+   (("Wno-c\\+\\+11-narrowing") "fpermissive"))
+ #t))
  (add-before 'build 'set-HOME
;; $HOME needs to be set at some point during the build phase
(lambda _ (setenv "HOME" "/tmp") #t)))
@@ -488,7 +495,7 @@ sample proximities between pairs of cases.")
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
("octave" ,octave)
-   ("swig" ,swig)
+   ("swig" ,swig-git)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/swig.scm b/gnu/packages/swig.scm
index b931db412..3a1139dbb 100644
--- a/gnu/packages/swig.scm
+++ b/gnu/packages/swig.scm
@@ -20,8 +20,12 @@
 (define-module (gnu packages swig)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix licenses)
+  #:use-module (guix utils)
   #:use-module (guix build-system gnu)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages bison)
   #:use-module (gnu packages pcre)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages boost)
@@ -74,3 +78,33 @@ you tailor the wrapping process to suit your application.")
 
 ;; See http://www.swig.org/Release/LICENSE for details.
 (license gpl3+)))
+
+;; This package contains upstream fixes that haven't been released as part of a
+;; stable version of SWIG.  This is necessary for software that uses SWIG to
+;; compile the correct and up-to-date programming language interfaces.
+(define-public swig-git
+  (let ((commit "12c66f9b7d884020e896ce92b9783bc3bac95d2d")
+(revision "1"))
+(package/inherit swig
+  (name "swig-git")
+  (version (git-version "4.0.0" revision commit))
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/swig/swig.git;)
+   (commit commit)))
+ (sha256 (base32 
"1367y47kdkly9cwyp4d60cm5d660am83g4p52k1hmzvimghwgvlp"))
+ (file-name (git-file-name name version
+  (arguments
+   (substitute-keyword-arguments (package-arguments swig)
+ ((#:phases phases)
+  `(modify-phases ,phases
+ (add-after 'unpack 'autogen
+   (lambda _
+ (invoke "sh" "autogen.sh")))
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("bison" ,bison)
+ ,@(package-native-inputs swig))
-- 
2.17.1

[ 79%] Linking CXX shared module shogun.so
cd /tmp/guix-build-shogun-6.1.3.drv-0/build/src/interfaces/r && 
/gnu/store/8mycww9vx11vidzka3g5gghwq11alk4w-cmake-3.7.2/bin/cmake -E 
cmake_link_script CMakeFiles/interface_r.dir/link.txt --verbose=1
/gnu/store/cfdn69spjc44x4sd0acrwhxq6yay3rbc-gcc-5.5.0/bin/c++  -fPIC -O0 -g  
-I/gnu/store/42j0p3x4v2gbwqyx6iv1j83qckndm799-r-minimal-3.5.0/lib/R/include -O2 
-g -DNDEBUG  -shared  -o shogun.so 
CMakeFiles/interface_r.dir/shogunR_wrap.cxx.o 
CMakeFiles/interface_r.dir/sg_print_functions.cpp.o  
-L/gnu/store/42j0p3x4v2gbwqyx6iv1j83qckndm799-r-minimal-3.5.0/lib/R/lib 
-Wl,-rpath,/gnu/st

Re: 04/05: gnu: swig: Patch for Octave 4.4.

[Kei Kebreau]

Mark H Weaver  writes:

> Hi Kei,
>
> Kei Kebreau  writes:
>
>> Mark H Weaver  writes:
>>
>>> Instead, I suggest creating a different 'swig' package for octave that
>>> inherits from the primary one and adds this patch.
>>
>> I agree that this will work. Is the attached patch something like what
>> you're thinking?
>
> Yes, although I have some suggestions:
>
>> From 475a7698fd4c88ea688cb43499344e65ffaf5b84 Mon Sep 17 00:00:00 2001
>> From: Kei Kebreau 
>> Date: Wed, 30 May 2018 08:34:42 -0400
>> Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.
>>
>> * gnu/packages/machine-learning.scm (swig-for-octave): New variable
>> * gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with
>> swig-for-octave.
>> * gnu/packages/patches/swig-octave-patches.patch: New file.
>> * gnu/local.mk (dist_patch_DATA): Register patch.
> [...]
>> diff --git a/gnu/packages/machine-learning.scm 
>> b/gnu/packages/machine-learning.scm
>> index e135ee0ee..4d54584a7 100644
>> --- a/gnu/packages/machine-learning.scm
>> +++ b/gnu/packages/machine-learning.scm
>> @@ -365,6 +365,14 @@ value imputation, classifier creation, generalization 
>> error estimation and
>>  sample proximities between pairs of cases.")
>>  (license license:gpl3+)))
>>  
>> +(define swig-for-octave
>> +  (package/inherit swig
>> +(name (string-append (package-name swig) "-for-octave"))
>> +(source
>> + (origin
>> +   (inherit (package-source swig))
>> +   (patches (search-patches "swig-octave-patches.patch"))
>
> For the patches field, how about something like this:
>
>(patches (append (origin-patches (package-source swig))
> (search-patches "swig-octave-patches.patch")))
>
> so if someone adds a patch to swig, it will automatically get picked up
> by this one too.
>
> Please add a comment above the 'swig-for-octave' definition explaining
> what it's for.  I was confused at first that you didn't change the
> octave definition, but now I guess that it's for other packages that
> wish to use octave via swig, or something along those lines?  It should
> be good to explain in a comment.
>
> Also, I think it would be better to put the 'swig-for-octave' definition
> immediately after the one for 'swig', so that it's more likely to be
> noticed by people working on swig.  This package has more connection to
> swig than it does to shogun.  It has no direct connection to 'shogun'
> except that shogun is currently the only user of it.
>
> Another question: instead of adding the patch, how about changing the
> origin to build from a git checkout?  The advantage of that is that it
> requires less trust from users.  I look at this big patch and I wonder
> if I should check to make sure it matches what upstream has (I didn't).
> If it's a git checkout, there's less trust needed.  It would also make
> later upgrades easier.
>
> It might also be better to call the package "swig-git" or something,
> dunno.
>
> What do you think?  Thanks for working on it.
>
>   Mark

Other than Shogun's Python/SWIG-related build failure (attached), this
patch seems to work fairly well. There appears to be an upstream issue
related to the invalid conversion mentioned in the build failure. I'm
keeping an eye on it for any new developments.

From deb75abebf74be37d2afedd9e5d8f8b07c65ab06 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.

* gnu/packages/swig.scm (swig-git): New variable
* gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with
swig-git.
---
 gnu/packages/machine-learning.scm |  2 +-
 gnu/packages/swig.scm | 34 +++
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index e135ee0ee..bc618bad2 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -487,7 +487,7 @@ sample proximities between pairs of cases.")
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
("octave" ,octave)
-   ("swig" ,swig)
+   ("swig" ,swig-git)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/swig.scm b/gnu/packages/swig.scm
index b931db412..3a1139dbb 100644
--- a/gnu/packages/swig.scm
+++ b/gnu/packages/swig.scm
@@ -20,8 +20,12 @@
 (define-module (gnu packages swig)
   #:use-module (guix packages)
   #:use-module (guix download)

Re: 04/05: gnu: swig: Patch for Octave 4.4.

[Kei Kebreau]

Mark H Weaver  writes:

> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 3771000f893d4b53e302f5bca07afeba69e76cd4
>> Author: Kei Kebreau 
>> Date:   Fri May 25 22:25:21 2018 -0400
>>
>> gnu: swig: Patch for Octave 4.4.
>
> On the core-updates branch, "guix refresh -l swig" reports that updating
> swig requires 1453 rebuilds.  That's too many, so I reverted it.
>
> Instead, I suggest creating a different 'swig' package for octave that
> inherits from the primary one and adds this patch.
>
> What do you think?
>
>   Mark

I agree that this will work. Is the attached patch something like what
you're thinking?

(Apologies if you get two of these messages; it seems to me like the
first one didn't go through.)

From 475a7698fd4c88ea688cb43499344e65ffaf5b84 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.

* gnu/packages/machine-learning.scm (swig-for-octave): New variable
* gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with
swig-for-octave.
* gnu/packages/patches/swig-octave-patches.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
 gnu/local.mk  |1 +
 gnu/packages/machine-learning.scm |   10 +-
 .../patches/swig-octave-patches.patch | 1119 +
 3 files changed, 1129 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/swig-octave-patches.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 7734586f0..895d33012 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1106,6 +1106,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/steghide-fixes.patch\
   %D%/packages/patches/strace-kernel-4.16.patch\
   %D%/packages/patches/superlu-dist-scotchmetis.patch  \
+  %D%/packages/patches/swig-octave-patches.patch   \
   %D%/packages/patches/swish-e-search.patch\
   %D%/packages/patches/swish-e-format-security.patch   \
   %D%/packages/patches/synfigstudio-fix-ui-with-gtk3.patch \
diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index e135ee0ee..4d54584a7 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -365,6 +365,14 @@ value imputation, classifier creation, generalization 
error estimation and
 sample proximities between pairs of cases.")
 (license license:gpl3+)))
 
+(define swig-for-octave
+  (package/inherit swig
+(name (string-append (package-name swig) "-for-octave"))
+(source
+ (origin
+   (inherit (package-source swig))
+   (patches (search-patches "swig-octave-patches.patch"))
+
 (define-public shogun
   (package
 (name "shogun")
@@ -487,7 +495,7 @@ sample proximities between pairs of cases.")
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
("octave" ,octave)
-   ("swig" ,swig)
+   ("swig" ,swig-for-octave)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/patches/swig-octave-patches.patch 
b/gnu/packages/patches/swig-octave-patches.patch
new file mode 100644
index 0..9fb64a7b1
--- /dev/null
+++ b/gnu/packages/patches/swig-octave-patches.patch
@@ -0,0 +1,1119 @@
+This patch represents the recently added support for Octave version 4.4 found
+here:
+
+https://github.com/swig/swig/commit/12c66f9b7d884020e896ce92b9783bc3bac95d2d
+
+diff -urN swig-3.0.12.old/CHANGES.current swig-3.0.12.new/CHANGES.current
+--- swig-3.0.12.old/CHANGES.current2017-01-27 18:52:02.0 -0500
 swig-3.0.12.new/CHANGES.current2018-05-26 08:40:06.501850058 -0400
+@@ -4,6 +4,14 @@
+ Issue # numbers mentioned below can be found on Github. For more details, add
+ the issue number to the end of the URL: https://github.com/swig/swig/issues/
+ 
++Version 4.0.0 (in progress)
++===
++
++2018-05-12: kwwette
++[Octave] add support for version 4.4
++- Should not introduce any user-visible incompatibilities
++
++
+ Version 3.0.12 (27 Jan 2017)
+ 
+ 
+diff -urN swig-3.0.12.old/Examples/Makefile.in 
swig-3.0.12.new/Examples/Makefile.in
+--- swig-3.0.12.old/Examples/Makefile.in   2017-01-27 18:52:02.0 
-0500
 swig-3.0.12.new/Examples/Makefile.in   2018-05-26 08:39:16.510124553 
-0400
+@@ -463,7 +463,7 @@
+ # -
+ 
+ octave_run:
+-  OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) $(OCTAVE_SCRIPT) 
$(RUNPIPE)
++  env OCTAVE_PATH= OCTAVE_HI

Re: 04/05: gnu: swig: Patch for Octave 4.4.

[Kei Kebreau]

Mark H Weaver  writes:

> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 3771000f893d4b53e302f5bca07afeba69e76cd4
>> Author: Kei Kebreau 
>> Date:   Fri May 25 22:25:21 2018 -0400
>>
>> gnu: swig: Patch for Octave 4.4.
>
> On the core-updates branch, "guix refresh -l swig" reports that updating
> swig requires 1453 rebuilds.  That's too many, so I reverted it.
>
> Instead, I suggest creating a different 'swig' package for octave that
> inherits from the primary one and adds this patch.
>
> What do you think?
>
>   Mark

I agree that this will work. Is the attached patch something like what
you're thinking?
From 475a7698fd4c88ea688cb43499344e65ffaf5b84 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.

* gnu/packages/machine-learning.scm (swig-for-octave): New variable
* gnu/packages/machine-learning.scm (shogun)[inputs]: Replace swig with
swig-for-octave.
* gnu/packages/patches/swig-octave-patches.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
 gnu/local.mk  |1 +
 gnu/packages/machine-learning.scm |   10 +-
 .../patches/swig-octave-patches.patch | 1119 +
 3 files changed, 1129 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/swig-octave-patches.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 7734586f0..895d33012 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1106,6 +1106,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/steghide-fixes.patch\
   %D%/packages/patches/strace-kernel-4.16.patch\
   %D%/packages/patches/superlu-dist-scotchmetis.patch  \
+  %D%/packages/patches/swig-octave-patches.patch   \
   %D%/packages/patches/swish-e-search.patch\
   %D%/packages/patches/swish-e-format-security.patch   \
   %D%/packages/patches/synfigstudio-fix-ui-with-gtk3.patch \
diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index e135ee0ee..4d54584a7 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -365,6 +365,14 @@ value imputation, classifier creation, generalization 
error estimation and
 sample proximities between pairs of cases.")
 (license license:gpl3+)))
 
+(define swig-for-octave
+  (package/inherit swig
+(name (string-append (package-name swig) "-for-octave"))
+(source
+ (origin
+   (inherit (package-source swig))
+   (patches (search-patches "swig-octave-patches.patch"))
+
 (define-public shogun
   (package
 (name "shogun")
@@ -487,7 +495,7 @@ sample proximities between pairs of cases.")
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
("octave" ,octave)
-   ("swig" ,swig)
+   ("swig" ,swig-for-octave)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/patches/swig-octave-patches.patch 
b/gnu/packages/patches/swig-octave-patches.patch
new file mode 100644
index 0..9fb64a7b1
--- /dev/null
+++ b/gnu/packages/patches/swig-octave-patches.patch
@@ -0,0 +1,1119 @@
+This patch represents the recently added support for Octave version 4.4 found
+here:
+
+https://github.com/swig/swig/commit/12c66f9b7d884020e896ce92b9783bc3bac95d2d
+
+diff -urN swig-3.0.12.old/CHANGES.current swig-3.0.12.new/CHANGES.current
+--- swig-3.0.12.old/CHANGES.current2017-01-27 18:52:02.0 -0500
 swig-3.0.12.new/CHANGES.current2018-05-26 08:40:06.501850058 -0400
+@@ -4,6 +4,14 @@
+ Issue # numbers mentioned below can be found on Github. For more details, add
+ the issue number to the end of the URL: https://github.com/swig/swig/issues/
+ 
++Version 4.0.0 (in progress)
++===
++
++2018-05-12: kwwette
++[Octave] add support for version 4.4
++- Should not introduce any user-visible incompatibilities
++
++
+ Version 3.0.12 (27 Jan 2017)
+ 
+ 
+diff -urN swig-3.0.12.old/Examples/Makefile.in 
swig-3.0.12.new/Examples/Makefile.in
+--- swig-3.0.12.old/Examples/Makefile.in   2017-01-27 18:52:02.0 
-0500
 swig-3.0.12.new/Examples/Makefile.in   2018-05-26 08:39:16.510124553 
-0400
+@@ -463,7 +463,7 @@
+ # -
+ 
+ octave_run:
+-  OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) $(OCTAVE_SCRIPT) 
$(RUNPIPE)
++  env OCTAVE_PATH= OCTAVE_HISTFILE=/dev/null $(RUNTOOL) $(OCTAVE) 
$(OCTAVE_SCRIPT) $(RUNPIPE)
+ 
+ # 

Re: Code of Conduct and Diversity Statement

[Kei Kebreau]

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

>
> As I see it, the new version is more clearly structured, clarifies the
> wording in some places, and introduces a distinction between “project
> team” and “project maintainers”.  Perhaps we’d need to clarify what the
> “project team” is in our case (?).
>
> Apart from this, I think 1.4 follows the spirit of 1.3.0 and its
> clarifications are welcome, so I’d be in favor of “upgrading”.
>
> What do people think?
>
> Thanks for sharing your thoughts, Tonton!
>
> Ludo’.

I'm also in favor of the move to version 1.4.


signature.asc
Description: PGP signature

Re: GSoC-2018

[Kei Kebreau]

Sandeep Subramanian  writes:

> Hi all,
>
> I am Sandeep Subramanian (uniq10) and I have been selected for the
> GSoC-2018 project "Continue rewrite build daemon in Guile Scheme".
> (Project description:
> https://libreplanet.org/wiki/Group:Guix/GSoC-2018#Continue_rewrite_build_daemon_in_Guile_Scheme
> )
>
> I am very excited to work on this project and am looking forward to
> interacting
> with the community here and on the #guix IRC channel (Nick: uniq10).
> I will mostly be active from UTC 08:00 to UTC 20:00.
>
> I hope to, with your help, successfully complete this project and make a
> meaningful contribution to the community.

Welcome!


signature.asc
Description: PGP signature

Re: Patch for broken Hiawatha

[Kei Kebreau]

Leo Famulari <l...@famulari.name> writes:

> On Mon, Feb 26, 2018 at 03:07:51PM -0500, Kei Kebreau wrote:
>> Hello all,
>> 
>> It seems that commit 22261238e7591c21d8362147992fbb12e67fda88, which
>> updates mbed TLS, has broken the hiawatha build [0]. It turns out that
>> the new release of mbed TLS contained a very minor typo that caused this
>> failure [1]. I've attached a patch that is ready to be merged as soon as
>> someone else can verify that it works.
>> 
>> Thank you!
>> 
>> [0]: https://hydra.gnu.org/eval/109917#tabs-now-fail
>> [1]: https://github.com/ARMmbed/mbedtls/pull/1362
>
>> From 8e23721f42e05482b925c6cfc244b9c19a11c0a5 Mon Sep 17 00:00:00 2001
>> From: Kei Kebreau <kkebr...@posteo.net>
>> Date: Mon, 26 Feb 2018 14:47:15 -0500
>> Subject: [PATCH] gnu: mbedtls-apache: Fix upstream typo.
>> 
>> A typo was introduced in version 2.7.0 that caused the hiawatha package to
>> fail to build. See https://github.com/ARMmbed/mbedtls/pull/1362.
>> 
>> * gnu/packages/tls.scm (mbedtls-apache)[source]: Add snippet to fix typo.
>
> Thanks, LGTM!

Pushed! Thanks for the review and the mbedtls security update!


signature.asc
Description: PGP signature

Patch for broken Hiawatha

[Kei Kebreau]

Hello all,

It seems that commit 22261238e7591c21d8362147992fbb12e67fda88, which
updates mbed TLS, has broken the hiawatha build [0]. It turns out that
the new release of mbed TLS contained a very minor typo that caused this
failure [1]. I've attached a patch that is ready to be merged as soon as
someone else can verify that it works.

Thank you!

[0]: https://hydra.gnu.org/eval/109917#tabs-now-fail
[1]: https://github.com/ARMmbed/mbedtls/pull/1362
From 8e23721f42e05482b925c6cfc244b9c19a11c0a5 Mon Sep 17 00:00:00 2001
From: Kei Kebreau <kkebr...@posteo.net>
Date: Mon, 26 Feb 2018 14:47:15 -0500
Subject: [PATCH] gnu: mbedtls-apache: Fix upstream typo.

A typo was introduced in version 2.7.0 that caused the hiawatha package to
fail to build. See https://github.com/ARMmbed/mbedtls/pull/1362.

* gnu/packages/tls.scm (mbedtls-apache)[source]: Add snippet to fix typo.
---
 gnu/packages/tls.scm | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 9e06e675f..2233b5974 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -797,7 +797,15 @@ then ported to the GNU / Linux environment.")
version "-apache.tgz"))
(sha256
 (base32
- "1vsmgxnw7dpvma51896n63yaf9sncmf885ax2jfcg89ssin6vdmf"
+ "1vsmgxnw7dpvma51896n63yaf9sncmf885ax2jfcg89ssin6vdmf"))
+   ;; An RFC 5114 constant was accidentally renamed in version 2.7.0.
+   ;; See https://github.com/ARMmbed/mbedtls/pull/1362.
+   (modules '((guix build utils)))
+   (snippet
+'(begin
+   (substitute* "include/mbedtls/dhm.h"
+ (("#define MBEDTLS_DHM_RFC5114_MODP_P")
+  "#define MBEDTLS_DHM_RFC5114_MODP_2048_P"))
 (build-system cmake-build-system)
 (arguments
  `(#:configure-flags
-- 
2.16.1



signature.asc
Description: PGP signature

Re: question regarding substitute* and #t

[Kei Kebreau]

Andy Wingo  writes:

> On Wed 24 Jan 2018 14:28, Mark H Weaver  writes:
>
>> Andy Wingo  writes:
>>
>>> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>>>
 + ;; Install to the right directory
 + (substitute* '("Makefile"
 +"Qsci/Makefile")
 +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
 +(assoc-ref outputs "out")))
 + #t)
>>>
>>> I guess once we switch over all instances of "system" and "system*" to
>>> use invoke, does that mean we will also be able to remove these
>>> vestigial "#t" returns?
>>
>> After we switch to using 'invoke' everywhere, or more precisely, after
>> we arrange to never return #false from any phase or snippet, then there
>> should be one more step before removing the vestigial #true returns: we
>> should change the code that calls phases or snippets to ignore the
>> value(s) returned by those procedures.  When that is done, then the #t's
>> will truly be vestigial.  Does that make sense?
>
> Sure, makes sense.  Thanks for thinking it through with me :)
>
> Andy

Thanks to you both for this thread!


signature.asc
Description: PGP signature

Re: core-updates, let’s go!

[Kei Kebreau]

Leo Famulari  writes:

> On Mon, Jan 01, 2018 at 06:12:49PM +0100, Ludovic Courtès wrote:
>> We’ll have to stay focused in the coming days to fix everything as
>> quickly as we can.
>
> The latest core-updates evaluation is coming together [0], but there are
> still a few notable issues:
>
> * Pandas is failing to build:
>
> https://hydra.gnu.org/job/gnu/core-updates/python2-pandas-0.19.2.x86_64-linux
>
> * CLISP is failing to build, which breaks SBCL:
>
> https://hydra.gnu.org/job/gnu/core-updates/clisp-2.49-60.x86_64-linux
>
> * Several packages are failing due to changes in ICU related to type
> definitions. For example, evolution-data-server is failing to build,
> which breaks GNOME:
>
> https://hydra.gnu.org/job/gnu/core-updates/evolution-data-server-3.24.3.x86_64-linux
>
> * ant-bootstrap failed to build, breaking most (all?) of the Java
> packages. This is being discussed in . I
> can't retry the ant-bootstrap build because the package is not public,
> so there is no corresponding job on Hydra. An example:
>
> https://hydra.gnu.org/build/2443807
>
> * And more!
>
> Why not check if the packages you rely on are working on core-updates?
> These are the packages that fail compared to the master branch:
>
> [0] 
> https://hydra.gnu.org/eval/109888?compare=master=1#tabs-now-fail

I have a patch for CLISP that addresses the source of the build
failure. I'm currently testing to see if the resulting binary can build
SBCL properly. Expect to see the patch on the guix-patches list soon!


signature.asc
Description: PGP signature

Re: invoke instead of (system* ...

[Kei Kebreau]

ng0  writes:

> Leo Famulari transcribed 1.4K bytes:
>> On Fri, Jan 12, 2018 at 08:16:40PM +0100, Catonano wrote:
>> > recently I read that we should move to using this invoke procedure instead
>
> Could you tell me where you've read this? It's news to me aswell.
>

You can check out this thread:
https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00278.html

>> > of the (system* some-script) in defining little scripts in packages and
>> > services definitions
>> > 
>> > But I can't remember where exactly
>> > 
>> > Where is this invoke procedure defined ?
>> 
>> It's in guix/build/utils.scm


signature.asc
Description: PGP signature

Re: Meltdown / Spectre

[Kei Kebreau]

Christopher Lemmer Webber  writes:

> Katherine Cox-Buday writes:
>
>> Tobias Geerinckx-Rice  writes:
>>
>>
>>> I think the real and thornier question for GuixSD
>>> is: if the recent CPU vulnerabilities require a
>>> microcode update to fully mitigate, then how do we
>>> square not recommending proprietary globs like
>>> this in official channels with giving users all
>>> knowledge required to decide for themselves?
>>
>> Yes, this exactly.
>>
>> It's a unique (hm, is it?) situation pitting the ideals of copyleft
>> against the welfare of users. If an opaque microcode is required to
>> successfully mitigate these bugs, what is the moral stance to take?
>>
>> I don't have an answer and that's why I'm asking here :)
>
> It seems to me that this is one of those "you need to upgrade some
> lowest level firmware which you already didn't have access to in order
> to keep your system secure"... I dunno if GuixSD should ship something,
> but I wouldn't blame anyone updating their microcode for something this
> critical.
>

My interpretation of the GNU FSDG leads me to believe that GuixSD
shouldn't ship anything. Because the opaque microcode update in question
is proprietary and necessarily runs on the CPU, we cannot and should not
recommend it. See how Libreboot addresses this issue:
https://libreboot.org/faq.html#microcode.

> That said, if the microcode were free in the first place, this would
> probably be a lot easier to deal with?

Yes, this would not be a problem. The real problem is with the
proprietary and thus harmful nature of Intel's microcode. Even if the
FSDG allowed for nonfree firmware in this case, there is no way to
verify with certainty that the microcode update does what it claims (and
/only/ what it claims, for that matter).


signature.asc
Description: PGP signature

Re: 01/01: gnu: python-pillow: Fix test failures on i686-linux and armhf-linux.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 15b60fc3138e9d601aff3e3317373ed465e6ea93
>> Author: Kei Kebreau <kkebr...@posteo.net>
>> Date:   Sun Dec 24 16:23:50 2017 -0500
>>
>> gnu: python-pillow: Fix test failures on i686-linux and armhf-linux.
>> 
>> * gnu/packages/patches/python-pillow-fix-failing-tests.patch: New file.
>> * gnu/local.mk (dist_patch_DATA): Add it.
>> * gnu/packages/python.scm (python-pillow)[source]: Use it.
>
> Thanks for your efforts, but after this commit, Hydra still failed to
> build both python-pillow and python2-pillow on i686 and armhf:
>
>   https://hydra.gnu.org/eval/109870?filter=pillow
>
>Mark

I've included more fixes from upstream from the related pull request[0]
in the patch provided under bug #29912. While I can't test the
armhf-linux build, on my machine the i686-linux and x86_64-linux versions
of python-pillow and python2-pillow build without a problem.

[0]: https://github.com/python-pillow/Pillow/pull/2825


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Kei Kebreau]

Kei Kebreau <kkebr...@posteo.net> writes:

> Leo Famulari <l...@famulari.name> writes:
>
>> On Sun, Dec 24, 2017 at 06:16:29PM -0500, Kei Kebreau wrote:
>>> I've attempted to use the upstream patch, but it involves some GIT
>>> binaries which aren't supported by GNU patch. Among other hackish
>>> options, temporarily upgrading to the appropriate upstream commit may
>>> fix this for now.
>>
>> Does it work if you pass '--binary' to patch-flags?
>
> It does not. Maybe I could use 'diff --binary' to patch the files into
> existence?

Using 'diff --text' on the non-text files seems to work. The patch file
is encoded as 'raw-text' according to Emacs. Please take a look at our
bug #29849.


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Kei Kebreau]

Leo Famulari <l...@famulari.name> writes:

> On Sun, Dec 24, 2017 at 06:16:29PM -0500, Kei Kebreau wrote:
>> I've attempted to use the upstream patch, but it involves some GIT
>> binaries which aren't supported by GNU patch. Among other hackish
>> options, temporarily upgrading to the appropriate upstream commit may
>> fix this for now.
>
> Does it work if you pass '--binary' to patch-flags?

It does not. Maybe I could use 'diff --binary' to patch the files into
existence?


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> Kei Kebreau <kkebr...@posteo.net> writes:
>
>> Mark H Weaver <m...@netris.org> writes:
>>
>>> kkebr...@posteo.net (Kei Kebreau) writes:
>>>
>>>> kkebreau pushed a commit to branch master
>>>> in repository guix.
>>>>
>>>> commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
>>>> Author: Kei Kebreau <kkebr...@posteo.net>
>>>> Date:   Mon Dec 4 17:56:37 2017 -0500
>>>>
>>>> gnu: python-pillow: Update to 4.3.0.
>>>
>>> This new version seems to deterministically fail its test suite on i686:
>>>
>>>   https://hydra.gnu.org/build/2400760
>>>   https://hydra.gnu.org/build/2400819
>>>
>>> I restarted both of these, and they each failed again the second time.
>>> The same builds (python-pillow and python2-pillow) also failed on armhf,
>>> although as I write this they have not yet completed their second build
>>> attempts.
>
> The (new) failure on armhf also appears to be consistent, although
> different from the i686 failure.  Instead of a failed test, the build
> times out after 1 hour of silence during the test suite:
>
>   https://hydra.gnu.org/build/2400971
>
> Running selftest:
> --- 57 tests passed.
> ...S...S..SS.SS...S..SS.S.SS.S.building
>  of `/gnu/store/cjinxvws27bwdwn7n2fab3k10had6y2p-python2-pillow-4.3.0.drv' 
> timed out after 3600 seconds of silence
> @ build-failed 
> /gnu/store/cjinxvws27bwdwn7n2fab3k10had6y2p-python2-pillow-4.3.0.drv - timeout
>
>> I'm investigating now. Thanks for the heads up.
>
>  Thanks!
>Mark

The i686 failure is possibly related to this bug:
https://github.com/python-pillow/Pillow/issues/2758

I've attempted to use the upstream patch, but it involves some GIT
binaries which aren't supported by GNU patch. Among other hackish
options, temporarily upgrading to the appropriate upstream commit may
fix this for now.

As for the armhf build, I'm still not sure what is going on.


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> Hi Kei,
>
> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
>> Author: Kei Kebreau <kkebr...@posteo.net>
>> Date:   Mon Dec 4 17:56:37 2017 -0500
>>
>> gnu: python-pillow: Update to 4.3.0.
>
> This new version seems to deterministically fail its test suite on i686:
>
>   https://hydra.gnu.org/build/2400760
>   https://hydra.gnu.org/build/2400819
>
> I restarted both of these, and they each failed again the second time.
> The same builds (python-pillow and python2-pillow) also failed on armhf,
> although as I write this they have not yet completed their second build
> attempts.
>
> Altogether, this caused around 150 new dependency failures:
>
>   https://hydra.gnu.org/eval/109866#tabs-now-fail
>
> See below for the tail of one of the i686 build logs.
>
> Could you take a look?
>
>Mark
>
> FAIL: TestFontPcf.test_high_characters
> --
> Traceback (most recent call last):
>   File 
> "/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
>  line 62, in test_high_characters
> self._test_high_characters(message.encode('latin1'))
>   File 
> "/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
>  line 55, in _test_high_characters
> self.assert_image_equal(image, compare)
>   File 
> "/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/helper.py", 
> line 85, in assert_image_equal
> msg or "got size %r, expected %r" % (a.size, b.size))
> AssertionError: Tuples differ: (775, 22) != (765, 22)
>
> First differing element 0:
> 775
> 765
>
> - (775, 22)
> ?   ^
>
> + (765, 22)
> ?   ^
>  : got size (775, 22), expected (765, 22)
>  >> begin captured logging << 
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
> - >> end captured logging << -
>
> --
> Ran 1085 tests in 4.238s
>
> FAILED (SKIP=116, failures=1)
> phase `check-installed' failed after 8.9 seconds
> builder for 
> `/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' failed 
> with exit code 1
> @ build-failed 
> /gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv - 1 
> builder for 
> `/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' failed 
> with exit code 1

I'm investigating now. Thanks for the heads up.


signature.asc
Description: PGP signature

Re: [PATCH] Include Krita

[Kei Kebreau]

Mark Meyer  writes:

> I retract this patch, it is buggy :( Be right back.
>
> On Tue, Dec 5, 2017, at 00:55, Mark Meyer wrote:
>> Hi,
>> please find attached a patch to include Krita in Guix.
>> 
>> Please CC me, as I'm not a list member.
>> 
>> Cheers, Mark
>> 
>> -- 
>>   Mark Meyer
>>   m...@ofosos.org
>> Email had 1 attachment:
>> + 0001-gnu-packages-kde.scm-krita-Add-new-variable.patch
>>   7k (text/x-patch)

Hi Mark!

Thank you for your work on this patch. I ask that when you finish fixing
the bugs you found in it, please send the patch to guix-patc...@gnu.org
so patch reviewers are less likely to lose track of it.

Thanks again,
Kei


signature.asc
Description: PGP signature

Re: 01/01: gnu: gcl: Update snapshot.

[Kei Kebreau]

Kei Kebreau <kkebr...@posteo.net> writes:

> Mark H Weaver <m...@netris.org> writes:
>
>> kkebr...@posteo.net (Kei Kebreau) writes:
>>
>>> kkebreau pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit dd0134fcb707452e1c343d66af6088c0be38a285
>>> Author: Kei Kebreau <kkebr...@posteo.net>
>>> Date:   Wed Nov 22 13:47:33 2017 -0500
>>>
>>> gnu: gcl: Update snapshot.
>>> 
>>> * gnu/packages/lisp.scm (gcl): Update to 2.6.12-1.5956140.
>>> [arguments]: Remove CFLAGS from and add GCL_CC and CC to
>>> make-flags; adjust
>>> pre-conf phase.
>>> 
>>> This update includes small upstream bug fixes and optimizations.
>>
>> Thanks for this.  Unfortunately, Maxima's test suite started failing,
>> and I guess this is the most likely cause.
>>
>>   https://hydra.gnu.org/build/2361466
>>
>> Would you be willing to investigate?
>>
>>  Mark
>
> Yes, I'm currently reproducing the build failure locally. Thank you for
> the notification.

So it turns out that I cannot reproduce this failure locally. Is there a
way that I access the failed build tree?


signature.asc
Description: PGP signature

Re: 01/01: gnu: gcl: Update snapshot.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit dd0134fcb707452e1c343d66af6088c0be38a285
>> Author: Kei Kebreau <kkebr...@posteo.net>
>> Date:   Wed Nov 22 13:47:33 2017 -0500
>>
>> gnu: gcl: Update snapshot.
>> 
>> * gnu/packages/lisp.scm (gcl): Update to 2.6.12-1.5956140.
>> [arguments]: Remove CFLAGS from and add GCL_CC and CC to
>> make-flags; adjust
>> pre-conf phase.
>> 
>> This update includes small upstream bug fixes and optimizations.
>
> Thanks for this.  Unfortunately, Maxima's test suite started failing,
> and I guess this is the most likely cause.
>
>   https://hydra.gnu.org/build/2361466
>
> Would you be willing to investigate?
>
>  Mark

Yes, I'm currently reproducing the build failure locally. Thank you for
the notification.


signature.asc
Description: PGP signature

Re: Please write "Update to " instead of "Update snapshot"

[Kei Kebreau]

I thought "Update snapshot." had become customary for updating to
different VCS commits. I am in favor of keeping "Update to ."
where  is the Guix version string of the package in
question. This practice is especially useful when using "git shortlog"
and related tools.


signature.asc
Description: PGP signature

Re: maxima: The SGC segfault recovery test failed with memprotect_bad_fault_address, SGC disabled

[Kei Kebreau]

Kei Kebreau <kkebr...@posteo.net> writes:
>
> I turns out that the issue is with stratified garbage collection in
> GCL. The substitute from hydra.gnu.org does in fact give me the error
> when I run "(si::sgc-on t)" in the REPL. I'm preparing a patch to update
> GCL to the version used in Debian stable (GCL git tag "pathnames1.13") and
> we'll see if changing that definition on the master branch will do anything.

On second thought, the patches applied to Debian Sid's GCL look useful
as well. Anyway, keep an eye out for my update patch.


signature.asc
Description: PGP signature

Re: maxima: The SGC segfault recovery test failed with memprotect_bad_fault_address, SGC disabled

[Kei Kebreau]

Alex Vong <alexvong1...@gmail.com> writes:

> Kei Kebreau <kkebr...@posteo.net> writes:
>
>> Alex Vong <alexvong1...@gmail.com> writes:
>>
>>> Hello all,
>>>
>>> When I start maxima, I get the following warning message:
>>>
>>> The SGC segfault recovery test failed with
>>> memprotect_bad_fault_address, SGC disabled
>>> The SGC segfault recovery test failed with
>>> memprotect_bad_fault_address, SGC disabled
>>> Maxima 5.41.0 http://maxima.sourceforge.net
>>> using Lisp GNU Common Lisp (GCL) GCL 2.6.12
>>> Distributed under the GNU Public License. See the file COPYING.
>>> Dedicated to the memory of William Schelter.
>>> The function bug_report() provides bug reporting information.
>>>
>>> Actually I encountered this problem quite a while ago after an update,
>>> but I didn't report it since it was not fetal.
>>
>> When did you first notice this issue?
>>
> I am afraid I cannot remember exactly when...
>
> I installed wxmaxima long ago and things worked fine for a long
> time. One day, after updating wxmaxima, it showed the above warning and
> started to crash nondeterministically when I typed things into the
> message box. The crash was fixed quickly by another update, but the
> warning persisted. 
>
>>>
>>> Does anyone knows what's going on?
>>>
>>> Cheers,
>>> Alex
>>
>> Hello Alex,
>>
>> This is my first time running into this issue. While I do get this
>> warning message using the Maxima substitute from hydra.gnu.org, when I
>> build Maxima 5.41.0 from source locally, this warning message does not
>> appear. Is this the case for you as well?
>>
> Same for me. I set --prefix during configure and install it
> somewhere. It starts without the warning.
>
>> The message comes from the source code of GNU Common Lisp, but the GCL
>> binary from hydra.gnu.org doesn't give this error when I run it. It
>> seems like this comes down a bug in GCL set off by Maxima, a bug in
>> Maxima, a reproducibility issue, or some combination of all of
>> these. I'll be investigating this further.
>>
>> Thank you,
>> Kei
>
> Thanks for looking at it!

I turns out that the issue is with stratified garbage collection in
GCL. The substitute from hydra.gnu.org does in fact give me the error
when I run "(si::sgc-on t)" in the REPL. I'm preparing a patch to update
GCL to the version used in Debian stable (GCL git tag "pathnames1.13") and
we'll see if changing that definition on the master branch will do anything.


signature.asc
Description: PGP signature

Re: maxima: The SGC segfault recovery test failed with memprotect_bad_fault_address, SGC disabled

[Kei Kebreau]

Alex Vong  writes:

> Hello all,
>
> When I start maxima, I get the following warning message:
>
> The SGC segfault recovery test failed with
> memprotect_bad_fault_address, SGC disabled
> The SGC segfault recovery test failed with
> memprotect_bad_fault_address, SGC disabled
> Maxima 5.41.0 http://maxima.sourceforge.net
> using Lisp GNU Common Lisp (GCL) GCL 2.6.12
> Distributed under the GNU Public License. See the file COPYING.
> Dedicated to the memory of William Schelter.
> The function bug_report() provides bug reporting information.
>
> Actually I encountered this problem quite a while ago after an update,
> but I didn't report it since it was not fetal.

When did you first notice this issue?

>
> Does anyone knows what's going on?
>
> Cheers,
> Alex

Hello Alex,

This is my first time running into this issue. While I do get this
warning message using the Maxima substitute from hydra.gnu.org, when I
build Maxima 5.41.0 from source locally, this warning message does not
appear. Is this the case for you as well?

The message comes from the source code of GNU Common Lisp, but the GCL
binary from hydra.gnu.org doesn't give this error when I run it. It
seems like this comes down a bug in GCL set off by Maxima, a bug in
Maxima, a reproducibility issue, or some combination of all of
these. I'll be investigating this further.

Thank you,
Kei


signature.asc
Description: PGP signature

Re: 01/01: gnu: totem: Enable parallel build.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> Hi,
>
> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit e5f748a6c0c774265f52c7246ee7b80bec6d3522
>> Author: Kei Kebreau <kkebr...@posteo.net>
>> Date:   Wed Nov 8 20:42:20 2017 -0500
>>
>> gnu: totem: Enable parallel build.
>> 
>> * gnu/packages/gnome.scm (totem)[arguments]: Set #:parallel-build? to #t
>> implicitly.
>
> Your commit reverted the preceding commit made to our 'totem' package,
> namely:
>
>> commit a97bfa46cdb782f705204a50a10bca9fa98c56b2
>> Author: Adam Van Ymeren <a...@vany.ca>
>> Date:   Fri Oct 13 12:40:50 2017 -0400
>> 
>> gnu: totem: Disable parallel build due to http://debbugs.gnu.org/28813
>> 
>> Fixes <http://bugs.gnu.org/28813>.
>> 
>> * gnu/packages/gnome.scm (totem)[arguments]: Add #:parallel-build?.
>> 
>> Signed-off-by: Ludovic Courtès <l...@gnu.org>
>
> Unsurprisingly, this caused bug #28813 to re-appear.  Since reverting
> this fix, one of the totem builds failed on Hydra with the same error
> message described in <https://bugs.gnu.org/28813>:
>
>   https://hydra.gnu.org/build/2352092
>
> namely:
>
> [124/150] Compiling Vala source 
> ../totem-3.26.0/src/plugins/sample-vala/totem-sample-vala-plugin.vala.
> FAILED: src/plugins/sample-vala/sample-vala@sha/totem-sample-vala-plugin.c 
> src/plugins/sample-vala/sample-vala.h 
> src/plugins/sample-vala/sample-vala.vapi 
> valac -C --pkg libpeas-1.0 --pkg gtk+-3.0 -d 
> src/plugins/sample-vala/sample-vala@sha --library=sample-vala -H 
> src/plugins/sample-vala/sample-vala.h --vapi ../sample-vala.vapi 
> --girdir=/tmp/guix-build-totem-3.26.0.drv-0/build/src --pkg=Totem-1.0 
> ../totem-3.26.0/src/plugins/sample-vala/totem-sample-vala-plugin.vala
> error: Package `Totem-1.0' not found in specified Vala API directories or 
> GObject-Introspection GIR directories
> Compilation failed: 1 error(s), 0 warning(s)
> [125/150] Linking target src/plugins/ontop/libontop.so.
> [126/150] Linking target src/totem.
> [127/150] Generating Totem-1.0.gir with a custom command.
> ninja: build stopped: subcommand failed.
> phase `build' failed after 15.8 seconds
> builder for `/gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv' 
> failed with exit code 1
> @ build-failed /gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv - 
> 1 builder for `/gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv' 
> failed with exit code 1
>
> I'd like to understand what led you to believe that removing this fix
> was appropriate.  In general, we don't add #:parallel-build? #f without
> a good reason.  The code even included a comment referencing bug #28813.
> I assume that you saw the comment, since you removed it.
>
> So, what made you think that this fix was no longer needed?  Can you
> help me understand how this happened?
>
>   Mark

I mistakenly thought Totem had been updated since that change and I had
built it successfully a few times on my computer. I've reverted this
change on master.


signature.asc
Description: PGP signature

Re: 01/01: gnu: itstool: Update to 2.0.4.

[Kei Kebreau]

Marius Bakke <mba...@fastmail.com> writes:

> Kei Kebreau <kkebr...@posteo.net> writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 13fbd174b5ffe5c2cc59e637f7859d357ab33d97
>> Author: Kei Kebreau <kkebr...@posteo.net>
>> Date:   Thu Nov 2 15:33:08 2017 -0400
>>
>> gnu: itstool: Update to 2.0.4.
>> 
>> * gnu/packages/glib.scm (itstool): Update to 2.0.4.
>> [inputs]: Replace python and python-libxml2 with python-2 and
>> python2-libxml2.
>
> This update broke "gtk-doc", so I reverted it.  Can you look into it?
>
> `itstool` is actually segfaulting:
>
> /gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash:
> line 4: 2798 Segmentation fault itstool -m "${mo}"
> ${d}/C/index.docbook ${d}/C/fdl-appendix.xml
> make[2]: *** [Makefile:523: de/de.stamp] Error 139
> make[2]: *** Waiting for unfinished jobs
> /gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash:
> line 4: 2808 Segmentation fault itstool -m "${mo}"
> ${d}/C/index.docbook ${d}/C/fdl-appendix.xml
> make[2]: *** [Makefile:523: fr/fr.stamp] Error 139

The itstool developers are aware of this problem [0]. The latest itstool
branch builds gtk-doc successfully, but I will wait until the issue is
closed before committing another patch.

[0]: https://github.com/itstool/itstool/issues/17
From 5d08f10d184a661d0ee5ddf13cd894d9299a9e1b Mon Sep 17 00:00:00 2001
From: Kei Kebreau <kkebr...@posteo.net>
Date: Sun, 5 Nov 2017 15:20:50 -0500
Subject: [PATCH] gnu: itstool: Update to 2.0.4.

* gnu/packages/glib.scm (itstool): Update to 2.0.4.
[source]: Apply patch.
[inputs]: Replace python and python-libxml2 with python-2 and python2-libxml2.
* gnu/packages/patches/itstool-fix-segfault.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
---
 gnu/local.mk|  1 +
 gnu/packages/glib.scm   | 10 +++--
 gnu/packages/patches/itstool-fix-segfault.patch | 50 +
 3 files changed, 57 insertions(+), 4 deletions(-)
 create mode 100644 gnu/packages/patches/itstool-fix-segfault.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index dbfe6829e..b45499153 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -744,6 +744,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/ilmbase-fix-tests.patch \
   %D%/packages/patches/intltool-perl-compatibility.patch   \
   %D%/packages/patches/isl-0.11.1-aarch64-support.patch\
+  %D%/packages/patches/itstool-fix-segfault.patch  \
   %D%/packages/patches/jacal-fix-texinfo.patch \
   %D%/packages/patches/java-powermock-fix-java-files.patch \
   %D%/packages/patches/jbig2dec-ignore-testtest.patch  \
diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index bc8775004..71c21bd64 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -395,19 +395,21 @@ The intltool collection can be used to do these things:
 (define itstool
   (package
 (name "itstool")
-(version "2.0.2")
+(version "2.0.4")
 (source (origin
  (method url-fetch)
  (uri (string-append "http://files.itstool.org/itstool/itstool-;
  version ".tar.bz2"))
  (sha256
   (base32
-   "0fh34wi52i0qikgvlmrcpf1vx6gc1xqdad4539l4d9hikfsrz45z"
+   "0q7b4qrc758zfx3adsgvz0r93swdbxjr42w37rahngm33nshihlp"))
+ (patches
+  (search-patches "itstool-fix-segfault.patch"
 (build-system gnu-build-system)
 (inputs
  `(("libxml2" ,libxml2)
-   ("python2-libxml2" ,python2-libxml2)
-   ("python-2" ,python-2)))
+   ("python-libxml2" ,python-libxml2)
+   ("python" ,python)))
 (arguments
  '(#:phases
(modify-phases %standard-phases
diff --git a/gnu/packages/patches/itstool-fix-segfault.patch 
b/gnu/packages/patches/itstool-fix-segfault.patch
new file mode 100644
index 0..ed34aa18b
--- /dev/null
+++ b/gnu/packages/patches/itstool-fix-segfault.patch
@@ -0,0 +1,50 @@
+This patch comes from
+https://github.com/itstool/itstool/commit/9b84c007a73e8275ca45762f1bfa3ab7c3a852e2#diff-d15c1935d231593da203d653eef729ff.
+
+diff -ur a/itstool.in b/itstool.in
+--- a/itstool.in   2017-10-09 12:00:24.0 -0400
 b/itstool.in   2017-11-05 15:10:45.057031963 -0500
+@@ -477,6 +477,7 @@
+ if load_dtd:
+ ctxt.loadSubset(1)
+ if keep_entities:
++ctxt.loadSubset(1)
+ ctxt.ctxtUseOptions(libxml2.XML_PARSE_DTDLOAD)
+ ctxt.replaceEntities(0)
+  

Re: SGE-Pygame mysteriously downgraded on PyPI

[Kei Kebreau]

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

> Hello,
>
> Kei Kebreau <kkebr...@posteo.net> skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi!
>>>
>>> Kei Kebreau <kkebr...@posteo.net> skribis:
>>>
>>>> I don't know if anyone else has noticed, but it seems that our
>>>> sge-pygame package is failing to build because the package version on
>>>> PyPI has downgraded from 1.5.1 to 1.5.
>>>
>>> How can that downgrade lead to a build failure of our package though?
>>>
>>
>> Our sge-pygame definition uses the source code from PyPI, not from GNU
>> Savannah and its mirrors where the project seems to be hosted. Because 
>> version
>> 1.5.1 is no longer available from PyPI servers, our package fails to
>> build.
>>
>> I can change the definition to get the tarball from Savannah and its
>> mirrors because we already do that for python-xsge, a similar package by
>> the same developer.
>
> Ah, got it.
>
> Well, I suggest you should do whichever looks most sensible to you.  If
> the downgrade on PyPI was motivated, but we should probably follow
> suite.  Otherwise, we could simply use the 1.5.1 tarball from Savannah.
>
> Thoughts?
>
> Ludo’.

For any who may be following this thread, I've elected to use the 1.5.1
tarball from Savannah. The code change is in commit
7f652029908f23d85629e2932cc70585ba3e8a1b.


signature.asc
Description: PGP signature

Re: 01/01: gnu: red-eclipse: Add store "data" package path as default.

[Kei Kebreau]

Leo Famulari <l...@famulari.name> writes:

> On Tue, Oct 10, 2017 at 08:26:31AM -0400, Kei Kebreau wrote:
>> kkebreau pushed a commit to branch master
>> in repository guix.
>> 
>> commit 42abb842f64f5dd7834cabd445a5f4d01f1e68a4
>> Author: Adonay Felipe Nogueira <adf...@hyperbola.info>
>> Date:   Sun Aug 20 15:28:20 2017 -0300
>> 
>> gnu: red-eclipse: Add store "data" package path as default.
>> 
>> * gnu/packages/games.scm (red-eclipse): Remove extra spaces. Make version
>> respect documentation.
>> [arguments]: Add "prefix" to make-flags. Add
>>     "add-store-data-package-path-as-default" phase. Improve "copy-data" 
>> phase.
>> 
>> Signed-off-by: Kei Kebreau <kkebr...@posteo.net>
>> ---
>>  gnu/packages/games.scm | 110 
>> ++---
>>  1 file changed, 68 insertions(+), 42 deletions(-)
>
> [...]
>
>> @@ -133,6 +133,7 @@
>>#:use-module (gnu packages gnuzilla)
>>#:use-module (gnu packages icu4c)
>>#:use-module (gnu packages networking)
>> +  #:use-module (guix build utils)
>>#:use-module (guix build-system gnu)
>>#:use-module (guix build-system haskell)
>>#:use-module (guix build-system python)
>
> This module import created an ambiguous reference to 'which':
>
> WARNING: (gnu packages games): `which' imported from both (gnu
> packages base) and (guix build utils)
>
> I don't know if it will be a problem in practice.

It looks like Ludovic took care of this in commit
db9c49f4999d4e5f6eb0565a6a80892131c55670. Thank you for the
notification, though.


signature.asc
Description: PGP signature

Re: SGE-Pygame mysteriously downgraded on PyPI

[Kei Kebreau]

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

> Hi!
>
> Kei Kebreau <kkebr...@posteo.net> skribis:
>
>> I don't know if anyone else has noticed, but it seems that our
>> sge-pygame package is failing to build because the package version on
>> PyPI has downgraded from 1.5.1 to 1.5.
>
> How can that downgrade lead to a build failure of our package though?
>

Our sge-pygame definition uses the source code from PyPI, not from GNU
Savannah and its mirrors where the project seems to be hosted. Because version
1.5.1 is no longer available from PyPI servers, our package fails to
build.

I can change the definition to get the tarball from Savannah and its
mirrors because we already do that for python-xsge, a similar package by
the same developer.


signature.asc
Description: PGP signature

SGE-Pygame mysteriously downgraded on PyPI

[Kei Kebreau]

Hello Guix,

I don't know if anyone else has noticed, but it seems that our
sge-pygame package is failing to build because the package version on
PyPI has downgraded from 1.5.1 to 1.5. I'm not sure why this has
happened, as the recommended version on the SGE-Pygame website is still
1.5.1. This gives me two questions:

1. Do we have a protocol for dealing with this sort of issue?

2. As I've had no luck searching on my own, where can one keep track of
the reasons behind changes like this on PyPI?


signature.asc
Description: PGP signature

Re: Adopt a patch!

[Kei Kebreau]

Pjotr Prins  writes:

> On Thu, Sep 21, 2017 at 10:31:29PM +0200, Ricardo Wurmus wrote:
>> FWIW, I didn’t mean to claim that there are no problems with the
>> email-based workflow.  I just think that we should improve upon it with
>> deliberation instead of jumping to the conclusion that Gitlab or Github
>> would be better.
>
> I think we can have both. We are still stuck in this idea that there
> should only be one tree. The Linux kernel is proving differently.
>
> Pj.

I agree. As long as we aren't solely reliant on a web browser for
contribution, having two interfaces through which to contribute would be
beneficial to people who aren't already familiar with Emacs. Perhaps the
people streamlining the Gitlab and Emacs interfaces can collaborate to
minimize friction between contributions through each interface.


signature.asc
Description: PGP signature

Re: [bug#28453] [PATCH 5/5] gnu: openttd-opengfx: Change installation directory.

[Kei Kebreau]

Kei Kebreau <kkebr...@posteo.net> writes:

> Arun Isaac <arunis...@systemreboot.net> writes:
>
>> Please find attached an updated patchset.
>>
>> Changes are as follows:
>>
>> * Disabled parallel build.
>> * Included a make-reproducible phase for openttd-opensfx.
>> * Changed the license for openmsx from cc-sampling+ to gpl2. It was
>> wrong earlier.
>> * Changed python dependency to python2-minimal for both openttd-openmsx
>> and openttd-opensfx.
>>
>>>From 8e1a146fde935cc1635c7a9f162e95c16871a8cf Mon Sep 17 00:00:00 2001
>> From: Arun Isaac <arunis...@systemreboot.net>
>> Date: Wed, 13 Sep 2017 22:06:12 +0530
>> Subject: [PATCH 1/6] gnu: Add catcodec.
>>
>> * gnu/packages/game-development.scm (catcodec): New variable.
>> ---
>>  gnu/packages/game-development.scm | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/gnu/packages/game-development.scm 
>> b/gnu/packages/game-development.scm
>> index 5633456d4..9916a1cb3 100644
>> --- a/gnu/packages/game-development.scm
>> +++ b/gnu/packages/game-development.scm
>> @@ -11,6 +11,7 @@
>>  ;;; Copyright © 2017 Tobias Geerinckx-Rice <m...@tobias.gr>
>>  ;;; Copyright © 2017 Manolis Fragkiskos Ragkousis <manolis...@gmail.com>
>>  ;;; Copyright © 2017 Peter Mikkelsen <petermikkelse...@gmail.com>
>> +;;; Copyright © 2017 Arun Isaac <arunis...@systemreboot.net>
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -192,6 +193,31 @@ necessary.
>>  ;; The MD5 implementation contained in GRFID is under the zlib license.
>>  (license (list license:gpl2 license:gpl2+ license:zlib
>>  
>> +(define-public catcodec
>> +  (package
>> +(name "catcodec")
>> +(version "1.0.5")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (string-append "https://binaries.openttd.org/extra/catcodec/;
>> +   version "/catcodec-" version "-source.tar.xz"))
>> +   (sha256
>> +(base32
>> + "1qg0c2i4p29sxj0q6qp2jynlrzm5pphz2xhcjqlxa69ycrnlxzs7"
>> +(build-system gnu-build-system)
>> +(arguments
>> + `(#:tests? #f ; no tests
>> +   #:make-flags (list (string-append "prefix=" %output))
>> +   #:phases (modify-phases %standard-phases
>> +  (delete 'configure
>> +(home-page "http://dev.openttdcoop.org/projects/catcodec;)
>> +(synopsis "Encode/decode OpenTTD sounds")
>> +(description "catcodec encodes and decodes sounds for OpenTTD.  These
>> +sounds are not much more than some metadata (description and filename) and 
>> raw
>> +PCM data.")
>> +(license license:gpl2)))
>> +
>>  (define-public gzochi
>>(package
>>  (name "gzochi")
>> -- 
>> 2.14.1
>>
>>>From f5c1a501c9ba193178db40d514aa337807cdfefb Mon Sep 17 00:00:00 2001
>> From: Arun Isaac <arunis...@systemreboot.net>
>> Date: Wed, 13 Sep 2017 22:21:56 +0530
>> Subject: [PATCH 2/6] licenses: Add CC-Sampling+ 1.0.
>>
>> * guix/licenses.scm (cc-sampling-plus-1.0): New variable.
>> ---
>>  guix/licenses.scm | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/guix/licenses.scm b/guix/licenses.scm
>> index b7dadd975..6de611da2 100644
>> --- a/guix/licenses.scm
>> +++ b/guix/licenses.scm
>> @@ -41,6 +41,7 @@
>>  cc0
>>  cc-by2.0 cc-by3.0 cc-by4.0
>>  cc-by-sa2.0 cc-by-sa3.0 cc-by-sa4.0
>> +cc-sampling-plus-1.0
>>  cddl1.0
>>  cecill cecill-b cecill-c
>>  artistic2.0 clarified-artistic
>> @@ -206,6 +207,11 @@ at URI, which may be a file:// URI pointing the 
>> package's tree."
>> "http://creativecommons.org/licenses/by/2.0/;
>> "Creative Commons Attribution 2.0 Generic"))
>>  
>> +(define cc-sampling-plus-1.0
>> +  (license "CC-Sampling+ 1.0"
>> +   "https://creativecommons.org/licenses/sampling+/1.0;
>> +   "Creative Commons Sampling Plus 1.0"))
>> +
>>  (define cddl1.0
>>(license "CDDL 1.0"
>> "http://directory.fsf.org/wiki/License:CDDLv1.0;
>> -- 
>> 2.14.1
>>
>>>From 3c5f0b4ecbe05f7957c324946ab108fce73dd875 Mon Sep 17 00:00:00 2001
>>

Re: ‘staging’ branch

[Kei Kebreau]

Kei Kebreau <kkebr...@posteo.net> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> Ludovic Courtès <l...@gnu.org> writes:
>>
>>> Hello!
>>>
>>> Marius, what’s the status of ‘staging’?  (Sorry I had to pick someone as
>>> the staging master, so to speak.  :-))
>>
>> I've shepherded the last few iterations, so I guess it's only fair!
>>
>> I was waiting for Keis "monster" patch from #27898, but if we are to
>> merge this before 'core-updates' we'll have to start building it now.
>>
>> Tangentially, there's also the Python 3.6 update.  Maybe we can just
>> toss it at 'core-updates', WDYT?
>>
>> @Kei: Feel free to push the patch to 'staging' if you can.  If it
>> doesn't make it until tomorrow, it will probably have to wait until the
>> next 'core-updates' is merged :/
>>
>
> I've updated and attached the patch over the past few hours. I haven't
> tested by building each affected package, so I'm not sure whether it's
> okay to push.
>
>>> Wouldn’t it be nice to merge master in staging, and then merge staging
>>> real soon?
>>
>> I've done the first part.  Will start it tomorrow, unless there are
>> objections.

Barring any objections, I'll be pushing in about an hour.


signature.asc
Description: PGP signature

Re: [bug#28453] [PATCH 5/5] gnu: openttd-opengfx: Change installation directory.

[Kei Kebreau]

Arun Isaac  writes:

> Please find attached an updated patchset.
>
> Changes are as follows:
>
> * Disabled parallel build.
> * Included a make-reproducible phase for openttd-opensfx.
> * Changed the license for openmsx from cc-sampling+ to gpl2. It was
> wrong earlier.
> * Changed python dependency to python2-minimal for both openttd-openmsx
> and openttd-opensfx.
>
>>From 8e1a146fde935cc1635c7a9f162e95c16871a8cf Mon Sep 17 00:00:00 2001
> From: Arun Isaac 
> Date: Wed, 13 Sep 2017 22:06:12 +0530
> Subject: [PATCH 1/6] gnu: Add catcodec.
>
> * gnu/packages/game-development.scm (catcodec): New variable.
> ---
>  gnu/packages/game-development.scm | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/gnu/packages/game-development.scm 
> b/gnu/packages/game-development.scm
> index 5633456d4..9916a1cb3 100644
> --- a/gnu/packages/game-development.scm
> +++ b/gnu/packages/game-development.scm
> @@ -11,6 +11,7 @@
>  ;;; Copyright © 2017 Tobias Geerinckx-Rice 
>  ;;; Copyright © 2017 Manolis Fragkiskos Ragkousis 
>  ;;; Copyright © 2017 Peter Mikkelsen 
> +;;; Copyright © 2017 Arun Isaac 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -192,6 +193,31 @@ necessary.
>  ;; The MD5 implementation contained in GRFID is under the zlib license.
>  (license (list license:gpl2 license:gpl2+ license:zlib
>  
> +(define-public catcodec
> +  (package
> +(name "catcodec")
> +(version "1.0.5")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "https://binaries.openttd.org/extra/catcodec/;
> +   version "/catcodec-" version "-source.tar.xz"))
> +   (sha256
> +(base32
> + "1qg0c2i4p29sxj0q6qp2jynlrzm5pphz2xhcjqlxa69ycrnlxzs7"
> +(build-system gnu-build-system)
> +(arguments
> + `(#:tests? #f ; no tests
> +   #:make-flags (list (string-append "prefix=" %output))
> +   #:phases (modify-phases %standard-phases
> +  (delete 'configure
> +(home-page "http://dev.openttdcoop.org/projects/catcodec;)
> +(synopsis "Encode/decode OpenTTD sounds")
> +(description "catcodec encodes and decodes sounds for OpenTTD.  These
> +sounds are not much more than some metadata (description and filename) and 
> raw
> +PCM data.")
> +(license license:gpl2)))
> +
>  (define-public gzochi
>(package
>  (name "gzochi")
> -- 
> 2.14.1
>
>>From f5c1a501c9ba193178db40d514aa337807cdfefb Mon Sep 17 00:00:00 2001
> From: Arun Isaac 
> Date: Wed, 13 Sep 2017 22:21:56 +0530
> Subject: [PATCH 2/6] licenses: Add CC-Sampling+ 1.0.
>
> * guix/licenses.scm (cc-sampling-plus-1.0): New variable.
> ---
>  guix/licenses.scm | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/guix/licenses.scm b/guix/licenses.scm
> index b7dadd975..6de611da2 100644
> --- a/guix/licenses.scm
> +++ b/guix/licenses.scm
> @@ -41,6 +41,7 @@
>  cc0
>  cc-by2.0 cc-by3.0 cc-by4.0
>  cc-by-sa2.0 cc-by-sa3.0 cc-by-sa4.0
> +cc-sampling-plus-1.0
>  cddl1.0
>  cecill cecill-b cecill-c
>  artistic2.0 clarified-artistic
> @@ -206,6 +207,11 @@ at URI, which may be a file:// URI pointing the 
> package's tree."
> "http://creativecommons.org/licenses/by/2.0/;
> "Creative Commons Attribution 2.0 Generic"))
>  
> +(define cc-sampling-plus-1.0
> +  (license "CC-Sampling+ 1.0"
> +   "https://creativecommons.org/licenses/sampling+/1.0;
> +   "Creative Commons Sampling Plus 1.0"))
> +
>  (define cddl1.0
>(license "CDDL 1.0"
> "http://directory.fsf.org/wiki/License:CDDLv1.0;
> -- 
> 2.14.1
>
>>From 3c5f0b4ecbe05f7957c324946ab108fce73dd875 Mon Sep 17 00:00:00 2001
> From: Arun Isaac 
> Date: Wed, 13 Sep 2017 22:35:02 +0530
> Subject: [PATCH 3/6] gnu: Add openttd-opensfx.
>
> * gnu/packages/games.scm (openttd-opensfx): New variable.
> ---
>  gnu/packages/games.scm | 38 ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
> index 7bfd05cc7..ed386fc84 100644
> --- a/gnu/packages/games.scm
> +++ b/gnu/packages/games.scm
> @@ -2525,6 +2525,44 @@ OpenGFX provides you with...
>  @end enumerate")
>  (license license:gpl2)))
>  
> +(define openttd-opensfx
> +  (package
> +(name "openttd-opensfx")
> +(version "0.2.3")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "https://binaries.openttd.org/extra/opensfx/;
> + version "/opensfx-" version "-source.tar.gz"))
> +   (sha256
> +(base32
> + "03jxgp02ks31hmsdh4xh0xcpkb70ds8jakc9pfc1y9vdrdavh4p5"
> +(build-system 

Re: 01/01: gnu: Put autoconf-related phases immediately after the 'unpack phase.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit d10092b849153dc27cfed0a9601fde6c7bdec918
>> Author: Kei Kebreau <kkebr...@posteo.net>
>> Date:   Sun Jul 30 21:02:35 2017 -0400
>>
>> gnu: Put autoconf-related phases immediately after the 'unpack phase.
>> 
>> * gnu/packages/audio.scm (audacity, rtmidi)[arguments]: Correct phases
>> accordingly.
>> * gnu/packages/bioinformatics.scm (mash, seek, vsearch, emboss,
>> htslib-for-sambamba)[arguments]: Likewise.
>> * gnu/packages/ci.scm (cuirass)[arguments]: Likewise.
>> * gnu/packages/compression.scm (minizip, xdelta)[arguments]: Likewise.
>> * gnu/packages/cpp.scm (libzen)[arguments]: Likewise.
>> * gnu/packages/crypto.scm (opendht)[arguments]: Likewise.
>> * gnu/packages/databases.scm (4store, mdbtools)[arguments]: Likewise.
>> * gnu/packages/debug.scm (stress-make)[arguments]: Likewise.
>> * gnu/packages/dns.scm (dnscrypt-proxy, dnscrypt-wrapper)[arguments]:
>> Likewise.
>> * gnu/packages/emacs.scm (emacs-pdf-tools)[arguments]: Likewise.
>> * gnu/packages/embedded.scm (libjaylink, openocd)[arguments]: Likewise.
>> * gnu/packages/engineering.scm (gerbv)[arguments]: Likewise.
>> * gnu/packages/erlang.scm (erlang)[arguments]: Likewise.
>> * gnu/packages/ftp.scm (weex)[arguments]: Likewise.
>> * gnu/packages/gnome.scm (dia)[arguments]: Likewise.
>> * gnu/packages/gnunet.scm (gnurl, guile-gnunet)[arguments]: Likewise.
>> * gnu/packages/gtk.scm (guile-rsvg, graphene)[arguments]: Likewise.
>> * gnu/packages/guile.scm (guildhall, guile-ics, 
>> guile-sqlite3)[arguments]:
>> Likewise.
>> * gnu/packages/ibus.scm (ibus-libpinyin)[arguments]: Likewise.
>> * gnu/packages/irc.scm (weechat)[arguments]: Likewise.
>> * gnu/packages/java.scm (classpath-devel)[arguments]: Likewise.
>> * gnu/packages/libreoffice.scm (libetonyek)[arguments]: Likewise.
>> * gnu/packages/libusb.scm (hidapi)[arguments]: Likewise.
>> * gnu/packages/linux.scm (gpm)[arguments]: Likewise.
>> * gnu/packages/logging.scm (glog)[arguments]: Likewise.
>> * gnu/packages/machine-learning.scm (ghmm)[arguments]: Likewise.
>> * gnu/packages/mail.scm (dovecot-trees, dovecot-libsodium-plugin, esmtp)
>> [arguments]: Likewise.
>> * gnu/packages/messaging.scm (freetalk, libmesode, 
>> libstrophe)[arguments]:
>> Likewise.
>> * gnu/packages/microcom.scm (microcom)[arguments]: Likewise.
>> * gnu/packages/ocaml.scm (ocaml-ssl)[arguments]: Likewise.
>> * gnu/packages/parallel.scm (slurm)[arguments]: Likewise.
>> * gnu/packages/pdf.scm (libharu)[arguments]: Likewise.
>> * gnu/packages/samba.scm (cifs-utils)[arguments]: Likewise.
>> * gnu/packages/serialization.scm (msgpack)[arguments]: Likewise.
>> * gnu/packages/shells.scm (scsh)[arguments]: Likewise.
>> * gnu/packages/telephony.scm (libiax2)[arguments]: Likewise.
>> * gnu/packages/textutils.scm (dotconf)[arguments]: Likewise.
>> * gnu/packages/version-control.scm (findnewest)[arguments]: Likewise.
>> * gnu/packages/video.scm (libmediainfo, mediainfo)[arguments]: Likewise.
>
> Thanks for working on this, but it looks like you didn't actually test
> building the modified packages.  For example:
>
>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>> index fe43d01..028fe06 100644
>> --- a/gnu/packages/java.scm
>> +++ b/gnu/packages/java.scm
>> @@ -685,7 +685,7 @@ the standard javac executable.  The tool runs on JamVM 
>> instead of SableVM.")))
>> "--disable-gjdoc")
>>   #:phases
>>   (modify-phases %standard-phases
>> -   (add-before 'configure 'bootstrap
>> +   (add-after 'remove-unsupported-anootations 'bootstrap
>>   (lambda _
>> (zero? (system* "autoreconf" "-vif"
>> (add-after 'unpack 'remove-unsupported-annotations
>
> You mispelled 'annotations' in the name of the phase, and thus we lost
> our Java packages.
>
> Since this commit, there are now 119 newly failing jobs:
>
>   https://hydra.gnu.org/eval/109773#tabs-now-fail
>
> I'm not sure how many of these new failures are due to this commit, but
> I suspect many of them are.
>
> Please test before you push to master.
>
>   Mark

This was caused by confusion on my end. I am working right now to find
and fix these errors. Thank you for your notification. My apologies.


signature.asc
Description: PGP signature

Re: NetworkManager instead of Wicd in ‘%desktop-services’?

[Kei Kebreau]

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

> Hello Guix!
>
> Shouldn’t we replace Wicd with NetworkManager in ‘%desktop-services’?
>
> I’ve given it a try on a GuixSD GNOME installation and it appears to
> work well, and it’s obviously well-integrated with GNOME, whereas Wicd
> is a bit hidden (one has to know what to look for) and “foreign.”
>
> Thoughts?
>
> Now, as someone who doesn’t use GNOME, I wonder if NM would work well
> for me.  Last time I tried it’s CLI was too low-level to be usable, and
> I don’t remember seeing a curses interface.  Suggestions?
>
> Thanks,
> Ludo’.

I'm in favor of the change as long as NetworkManager's equivalents to
wicd-gtk and wicd-curses are installed by default. Mark brought up
nmtui; that sounds like something we should enable. Also, it would be
nice to have notifications work (if they don't already) when using
nm-applet. I hear that this depends on xfce4-notifyd?


signature.asc
Description: PGP signature

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> Kei Kebreau <k...@openmailbox.org> writes:
>
>> Mark H Weaver <m...@netris.org> writes:
>>
>>> k...@openmailbox.org (Kei Kebreau) writes:
>>>
>>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>>> ("shared-mime-info" ,shared-mime-info)))
>>>>  (arguments
>>>>   `(#:phases (modify-phases %standard-phases
>>>> +  (add-before
>>>> +   'configure 'autoconf
>>>> +   (lambda _
>>>> + (zero? (system* "./bootstrap"
>>>
>>> In general, autoconf-style phases like this should be put after the
>>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>>> needs to be able to operate on the generated configure script.
>>>
>>> When you move the phase earlier, you may then find that you need to
>>> launch the 'bootstrap' script differently, because its shebang will not
>>> be correct.  That's because it will now be run before the
>>> 'patch-source-shebangs' phase.
>>>
>>> So, the way we normally do this is to run something like:
>>>
>>>   (zero? (system* "sh" "bootstrap"))
>>>
>>> Grepping for "add-before 'configure" reveals that there are now a rather
>>> large number of instances of this problem.  Oh well.
>>>
>>>Mark
>>
>> I see. Thank you for the correction.
>>
>> Do you consider it worth going through the package code and patching
>> this problem specifically or should it be corrected gradually while
>> making other changes?
>
> If you (or anyone else) is willing to work on this, I think it would be
> quite helpful to go through and fix some or all of these problems
> proactively.  It's quite common for people to look at existing packages
> for examples of how things should be done, so the presence of these
> mistakes in our tree will spawn new instances of the same mistake until
> they are eradicated :)
>
> Two things to keep in mind:
>
> * If changing a package would trigger a large number of rebuilds, the
>   change should be made on 'core-updates' instead.
>
> * For each change on 'master', we should make sure the package still
>   builds successfully before pushing it.  That should be enough testing
>   for kind of change.
>
>  Thanks!
>Mark

I'm leaving this message here to let everyone on the list know that this
patch is being worked on. :-)


signature.asc
Description: PGP signature

Re: tor with --expensive-hardening is using way too much memory

[Kei Kebreau]

ng0  writes:

> I noticed this before the contribution entered master, so this message
> is not really a news.
>
> To quote myself from earlier today:
>
>   I think we should revert one piece of the tor hardened build.. 3 
> hours
>uptime: 684.3 MiB + 753.0 KiB = 685.1 MiB   tor
>
> Comparison: my Chromium with 55 tabs open uses 2.2GB.
>
>  Private  +   Shared  =  RAM used   Program
> … 
>  12.4 MiB +   1.1 MiB =  13.4 MiB   vim
>  15.5 MiB + 959.0 KiB =  16.4 MiB   Xorg
>  17.3 MiB +   5.6 MiB =  22.9 MiB   guix substitute
>  22.8 MiB +   1.3 MiB =  24.1 MiB   shepherd
>  26.7 MiB + 551.5 KiB =  27.3 MiB   emacs-25.2
> 131.1 MiB +   6.2 MiB = 137.3 MiB   .guix-real
> 732.7 MiB + 932.0 KiB = 733.6 MiB   tor
> …
> uptime: 6:24h
>
> Now I wouldn't consider tor to be problematic when this would be the
> default for tor. But it isn't, and --enable-expensive-hardening is an
> experimental function which is not enabled by default from upstream (as
> all our recently added config options for tor (not sure right now if all
> are experimental, but they are not standard).
>
> Comparison, Debian running for a very long time (months) and using the
> same config:
>
>  40.6 MiB + 486.0 KiB =  41.1 MiB   tor
>
>
> I'm convinced that removing --enable-expensive-hardening will improve
> the situation, I have watched an VM with tor without this config switch.
> Whoever needs or wants this switch can make use of the easy way to
> create custom packages in Guix.
>
> If someone else can confirm my observations, I'll prepare an patch.

The top(1) command tells me that tor is taking up just short of a
gigabyte of RAM. I haven't tried disabling the --enable-expensive-hardening
flag, yet.


signature.asc
Description: PGP signature

Re: core-updates summer 2017

[Kei Kebreau]

Leo Famulari  writes:

> I just started a new evaluation of core-updates and am reconfiguring my
> GuixSD system based on it.
>
> Let's use this thread to discuss the state of the branch.

Would this be the time to enable the ACL tests as previously discussed?


signature.asc
Description: PGP signature

Re: Inkscape libpoppler error

[Kei Kebreau]

Kei Kebreau <k...@openmailbox.org> writes:

> Daniel Pimentel <d...@d4n1.org> writes:
>
>> Hi guixs,
>>
>> today I updated my GuixSD but my Inkscape not start :(
>>
>> I installed poppler and I reinstaled inkscape too. In my
>> ~/.guix-profile there isn't libpoppler.so.66 but in my system there:
>> /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66
>> /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66
>> /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66
>>
>> Error output:
>> inkscape: error while loading shared libraries: libpoppler.so.66:
>> cannot open shared object file: No such file or directory
>
> Hi Daniel,
>
> I just checked the inkscape package on my computer and I got the same
> error. I'm looking into the problem now. Sorry for the inconvenience.

I've found the source of the issue and I'm seeing about fixing it. In
the meantime, you can reinstall inkscape using the following command:

guix package -i inkscape --no-grafts


signature.asc
Description: PGP signature

Re: Inkscape libpoppler error

[Kei Kebreau]

Daniel Pimentel  writes:

> Hi guixs,
>
> today I updated my GuixSD but my Inkscape not start :(
>
> I installed poppler and I reinstaled inkscape too. In my
> ~/.guix-profile there isn't libpoppler.so.66 but in my system there:
> /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66
> /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66
> /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66
>
> Error output:
> inkscape: error while loading shared libraries: libpoppler.so.66:
> cannot open shared object file: No such file or directory

Hi Daniel,

I just checked the inkscape package on my computer and I got the same
error. I'm looking into the problem now. Sorry for the inconvenience.


signature.asc
Description: PGP signature

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> k...@openmailbox.org (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 5143517c9969d17b48cbb60e1103633bc0cfb430
>> Author: Kei Kebreau <k...@openmailbox.org>
>> Date:   Fri Jul 7 22:58:27 2017 -0400
>>
>> gnu: wxmaxima: Update to 17.05.0.
>> 
>> * gnu/packages/maths.scm (wxmaxima): Update to 17.05.0.
>> [source]: Update URL and add file-name.
>> [native-inputs]: Add autoconf, automake and gettext-minimal.
>> [arguments]: Add 'autoconf' phase.
>
> [...]
>
>> @@ -2172,6 +2176,10 @@ point numbers.")
>> ("shared-mime-info" ,shared-mime-info)))
>>  (arguments
>>   `(#:phases (modify-phases %standard-phases
>> +  (add-before
>> +   'configure 'autoconf
>> +   (lambda _
>> + (zero? (system* "./bootstrap"
>
> In general, autoconf-style phases like this should be put after the
> 'unpack' phase, not before the 'configure' phase.  The reason is that on
> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
> needs to be able to operate on the generated configure script.
>
> When you move the phase earlier, you may then find that you need to
> launch the 'bootstrap' script differently, because its shebang will not
> be correct.  That's because it will now be run before the
> 'patch-source-shebangs' phase.
>
> So, the way we normally do this is to run something like:
>
>   (zero? (system* "sh" "bootstrap"))
>
> Grepping for "add-before 'configure" reveals that there are now a rather
> large number of instances of this problem.  Oh well.
>
>Mark

I see. Thank you for the correction.

Do you consider it worth going through the package code and patching
this problem specifically or should it be corrected gradually while
making other changes?


signature.asc
Description: PGP signature

Re: Xorg tearing fix on Intel HD Graphics 4000

[Kei Kebreau]

Roel Janssen  writes:

> Ricardo Wurmus writes:
>
>> Hi Roel,
>>
>>> With the following patch to the Xorg configuration file, I have a
>>> tear-free GuixSD experience.  I wonder if this is upstreameable in some
>>> way.  This patch is probably too broad in effect.  Can I change it so
>>> that only the graphics card I have will be affected by this patch?
>>
>> I’m not sure about this, but you can apply it only to your system by
>> changing the slim-service’s “startx” value like this:
>>
>> --8<---cut here---start->8---
>> (modify-services %desktop-services
>>   (slim-service-type
>>config => (slim-configuration
>>   (inherit config)
>>   (startx (xorg-start-command
>>#:configuration-file
>>(xorg-configuration-file
>> #:extra-config
>> (list your-fix)))
>> --8<---cut here---end--->8---
>>
>> But I suppose what you want is to apply it unconditionally in Guix and
>> have the X server ignore it for all but this one graphics card, right?
>
> No, not necessarily.  I could no longer do 'guix pull && guix system
> reconfigure ...', which I attempted to solve by upstreaming this patch.
>
> I wonder if anyone else is having the same problem on this hardware..  

I have the same problem on Intel GM45 graphics (in the Thinkpad
X200). I'm going to try Ricardo's snippet as well and see if things get
better.

>
> Thanks for your snippet!  I've done a system reconfigure and the extra
> configuration applied as expected.
>
> If there is anyone with the same problem, we could look further into
> upstreaming it.
>
> Thanks,
> Roel


signature.asc
Description: PGP signature

Re: Acl test investigation

[Kei Kebreau]

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

> Hello Kei,
>
> Kei Kebreau <k...@openmailbox.org> skribis:
>
>> I discovered that the Acl tests are failing partly because the coreutils
>> seemingly aren't compiled with Acl support before the tests are run
>> (even though acl is an input to coreutils). The tests are written with
>> the assumption that the coreutils are built with Acl support. An example
>> is in the sbits-restore.test file, where a sed command is expecting to
>> remove an Acl bit from ls output, but instead removes normal directory
>> permission information.
>>
>> Any ideas on how to resolve this without disabling the Acl tests?
>
> Could you give a bit more context?  On which branch does this failure
> happen?
>

I discovered this on the master branch and there didn't seem to be fixes
on core-updates.

> If the unit tests of the ‘acl’ package check the output of ‘ls’, then
> there’s a circular dependency issue between Coreutils and ACL. I would
> argue that it’s up to Coreutils to test its ‘ls’ command, but in the
> meantime, we could patch ACL to skip its ‘ls’ test.
>

ACL tests still fail later on, but the 'ls' test is easily fixable (just
remove the sed statement that removes the last character). I'll craft
the 'ls' related patch and see if the others can be fixed as well.

> Is this what you were asking?  :-)
>

Yes. Thanks!

> Ludo’.


signature.asc
Description: PGP signature

Acl test investigation

[Kei Kebreau]

I discovered that the Acl tests are failing partly because the coreutils
seemingly aren't compiled with Acl support before the tests are run
(even though acl is an input to coreutils). The tests are written with
the assumption that the coreutils are built with Acl support. An example
is in the sbits-restore.test file, where a sed command is expecting to
remove an Acl bit from ls output, but instead removes normal directory
permission information.

Any ideas on how to resolve this without disabling the Acl tests?


signature.asc
Description: PGP signature

Re: Small package re-organization proposal

[Kei Kebreau]

Leo Famulari <l...@famulari.name> writes:

> On Fri, Jun 16, 2017 at 10:29:09AM +0200, Ricardo Wurmus wrote:
>> 
>> Kei Kebreau <k...@openmailbox.org> writes:
>> 
>> > I think it may be a good idea to consolidate spelling and grammar
>> > packages into language.scm (or a new spelling.scm file if the former is
>> > not appropriate). This would include packages such as aspell and its
>> > dictionaries, hunspell, enchant, and any others that I might be missing.
>> >
>> > Any thoughts on this?
>> 
>> I have no preference here.  I think we should avoid moving around
>> modules between releases, because it needlessly breaks third-party
>> repositories (used with GUIX_PACKAGE_PATH).
>
> Also, I think we should do this kind of reorganization between
> core-updates cycles. Otherwise the merges tend to be trickier.

Okay. Since this is mostly a cosmetic fix (at least that's what it seems
to me), I'm fine with letting it go. It's good to know when these sorts
of things are most appropriate within our development cycle.


signature.asc
Description: PGP signature

Re: 01/01: gnu: gmime: Update to 3.0.1.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> k...@openmailbox.org (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit a512ca81e8998d86770f5a088a9563bc3f24560f
>> Author: Kei Kebreau <k...@openmailbox.org>
>> Date:   Thu Jun 15 22:16:40 2017 -0400
>>
>> gnu: gmime: Update to 3.0.1.
>> 
>> * gnu/packages/mail.scm (gmime): Update to 3.0.1.
>
> This broke the build for 'totem-pl-parser', which in turn breaks gnome.
>
>   https://hydra.gnu.org/eval/109689#tabs-now-fail
>
> We'll need to revert it if it cannot be fixed soon.
>
>  Mark

It looks like gmime >= 3.0 compatibility won't arrive until the next
version of totem-pl-parser. I've reverted the commit.


signature.asc
Description: PGP signature

Small package re-organization proposal

[Kei Kebreau]

I think it may be a good idea to consolidate spelling and grammar
packages into language.scm (or a new spelling.scm file if the former is
not appropriate). This would include packages such as aspell and its
dictionaries, hunspell, enchant, and any others that I might be missing.

Any thoughts on this?


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add fpc. (version 2)

[Kei Kebreau]

Marius Bakke  writes:

> Marius Bakke  writes:
>
>> Just to piggy-back on this discussion, I'm attempting to package
>> "Hedgewars" and needed this patch to get fpc working properly:
>
> Oops, found one more patch in that old branch. @Kei, feel free to squash
> this into the original patch:

Patch "squashed"!


signature.asc
Description: PGP signature

Re: 02/02: gnu: Add s.

[Kei Kebreau]

ng0 <n...@pragmatique.xyz> writes:

> Mark H Weaver transcribed 1.2K bytes:
>> k...@openmailbox.org (Kei Kebreau) writes:
>> 
>> > kkebreau pushed a commit to branch master
>> > in repository guix.
>> >
>> > commit 0e4591bb696a36bc83f75869dd2711987b17b722
>> > Author: ng0 <n...@no-reply.pragmatique.xyz>
>> > Date:   Tue May 16 22:28:58 2017 +
>> >
>> > gnu: Add s.
>> > 
>> > * gnu/packages/shells.scm (s): New variable.
>> > 
>> > Signed-off-by: Kei Kebreau <k...@openmailbox.org>
>> > ---
>> >  gnu/packages/shells.scm | 61 
>> > +
>> >  1 file changed, 61 insertions(+)
>> >
>> > diff --git a/gnu/packages/shells.scm b/gnu/packages/shells.scm
>> > index 5eeb186..5e04e86 100644
>> > --- a/gnu/packages/shells.scm
>> > +++ b/gnu/packages/shells.scm
>> > @@ -503,6 +503,67 @@ Its features include:
>> >  @end enumerate\n")
>> >  (license bsd-2)))
>> >  
>> > +(define-public s
>> > +  (let ((commit "6604341edb3a775ff94415762af3ee9bd86bfb3c")
>> > +(revision "1"))
>> > +(package
>> > +  (name "s")
>> > +  (version (string-append "0.0.0-" revision "." (string-take commit 
>> > 7)))
>> 
>> I think we should rename this package and variable name to 's-shell' or
>> something along those lines.  's' is commonly used as a local variable
>> name.  Single character variable names are in short supply, and I don't
>> think we should allocate them to packages.
>> 
>> Thoughts?
>> 
>>   Mark
>
> I did not think of this use, renaming to s-shell is okay.

I agree.


signature.asc
Description: PGP signature

Re: 01/01: gnu: glib: Update to 2.53.1.

[Kei Kebreau]

Marius Bakke <mba...@fastmail.com> writes:

> Kei Kebreau <k...@openmailbox.org> writes:
>
>> Should I revert the unstable commits on gnome-updates and replace them
>> with their equivalents? I didn't intend to use unstable versions of the
>> GNOME-related software. My intention was to upgrade packages necessary
>> for gjs to build with minimal failures
>> (glib -> gobject-introspection -> gjs).
>
> I moved the contents of 'gnome-updates' to 'staging', so you can just
> make new commits on the staging branch. Let's try to restart it once the
> master queue clears on Hydra.

Alright. Thank you.


signature.asc
Description: PGP signature

Re: 01/01: gnu: glib: Update to 2.53.1.

[Kei Kebreau]

Mark H Weaver <m...@netris.org> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> Kei Kebreau <k...@openmailbox.org> writes:
>>
>>> kkebreau pushed a commit to branch gnome-updates
>>> in repository guix.
>>>
>>> commit 90e0b6024b375f919878414163a6ad5857cc4b3e
>>> Author: Kei Kebreau <k...@openmailbox.org>
>>> Date:   Sun May 21 18:15:00 2017 -0400
>>>
>>> gnu: glib: Update to 2.53.1.
>>> 
>>> * gnu/packages/glib.scm (glib): Update to 2.53.1.
>>
>> Many (most?) of the GNOME-family packages follow an "even/odd"
>> development cycle, where the stable branches have even minor versions.
>> While I couldn't find it mentioned explicitly on the glib homepage, a
>> peek in the git repository suggests that they follow this model:
>>
>> https://git.gnome.org/browse/glib/refs/
>>
>> So I think we should instead go for the most recent 2.52.x release.
>> Can you check whether that is the case for "gobject-introspection" as
>> well?
>>

It appears to be so.

>> `guix refresh` suggests the 1.52.x branch:
>
> Yes, we should always use stable branches unless there is a compelling
> reason to do otherwise.
>
>   Mark

No problem here, especially now that I'm aware of the GNOME version
number scheme.

Should I revert the unstable commits on gnome-updates and replace them
with their equivalents? I didn't intend to use unstable versions of the
GNOME-related software. My intention was to upgrade packages necessary
for gjs to build with minimal failures
(glib -> gobject-introspection -> gjs).


signature.asc
Description: PGP signature