Re: Install hook
pelzflorian (Florian Pelz) writes: > On 03/19/2017 01:14 PM, Julien Lepiller wrote: >> I think install hooks are scripts run after each package installation, >> that are provided by the package itself. We already have a similar >> mechanism that takes place when building the user's profile. See >> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm. >> For instance, we build a icon-theme.cache cache file for every icon >> theme in the user's profile. >> […] >> I think we should make sure that this file is never present in the >> output of a package, and add a function to build it in profiles.scm. >> >> Does it make any sense? >> > > Yes, exactly. These profile hooks look similar to what I meant. Would you like to give it a try to add a profile hook for building “gschemas.compiled” once for all packages in a given profile? Please also email a summary to bug-g...@gnu.org so that we can keep track of this. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Being excellent to one another
dian_ce...@zoho.com writes: > For anyone who reads older books, mankind as a whole used to be refered > to as "he", and while one can certainly make an issue out of that (and > I'm sure plenty of people have), it does also set a precedent for using > the male gender as a gender-neutral option, which happens to have a > rather long history. The generic masculine is a problem. Since the 1970s there have been numerous studies that were published in peer-reviewed journals that demonstrate that the use of so-called generic masculine (in languages with a genus) evokes a disproportionate number of male images compared to gendered split forms or gender neutral terms. As a result the use of generic “he” contributes to the alienation of underrepresented groups, especially in fields like software development. I suggest reading some relevant research articles or a literature review on this subject. > I don't know about anyone > else, but gender == sex, and that is more-or-less that. This is not correct. Gender has little to do with biological sex. That too has been the subject of research for many decades, and I encourage everyone to browse the scientific literature on this matter. Maybe this simplistic view explains your misunderstandings in the rest of your message. >> 1. Try not to offend. >> 2. Try not to be offended. >> 3. Recognise that diversity is an asset. >> 4. Respect the integrity and right to self-definition of all >> participants > > IMO, the 4th guideline there is entirely redundant and already covered > by the 3rd. People, we already *have* a code of conduct. There’s no need to try to come up with one from scratch. Please accept this. > I don't know if it is a cultural thing, or how I was raised, or what, > but as far as I am concerned part of basic social etiquette is roughly > summed up by the first two guidelines in the above list. Call me old > fasioned or a bigot or whatever, but calling a male "he" and a female > "she" is and should be perfectly acceptable, especially in this day and > age. This is nothing to do with fashion. What “should” be acceptable is not up to you to decide. There is no comparison between the distress caused by being “othered”, invalidated, and erased and the minor inconvenience of correcting one’s use of pronouns when talking to or about another person. > This whole issue feels like a general lack of reasonable manners[2] and > interpersonal skills, and not something that really calls for long, > drawn-out thread on the development mailing list. It *is* very simple and our Code of conduct (which is much much shorter than, say, the GPL) reflects that. We ask everyone to respect other people; this includes not to purposefully misgender others, not to poke fun at (= harrass) people who do not confirm to the gender binary, not to make sexist jokes or using sexualised language, etc. > [1] If someone wants to try and explain the issue to me, feel free to > send me a private email, but unless you're actually dealing with this > issue yourself, don't bother. I have no real tolerance for white knights > playing at protecting other people with issues, especially when it comes > to explaining said issues. I have no reason to believe a white knight > has any grasp on the situation that would prove to be useful to me. I very much disagree with this. 1) You cannot expect affected minorities to educate you; there is enough information out there that you can use to do this yourself. 2) As maintainers and developers who make up a community it is our duty to tackle these issues head on to shape the community in a way that ensures a welcoming environment for everyone. As a final note I’d like to state that you can read about these things. Please acknowledge the many researchers in social sciences, who have worked on these issues since decades. It is ill-advised to try to explain away problems that you don’t understand and where you have no theoretical background. The hacker ideal of building models from first principles fails here and is certainly not suited for a sprawling discussion. I recommend more reading on these subjects. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
On Tue, 21 Mar 2017 02:22:11 +0100
John Darrington wrote:
> --- a/gnu/packages/image.scm
> +++ b/gnu/packages/image.scm
> @@ -80,6 +80,8 @@
> (sha256
> (base32
> "0ylgyx93hnk38haqrh8prd3ax5ngzwvjqw5cxw7p9nxmwsfyrlyq"
> (build-system gnu-build-system)
> + (arguments
> +`(#:configure-flags '("LDFLAGS=-lpthread")))
That's libpng-1.6.28, right? I've tried to reproduce the failure on current
'core-updates' master (x86_64-linux). It builds just fine:
$ git describe
v0.12.0-2306-gf826c8c7e
$ ./pre-inst-env guix build libpng --check --no-grafts -K
/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28
At a glance source code of libpng and it's tests does not contain any pthread
calls.
Do you have a build log with the failure? I wonder where missing symbols come
from.
--
Sergei
pgpRcDjFU9ETT.pgp
Description: Цифровая подпись OpenPGP
Re: Being excellent to one another
Hello,
I'm trying to draw this thread to a close as I genuinely believe that
neither side intends malice:
- John genuinely does not see how his statements can very easily be
interpreted as highly disrespectful and even mocking
- myself and others genuinely do not want to bear down on individuals by
virtue of simple miscommunication.
John, I would suggest to you that when at least three independent
individuals read your paragraph in which you (as you confirmed to me) in
good faith tried to create an extreme example to confirm that you would
respect (though fallibly) other people's rights to define their own
identity, then that paragraph was perhaps unfortunately formulated.
An apology and clarification would resolve that matter.
By way of clarification from my side, the paragraph reads like you're
creating a ("humourous") hyperbolic example that is only tangentially
related to the real discussion at hand to begrudgingly admit that you
would be willing to respect other people's identities.
Perhaps in that light you can see how that statement might have
trivialised other people's experiences and have come across as
insulting?
It simply wasn't necessary to employ that rhetorical device — just
acknowledging that you might slip up at times, would have been
sufficient. The rhetorical device turned your genuine sentiment into a
statement in which you seemed to accede and simultaniously implicitly
ridiculed those whom you were acceding to.
I also believe it is within this context that Ludo considered that you
were in breach of the code of conduct. Specifically the example related
to "Trolling or insulting/derogatory comments".
As I say, I do not believe you intended to troll. I hope we can move on
from this thread now by way of agreeing concrete steps for the future.
I would request the following moving forward:
- That we respect people's self-identification (which includes
respecting their pronouns)
- That we accept the "Singular They" as a valid form of non-gendered
language in formal and informal communication (this does not mean *you*
have to use it if you don't want to, but at least don't derail other
people's advice that it is a valid form)
Could we leave it at this for now?
It would be cool if we could get explicit or at least silent agreement
(by no longer responding to the thread) on this thread from those
primarily involved.
Best wishes,
Alex
PS: As Ricardo points out in his email to this thread, the issues of
gender/sex, and more widely, identity are enormously complex & I agree
that we cannot resolve them here. But we can come to a situation where
we treat each other in a way that is non-exclusionary. Part of this
means that we will have conversations like these at irregular intervals
— precisely because these issues are not resolved in society at large,
they will bubble up here.
In the meantime I would encourage people who care about these subjects
to read up on feminist theory, trans politics & intersectional
politics. These are big, complex topics — and no-one agrees with all
that is written, but I believe that we as a community would support most
of the issues raised in those contexts.
John Darrington writes:
> On Mon, Mar 20, 2017 at 04:49:13PM +0100, Ludovic Court??s wrote:
>
> John, people have explained things at length already; you can re-read
> the project???s code of conduct if in doubt. This isn???t up for debate.
> Please stop playing this game right now.
>
> Ludo,
>
> * I am not playing a game - I think this is very serious.
> * I have not breached the code of conduct (at your request I have just read
> it again).
> * I am trying my *utmost* to act with restraint and consideration in the face
> of persistent provocation.
> * I have said on several occasions that we should all agree to live with
> our differences and let this thread stop.
>
> John
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
On Tue, Mar 21, 2017 at 09:09:28AM +, Sergei Trofimovich wrote:
On Tue, 21 Mar 2017 02:22:11 +0100
John Darrington wrote:
> --- a/gnu/packages/image.scm
> +++ b/gnu/packages/image.scm
> @@ -80,6 +80,8 @@
> (sha256
> (base32
"0ylgyx93hnk38haqrh8prd3ax5ngzwvjqw5cxw7p9nxmwsfyrlyq"
> (build-system gnu-build-system)
> + (arguments
> +`(#:configure-flags '("LDFLAGS=-lpthread")))
That's libpng-1.6.28, right? I've tried to reproduce the failure on current
'core-updates' master (x86_64-linux). It builds just fine:
$ git describe
v0.12.0-2306-gf826c8c7e
$ ./pre-inst-env guix build libpng --check --no-grafts -K
/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28
At a glance source code of libpng and it's tests does not contain any
pthread calls.
Do you have a build log with the failure? I wonder where missing symbols
come from.
Yes *IT* builds fine. It's just the thing that depend upon it that don't.
For example look at the most recent build attempt for pspp.
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
signature.asc
Description: Digital signature
Re: Being excellent to one another
May I suggest that those who think “singular they” should not be used just avoid non-gender neutral pronouns and use proper nouns, i.e. names, instead? I believe there is no other alternative. Regards, Florian signature.asc Description: OpenPGP digital signature
Re: Install hook
On 03/21/2017 09:11 AM, Ricardo Wurmus wrote: > > Would you like to give it a try to add a profile hook for building > “gschemas.compiled” once for all packages in a given profile? > I’ll take a closer look at the code and try it. Since packages are shipped as part of Guix anyway, one profile hook in Guix maybe is not worse than allowing hooks to be added to e.g. the glib package in this case. > Please also email a summary to bug-g...@gnu.org so that we can keep > track of this. > Will do.
Re: [PATCH 2/2] gnu: Add GNU Mach.
Awesome Rene, thank you. Manolis
Re: Introducing ‘guix pack’
On Mon 20 Mar 2017 15:14, l...@gnu.org (Ludovic Courtès) writes: > Federico Beffa skribis: > >> If you provide an archive such as >> 'guile-2.2.0-pack-x86_64-linux-gnu.tar.lz' reachable from the main >> project page (especially without any warning about its intended >> purpose), I bet that many peoples will install it and keep it. If more >> projects follow this example, we land to the above scenario where "rm >> -rf /gnu" is not practical at all. Replying to Federico: These are the same considerations as with Guix fwiw, unless you remove old profiles and "guix gc". Another solution to this concern is to remove /gnu/store and re-unpack the tarballs that you still want. Generally though I think we shouldn't expect people to access the store directly; they'd only use /opt/gnu or whatever. In the case that you have upgraded the software, surely the problem is fixed (though of course you may fix the problem for pack A but not pack B). The natural solution is to use a package manager of course, as you note :) > I agree, there’s always a risk. I think what we can do is communicate > about these risks, and avoid using distributing packs in situations that > make it too likely that people will keep the pack without ever > upgrading. Agreed, though I wouldn't over-stress the risks to be honest -- Guix gives both users and distributors the ability to generate a new pack easily. A user can decide not to upgrade even in a system that is managed by Guix. User freedom is all of this :) Andy
Re: Let’s freeze and build ‘core-updates’!
Le 2017-03-20 19:41, Leo Famulari a écrit : On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote: So, here’s a plan: • Once Efraim has pushed some of the aarch64 patches, do another evaluation of the “core” package set for that branch, and check for anything wrong. From there on, forbid full-rebuild changes. • Once the “core” subset builds correctly on all the supported platforms (those that Hydra supports), merge ‘master’. Maybe update a couple of things like GnuTLS while we’re at it. From there on forbid non-trivial changes. • Build all the packages. (To do that, someone with access to Hydra must change the “subset” argument to “all” in the config of the ‘core-updates’ jobset.) • Fix things. We are at this stage... please help :) Here is a list of packages that are failing on core-updates but not on the master branch: https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail It might take a while to load the web page; please have patience :) Once you load it, take note of the brown and red icons. The brown icon means, "we did not try to build this yet, because one of the dependencies failed to build". The red icon means, "we tried to build this and it failed." You should probably focus on these failed builds. I'm sorry if the color-coding is not sufficient for you; we know it's not a good system for people who have impaired vision. My vision is pretty good and I find it hard to pick out the red icons. Once you have found an interesting build failure, read its log (the "raw" log is most useful, in my opinion) and try to reproduce and fix it on your machine. Then send a patch! Sometimes there is a spurious build failure: The SSH connection used for offloading fails, or the build machine is out of memory. Reply to this thread with a link to the failing build and we will restart it. Thanks in advance :) Hi, c-reduce seems to have failed because of a crash in g++. Maybe the server lacked memory? It builds fine here.
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
Hi John,
thanks for looking into the problem.
On Tue, 21 Mar 2017 02:22:11 +0100
John Darrington wrote:
> + (arguments `(#:configure-flags '("LDFLAGS=-lpthread")))
Hmm, that seems to be a very unsafe thing to do.
In order to actually use pthread, one has to switch gcc into pthread mode
(which influences how it handles variables etc).
But just passing "-lpthread" to the linker does no such things and will only
make it link - with the wrong actual instructions in the object files!
Also, even if it worked - by chance -, that seems like papering over the
problem.
It would be better to check out the object files (with objdump -r or objdump
-t) and find out where the symbol is listed as undefined ("U"). Then check the
associated source file whether it actually intended to use pthread.
Pthread is not exactly a modular library that you can just switch on and off at
will.
Re: Being excellent to one another
On Tue, Mar 21, 2017 at 10:14:45AM +0100, Alex Sassmannshausen wrote:
I'm trying to draw this thread to a close as I genuinely believe that
neither side intends malice:
- John genuinely does not see how his statements can very easily be
interpreted as highly disrespectful and even mocking
- myself and others genuinely do not want to bear down on individuals by
virtue of simple miscommunication.
John, I would suggest to you that when at least three independent
individuals read your paragraph in which you (as you confirmed to me) in
good faith tried to create an extreme example to confirm that you would
respect (though fallibly) other people's rights to define their own
identity, then that paragraph was perhaps unfortunately formulated.
An apology and clarification would resolve that matter.
By way of clarification from my side, the paragraph reads like you're
creating a ("humourous") hyperbolic example that is only tangentially
related to the real discussion at hand to begrudgingly admit that you
would be willing to respect other people's identities.
Perhaps in that light you can see how that statement might have
trivialised other people's experiences and have come across as
insulting?
It simply wasn't necessary to employ that rhetorical device ??? just
acknowledging that you might slip up at times, would have been
sufficient. The rhetorical device turned your genuine sentiment into a
statement in which you seemed to accede and simultaniously implicitly
ridiculed those whom you were acceding to.
Alright. I see you have a point, albeit stretched. By way of explanation:
You are right that I deliberately contrived an extreme and rediculous
hypothetical scenario to illustrate a point; or as you put it - a hyberbole.
I DID think about this when I wrote it and I made it absurdly rediculous
precisely *because* I thought doing so would avoid anyone thinking that I was
trying to mock transvestites: Had I said "... a person that looks clearly
like a bloke ..." then that would have been potentially hurtful to
someone reading my mail and trying unsuccessfully to look effeminate. But by
making the scenario extreme and rediculous I considered that this danger would
be eliminated - a person trying to look effeminate, would obviously not have
"a big black wiry beard" - she would be taking hormones - or at the very
least - have shaved. However I realise now that the 6'4" attribute was not
so carefully thought out. That person would have no control over her height.
For this reason it is conceivable that a reader might have thought I was
mocking that hypothetical person. I should have chosen an attribute which the
person could change.
I apologise for not thinking carefully enough about that email before
sending it.
Regarding your other comments, for the avoidance of doubt:
* I have no interest in the sex/race/body-size etc of any Guix contributor.
* I do not begrudge anyone their right to self-identify with whatever genre
pleases the individual concerned.
* I know how it hurts when others deny me the right to voice an opinion so
I will not deny them that same right.
Thank you all for listening.
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
signature.asc
Description: Digital signature
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
On Tue, Mar 21, 2017 at 12:29:05PM +0100, Danny Milosavljevic wrote:
Hi John,
thanks for looking into the problem.
On Tue, 21 Mar 2017 02:22:11 +0100
John Darrington wrote:
> + (arguments `(#:configure-flags '("LDFLAGS=-lpthread")))
Hmm, that seems to be a very unsafe thing to do.
I was afraid you might say that.
In order to actually use pthread, one has to switch gcc into pthread mode
(which influences how it handles variables etc).
But just passing "-lpthread" to the linker does no such things and will
only make it link - with the wrong actual instructions in the object files!
It used to work. Only recently has it stopped working.
So that would seem to confirm to me that a version of gcc (or some other part of
the tool chain) recently checked into core-updates might have been
misconfigured.
Is it possible that somehow pthread mode has been inadvertently switched on?
It would be better to check out the object files (with objdump -r or
objdump -t) and find out where the symbol is listed as undefined ("U"). Then
check the associated source file whether it actually intended to use pthread.
I'm not familiar enough with the internals to know exactly which source file
would be involved. But the error message clearly says to relink libpng and
libfontconfig
using -lpthread. I just did as told.
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
signature.asc
Description: Digital signature
Re: Being excellent to one another
Word of advice: don't use 'transvestite'. It's a slur. To find out why doesn't take very long to search, but for completion: https://www.queerty.com/lets-learn-the-nine-anti-trans-slurs-we-should-avoid-20110620
Re: Being excellent to one another
On Tue, Mar 21, 2017 at 12:17:08PM +, ng0 wrote: Word of advice: don't use 'transvestite'. It's a slur. Is it? I didn't know that. I thought it just came from the latin, (or greek or whatever): trans meaning "across" and "vestment" clothing. It certainly wasn't a slur when I first learnt the word, but meanings change... Thanks for pointing this out. Actually it was a thinko anyway. I meant to type "transgender". J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Re: Being excellent to one another
John Darrington transcribed 1.1K bytes: > On Tue, Mar 21, 2017 at 12:17:08PM +, ng0 wrote: > Word of advice: don't use 'transvestite'. It's a slur. > > Is it? I didn't know that. I thought it just came from the latin, > (or greek or whatever): trans meaning "across" and "vestment" clothing. > It certainly wasn't a slur when I first learnt the word, but > meanings change... Thanks for pointing this out. > > > Actually it was a thinko anyway. I meant to type "transgender". > > J' > > > -- > Avoid eavesdropping. Send strong encrypted email. > PGP Public key ID: 1024D/2DE827B3 > fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 > See http://sks-keyservers.net or any PGP keyserver for public key. > It is a slur when used in the sense like you did it, ie it's a slur for transpeople (not being specific about wether transgender or transsexual was meant). I think if literally transvestite[0] is meant, there are nicer words people chose for selfidentification, but I'd have to ask friends or search for a good introduction which is selfexplanatory. Anyway, we are currently looking into the best way to solve this thread and the issues it showed with Ludovic and Ricardo. [0]: The repetition only because I'm really not sure wether it's a general or only specific slur. If it is in general, I'm sorry.
Re: Being excellent to one another
ng0 transcribed 1.3K bytes: > John Darrington transcribed 1.1K bytes: > > On Tue, Mar 21, 2017 at 12:17:08PM +, ng0 wrote: > > Word of advice: don't use 'transvestite'. It's a slur. > > > > Is it? I didn't know that. I thought it just came from the latin, > > (or greek or whatever): trans meaning "across" and "vestment" clothing. > > It certainly wasn't a slur when I first learnt the word, but > > meanings change... Thanks for pointing this out. > > > > > > Actually it was a thinko anyway. I meant to type "transgender". > > > > J' > > > > > > -- > > Avoid eavesdropping. Send strong encrypted email. > > PGP Public key ID: 1024D/2DE827B3 > > fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 > > See http://sks-keyservers.net or any PGP keyserver for public key. > > > > It is a slur when used in the sense like you did it, ie it's a slur > for transpeople (not being specific about wether transgender or > transsexual was meant). > > I think if literally transvestite[0] is meant, there are nicer words people > chose for selfidentification, but I'd have to ask friends or search for > a good introduction which is selfexplanatory. > > Anyway, we are currently looking into the best way to solve this thread > and the issues it showed with Ludovic and Ricardo. > > [0]: The repetition only because I'm really not sure wether it's a > general or only specific slur. If it is in general, I'm sorry. > Addition, this is a good summary and shows the development of words. Summarized, today it's archaic and perceived as slur by many people. https://www.quora.com/Is-the-term-transvestite-offensive
kodi: LD_LIBRARY_PATH vs. RUNPATH
Hi Marius,
mba...@fastmail.com (Marius Bakke) skribis:
> commit 4b9a5bd990a4c734828571147f9fec01c7053fcc
> Author: Marius Bakke
> Date: Tue Mar 21 07:02:36 2017 +0100
>
> gnu: kodi: Wrap executable so it finds libcurl.
>
> * gnu/packages/kodi.scm (kodi)[arguments]: Add 'wrap' phase.
[...]
> + (add-after 'install 'wrap
> + (lambda* (#:key inputs outputs #:allow-other-keys)
> + (let ((out (assoc-ref outputs "out"))
> + (curl (string-append (assoc-ref inputs "curl") "/lib")))
> + (wrap-program (string-append out "/bin/kodi")
> + `("LD_LIBRARY_PATH" suffix (,curl)))
> + #t))
I think it would be nicer to add libcurl to the RUNPATH of kodi, by
adding -Wl,-rpath=/…/curl/lib to the LDFLAGS for the ‘kodi’ executable,
rather than clobbering LD_LIBRARY_PATH (that’s more “controlled” and
less intrusive).
Perhaps that’s more complicated to do though (finding the right makefile
or makefile variable to pass, etc.)
WDYT?
Thanks,
Ludo’.
PS: Apologies if I missed an earlier discussion of this!
Re: kodi: LD_LIBRARY_PATH vs. RUNPATH
Ludovic Courtès writes:
> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) skribis:
>
>> commit 4b9a5bd990a4c734828571147f9fec01c7053fcc
>> Author: Marius Bakke
>> Date: Tue Mar 21 07:02:36 2017 +0100
>>
>> gnu: kodi: Wrap executable so it finds libcurl.
>>
>> * gnu/packages/kodi.scm (kodi)[arguments]: Add 'wrap' phase.
>
> [...]
>
>> + (add-after 'install 'wrap
>> + (lambda* (#:key inputs outputs #:allow-other-keys)
>> + (let ((out (assoc-ref outputs "out"))
>> + (curl (string-append (assoc-ref inputs "curl") "/lib")))
>> + (wrap-program (string-append out "/bin/kodi")
>> + `("LD_LIBRARY_PATH" suffix (,curl)))
>> + #t))
>
> I think it would be nicer to add libcurl to the RUNPATH of kodi, by
> adding -Wl,-rpath=/…/curl/lib to the LDFLAGS for the ‘kodi’ executable,
> rather than clobbering LD_LIBRARY_PATH (that’s more “controlled” and
> less intrusive).
>
> Perhaps that’s more complicated to do though (finding the right makefile
> or makefile variable to pass, etc.)
>
> WDYT?
I agree, this was a lazy fix on my part to enable some expected
functionality (scraping, add-ons) because I could not figure out how to
pass LDFLAGS (the environment variable was not enough).
Will work on a proper fix; adding it to the 'kodi-test' executable
should also sort the failing web tests, methinks.
signature.asc
Description: PGP signature
cURL release 7.54.0 release schedule [Fwd: 7.54.0 feature freeze tomorrow]
Hi, message below forwarded for cURL maintaining people in Guix. 7.54.0 is scheduled for 2017-04-19 if all goes as planned. - Forwarded message from Daniel Stenberg - Date: Tue, 21 Mar 2017 09:01:27 +0100 (CET) From: Daniel Stenberg To: libcurl hacking Subject: 7.54.0 feature freeze tomorrow Hi team, Tomorrow is the last day to land any new features for the coming 7.54.0 release, which basically means you need to already have the feature in review to have a chance. If you have something that we seem to have dropped and you want it in, please remind us and bring it back to the table and let's see what we can do. Then on, we will do bug fixes for another 4 weeks and ship the next release on April 19 - if everything goes as planned. Your help in doing this is very much appreciated! -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html - End forwarded message -
Re: Let?s freeze and build ?core-updates?!
Hi,
Once you have found an interesting build failure, read its log (the
"raw" log is most useful, in my opinion) and try to reproduce and fix
it
on your machine. Then send a patch!
Sometimes there is a spurious build failure: The SSH connection used
for
offloading fails, or the build machine is out of memory. Reply to this
thread with a link to the failing build and we will restart it.
Attachment patch for xf86-video-vmware-13.2.1.
https://hydra.gnu.org/build/1932198From d5dd0ab353fca180f122210c68297a0d66abec37 Mon Sep 17 00:00:00 2001
From: rennes
Date: Tue, 21 Mar 2017 08:10:58 -0600
Subject: [PATCH] gnu: xf86-video-vmware: Fix build.
* gnu/packages/xorg.scm (xf86-video-vmware)[inputs]: Add llvm.
---
gnu/packages/xorg.scm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm
index 266ac78fb..11ce611c4 100644
--- a/gnu/packages/xorg.scm
+++ b/gnu/packages/xorg.scm
@@ -12,6 +12,7 @@
;;; Copyright © 2016 David Craven
;;; Copyright © 2016, 2017 John Darrington
;;; Copyright © 2017 Marius Bakke
+;;; Copyright © 2017 Rene Saavedra
;;;
;;; This file is part of GNU Guix.
;;;
@@ -51,6 +52,7 @@
#:use-module (gnu packages image)
#:use-module (gnu packages libbsd)
#:use-module (gnu packages linux)
+ #:use-module (gnu packages llvm)
#:use-module (gnu packages m4)
#:use-module (gnu packages ncurses)
#:use-module (gnu packages perl)
@@ -3356,6 +3358,7 @@ X server.")
(inputs
`(("libx11" ,libx11)
("libxext" ,libxext)
+ ("llvm" ,llvm)
("mesa" ,mesa) ; for xatracker
("xorg-server" ,xorg-server)))
(native-inputs
--
2.12.0
Re: [GSoC] Development of Cuirass.
Hi, Mathieu Lirzin writes: > Here is my proposal for the Google Summer of Code 2017. I have updated it, according to the various feedback I had. Here is the link: http://mathieu.lirzin.emi.u-bordeaux.fr/gsoc/guix.html I must say that given the current agitation in Guix community for gender related issues, I am sorry to say that I withdraw my proposal. A majority of people in this community seems to adhere to political ideas related to feminism and LGBT causes and are very vocal about it. While I respect people having such conviction, the fact that those ideas/values are repeatedly presented as if every one should adhere to them is not welcoming for those who disagree. As a consequence I would rather spend my time working on Free Software projects that I consider more tolerant. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [GSoC] Development of Cuirass.
Hi Mathieu, Mathieu Lirzin skribis: > A majority of people in this community seems to adhere to political > ideas related to feminism and LGBT causes and are very vocal about it. > While I respect people having such conviction, the fact that those > ideas/values are repeatedly presented as if every one should adhere to > them is not welcoming for those who disagree. You’ve said it before and that’s a misunderstanding. Ricardo and I, as maintainers, are trying to acknowledge an issue that is very real in free software and tech groups, and we’re doing the little we can do to avoid these problems in our group. There is nothing you or I lose. > As a consequence I would rather spend my time working on Free Software > projects that I consider more tolerant. Very harsh to say the least. :-( Good luck with your future endeavors. Ludo’.
[EOT] Re: Being excellent to one another
John, > * I am not playing a game - I think this is very serious. > * I have not breached the code of conduct (at your request I have just read > it again). > * I am trying my *utmost* to act with restraint and consideration in the face > of persistent provocation. > * I have said on several occasions that we should all agree to live with > our differences and let this thread stop. thank you for your clarification. We’d like to end discussions in this thread, so let me just make a final statement on behalf of the maintainers. Some of your comments in this thread were considered derogatory, and they actively made at least one participant uncomfortable. This outcome is undesirable and as a group we need to make sure it does not happen again. Re-reading the thread I see that some of your earlier off-topic statements in the thread can be interpreted as antagonising, even if you hold they were not *meant* to be hurtful or trolling. The same applies to some comments and examples that were made in later messages to illustrate your points. ng0 asked for multiple times that “singular they” be used when referring to them. Your response to the use of “singular they” was “I refuse to use it”. 1. In the future, please respect the gender of participants by using the pronouns they ask for (when they do). Alternatively, use their names instead of pronouns. 2. Avoid assumptions by using gender-neutral wording. This project considers this form of respect to be more important than what some might consider “good English grammar”. We also acknowledge that there have been harsh messages on both sides, including personal insults; this is also not in the spirit of mutual respect that the code of conduct suggests, the foundation for communications in this group. It doesn’t have to be this way. Like you wrote above, we can agree to live with our differences and respect them. Let’s stop this thread and continue in the spirit of the code of conduct. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net PS: If any of the participants feel that we have handled this case in an unsatisfactory manner, please write to the maintainers (Ludo and myself) off list. signature.asc Description: PGP signature
Re: bug#26201: No notification of cache misses when downloading substitutes
On 21/03/17 16:35, dian_ce...@zoho.com wrote: > Florian Pelz wrote: >> If it cached everything, it wouldn’t be a cache? > > If the point is to reduce the load on hydra, then at some point it > could have everything. If it doesn't, then why have a mirror when it's > just pulling right the source all the time anyways? Quite the opposite. That would raise the load on Hydra even further. Kind regards, T G-R signature.asc Description: OpenPGP digital signature
Re: bug#26201: No notification of cache misses when downloading substitutes
On Tue, 21 Mar 2017 17:02:29 +0100 Tobias Geerinckx-Rice wrote: > On 21/03/17 16:35, dian_ce...@zoho.com wrote: > > Florian Pelz wrote: > >> If it cached everything, it wouldn’t be a cache? > > > > If the point is to reduce the load on hydra, then at some point it > > could have everything. If it doesn't, then why have a mirror when > > it's just pulling right the source all the time anyways? > > Quite the opposite. That would raise the load on Hydra even further. As I stated before in the bug (#26201), I'd prefer someone else respond to this. At this point the breakdown in communication is starting to feel like mockery.
Re: bug#26201: No notification of cache misses when downloading substitutes
On 21/03/17 17:13, dian_ce...@zoho.com wrote: > As I stated before in the bug (#26201), I'd prefer someone else respond > to this. At this point the breakdown in communication is starting to > feel like mockery. I'd already posted an invitation to do so on IRC. I'm sure someone will find their way here. Your hostility is unwarranted. You've made your intentions abundantly clear. :-( T G-R signature.asc Description: OpenPGP digital signature
Re: GuixSD download options
Hi, pot...@riseup.net skribis: > since the installation process is quite manual, takes long and ends in a > VM image for users who don't want to replace their current system, I > think there should be at least an option to download a tar file with the > content of a preconfigured root file system. The installation image is actually a full-blown GuixSD. You can run ‘guix package’ in it, etc. Granted, you’re probably looking for something more directly usable, with Xorg and stuff. We could publish such an image; the problem then becomes disk space on the gnu.org servers. ;-) That said, it’s easy to build one for you even if you don’t run GuixSD: you can install Guix on your distro, whichever it is, and from there use ‘guix system vm’ to build a GuixSD image. https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html Would that be helpful? Ludo’.
Re: bug#26201: No notification of cache misses when downloading substitutes
On Tue, 21 Mar 2017 17:33:37 +0100 Tobias Geerinckx-Rice wrote: > On 21/03/17 17:13, dian_ce...@zoho.com wrote: > > As I stated before in the bug (#26201), I'd prefer someone else > > respond to this. At this point the breakdown in communication is > > starting to feel like mockery. > > I'd already posted an invitation to do so on IRC. I'm not always looking at my IRC window, so I missed that. In any instance, it seems Ludo has picked up on this in the bugreport.
Re: [GSoC] Development of Cuirass.
Mathieu Lirzin writes: > I must say that given the current agitation in Guix community for gender > related issues, I am sorry to say that I withdraw my proposal. Sorry to hear that. > A majority of people in this community seems to adhere to political > ideas related to feminism and LGBT causes and are very vocal about it. > While I respect people having such conviction, the fact that those > ideas/values are repeatedly presented as if every one should adhere to > them is not welcoming for those who disagree. > > As a consequence I would rather spend my time working on Free Software > projects that I consider more tolerant. Wow, I'm shocked to read this! Let me check. Are you saying that condoning disrespectful/non-considerate behaviour is actually "tolerance" and preferrable when building a community? Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: bug#26201: No notification of cache misses when downloading substitutes
Mmm... Forbidden reply. dian_ce...@zoho.com wrote: >> As I stated before in the bug (#26201), [...] > In any instance, it seems Ludo has picked up on this in the bugreport. Oh no. Now I get it. I just realised I managed to shunt this debbugs thread onto guix-devel somehow. As if there wasn't enough going on. Sorry everyone! Kind regards, T G-R signature.asc Description: OpenPGP digital signature
Re: [GSoC] Development of Cuirass.
Mathieu, On 21/03/17 15:31, Mathieu Lirzin wrote: > I must say that given the current agitation in Guix community for gender > related issues, I am sorry to say that I withdraw my proposal. I'm also very sorry to see you go. > As a consequence I would rather spend my time working on Free Software > projects that I consider more tolerant. I hope you find whatever it is you're looking for. Kind regards, T G-R signature.asc Description: OpenPGP digital signature
Re: GuixSD download options
Hi, thanks for the answer, the general idea is to have a something like a tar.gz without initrd and kernel but with a working /sbin/init file. Regards, Kai
Re: Let’s freeze and build ‘core-updates’!
On Tue, Mar 21, 2017 at 12:16:20PM +0100, julien lepiller wrote: > c-reduce seems to have failed because of a crash in g++. Maybe the server > lacked memory? It builds fine here. Thanks for checking on the log! Indeed, errors like this one... g++: internal compiler error: Killed (program cc1plus) ... typically indicate an out-of-memory condition. So, I restarted the build. signature.asc Description: PGP signature
Re: Advice about GuixSD on Serveraptor?
On Sun, Mar 12, 2017 at 08:32:52PM -0400, Leo Famulari wrote: > I had wanted to use the GuixSD installer because the image format > conversion is reproducible. So, nobody would have to trust me to provide > the right thing. > > Of course, it would be a lot simpler if we made a barebones system with > `guix system vm-image`. > > If we can't use the installer, how should we create and provide another > image? Any advice or guidance? I can easily create an image to use for this, but I don't want to do it if others think I am going beyond the level of trust placed in me by the Guix project. signature.asc Description: PGP signature
Re: Let?s freeze and build ?core-updates?!
On Tue, Mar 21, 2017 at 08:22:29AM -0600, ren...@openmailbox.org wrote: > Attachment patch for xf86-video-vmware-13.2.1. > > https://hydra.gnu.org/build/1932198 > From d5dd0ab353fca180f122210c68297a0d66abec37 Mon Sep 17 00:00:00 2001 > From: rennes > Date: Tue, 21 Mar 2017 08:10:58 -0600 > Subject: [PATCH] gnu: xf86-video-vmware: Fix build. > > * gnu/packages/xorg.scm (xf86-video-vmware)[inputs]: Add llvm. Thanks, pushed! By the way, I couldn't apply your patch because the text encoding seems to different from what is in the Git repo. So, I recreated it from scratch. > --- > gnu/packages/xorg.scm | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm > index 266ac78fb..11ce611c4 100644 > --- a/gnu/packages/xorg.scm > +++ b/gnu/packages/xorg.scm > @@ -12,6 +12,7 @@ > ;;; Copyright ?? 2016 David Craven > ;;; Copyright ?? 2016, 2017 John Darrington > ;;; Copyright ?? 2017 Marius Bakke > +;;; Copyright ?? 2017 Rene Saavedra For example, the copyright © symbols are replaced by two question marks here. I'm not sure if this is a problem on my end or yours. And it looks like the subject line might be messed up: http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00651.html signature.asc Description: PGP signature
Re: cURL release 7.54.0 release schedule [Fwd: 7.54.0 feature freeze tomorrow]
On Tue, Mar 21, 2017 at 02:06:33PM +, ng0 wrote: > Hi, > > message below forwarded for cURL maintaining people in Guix. > 7.54.0 is scheduled for 2017-04-19 if all goes as planned. Thanks for the notice. We'll be ready :)
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
Hi, I forgot to say: gcc pthread mode is activated via option "-pthread". It enables thread-local storage for some things (errno etc) and uses reentrant versions of some functions. Which packages are the ones that is depending on libpng and failing? I can have a look...
Re: [GSoC] Development of Cuirass.
On Tue, Mar 21, 2017 at 03:31:01PM +0100, Mathieu Lirzin wrote: > Hi, > > Mathieu Lirzin writes: > > > Here is my proposal for the Google Summer of Code 2017. > > I have updated it, according to the various feedback I had. Here is the > link: > > http://mathieu.lirzin.emi.u-bordeaux.fr/gsoc/guix.html > > I must say that given the current agitation in Guix community for gender > related issues, I am sorry to say that I withdraw my proposal. > > A majority of people in this community seems to adhere to political > ideas related to feminism and LGBT causes and are very vocal about it. > While I respect people having such conviction, the fact that those > ideas/values are repeatedly presented as if every one should adhere to > them is not welcoming for those who disagree. > > As a consequence I would rather spend my time working on Free Software > projects that I consider more tolerant. I'm really disappointed that this is the result of that discussion. I do think that Ludovic is right: we lose nothing by trying to address the gender imbalance in our community. I sincerely hope you'll reconsider leaving the Guix project. And if you keep your decision, I wish you luck in whatever you do. Sincerely, Leo signature.asc Description: PGP signature
Re: [PATCH] gnu: Add lmms
On Thu, Mar 16, 2017 at 10:54:09PM -0700, Rodger Fox wrote: > > Apparently, LMMS can be built with Qt 5: > > > > https://github.com/LMMS/lmms/wiki/Compiling-lmms#using-qt5 > > > > Can you try it and let us know how it goes? > > Ok, I looked into this. Qt5 is supported only in the newest development > version of lmms, but what I packaged is the latest stable release. > > I will make a note of this for when I update the package, but what can > we do for the mean time? Accept this as is? Package the release > candidiate? Or just wait for the next stable release of lmms before > adding this to guix? > > To be honest, the RC looks like it has some cool new features, so I > will probably be building it for myself either way. Also, lmms is on > a pretty slow release cycle. The last stable was 2015, RC-1 was > early 2016, and RC-2 was Jan 2017. So maybe if it seems stable enough > when I build it I can package the RC-2. I could do one for each if that > makes sense, kind of like the guile and guile-next packages. > What do you think? lmms and lmms-rc? I think it's fine to package the stable release with qt-4, with a comment in the package definition indicating that we should try qt-5 when upgrading.
Re: [PATCH] gnu: Add lmms
On Wed, Mar 08, 2017 at 08:47:03PM -0800, Rodger Fox wrote: > Sorry for the delay. I got the rpath issue fixed on this. > It should be ready to apply now. > > -Rodger Fox > From 70f155cd4bde3060b87c0834f12f71886c1e0f3f Mon Sep 17 00:00:00 2001 > From: Rodger Fox > Date: Wed, 8 Mar 2017 20:28:10 -0800 > Subject: [PATCH] gnu: Add lmms. > > * gnu/packages/music.scm (lmms): New variable. Pushed as a42619e5e211ed2511f71029ee2c5777c0f54c3b, thanks! PS— The patch did not apply cleanly due to text encoding problems. For example, the copyright symbols are garbled: > ;;; Copyright ?? 2016 John J. Foerch > ;;; Copyright ?? 2016 Alex Griffin > ;;; Copyright ?? 2017 ng0 > +;;; Copyright ?? 2017 Rodger Fox And you can see similar issues in the patch as provided by mailing list's web interface: http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00268.html I'm not sure what do to about this. signature.asc Description: PGP signature
Re: Advice about GuixSD on Serveraptor?
Leo Famulari writes: > On Sun, Mar 12, 2017 at 08:32:52PM -0400, Leo Famulari wrote: >> I had wanted to use the GuixSD installer because the image format >> conversion is reproducible. So, nobody would have to trust me to provide >> the right thing. >> >> Of course, it would be a lot simpler if we made a barebones system with >> `guix system vm-image`. >> >> If we can't use the installer, how should we create and provide another >> image? > > Any advice or guidance? > > I can easily create an image to use for this, but I don't want to do it > if others think I am going beyond the level of trust placed in me by the > Guix project. So, if you provided the source scheme to generate the image, and signed the image, people would both have the option to generate the image themselves, or download your signed binary image if they trust you? Honestly, at this point the most important thing is to get things to the point where we have *a* documented process to install GuixSD on these servers; once we have that, and assuming we also have documentation / tooling where people could reproduce the whole process (even if they used the image you provided, as long as they could reproduce that step too) I think we're in a much better state than we are... and we could refine further from there. My opinion, anyway! - Chris
Re: Advice about GuixSD on Serveraptor?
On Tue, Mar 21, 2017 at 03:22:43PM -0500, Christopher Allan Webber wrote: > Leo Famulari writes: > > I can easily create an image to use for this, but I don't want to do it > > if others think I am going beyond the level of trust placed in me by the > > Guix project. > > So, if you provided the source scheme to generate the image, and signed > the image, people would both have the option to generate the image > themselves, or download your signed binary image if they trust you? Not exactly... Serveraptor offers users a set of images to choose from, but they don't have a method by which users can upload their own images. You'd have to make a special arrangement for that. So what I'm doing here is trying to provide Serveraptor with a GuixSD image that they'd offer to users. People could regenerate the image themselves, but it would be difficult to verify that it matches what is offered by Serveraptor. There are VPS providers that provide an image upload system but, as far as I know, none of them accept raw QEMU images. They all want ISO-formatted images. > Honestly, at this point the most important thing is to get things to the > point where we have *a* documented process to install GuixSD on these > servers; once we have that, and assuming we also have documentation / > tooling where people could reproduce the whole process (even if they > used the image you provided, as long as they could reproduce that step > too) I think we're in a much better state than we are... and we could > refine further from there. My idea is to create a bare-bones GuixSD image using `guix system vm-image` and provide that to Serveraptor. Users would boot directly into the system and reconfigure it to fit their needs. If by "install GuixSD" you mean "boot the GuixSD USB install and initialize the system", that does work, but it's not very satisfying because Serveraptor's management interface does not expose the virtualized storage devices, so it's difficult (impossible?) to reclaim the partition used by the installer. signature.asc Description: PGP signature
Re: Install hook
On Tue, 2017-03-21 at 11:06 +0100, pelzflorian (Florian Pelz) wrote: > On 03/21/2017 09:11 AM, Ricardo Wurmus wrote: > > > > Would you like to give it a try to add a profile hook for building > > “gschemas.compiled” once for all packages in a given profile? > > > > I’ll take a closer look at the code and try it. Since packages are > shipped as part of Guix anyway, one profile hook in Guix maybe is not > worse than allowing hooks to be added to e.g. the glib package in this case. > > > Please also email a summary to bug-g...@gnu.org so that we can keep > > track of this. > > > > Will do. > Sorry. I’m feeling a little stupid. GSettings checks each entry in XDG_DATA_DIRS for a gschemas.compiled file, so compiling the settings for each package individually does work. The issue with the app I was trying to run was elsewhere. Now, all GSettings could still be compiled in a profile hook to a single gschemas.compiled file to eliminate the annoying warning message about “arbitrarily choosing” one of them. I have seen an mlet for the first time today, so I’m not going to fix this. I’m also not sure if this is really better than what (guix build glib-or-gtk-build-system) does. I’m also not going to file a bug since I’m not sure if we even want to change the current method.
Re: Advice about GuixSD on Serveraptor?
On Tue, Mar 21, 2017 at 04:46:20PM -0400, Leo Famulari wrote: > So what I'm doing here is trying to provide Serveraptor with a GuixSD > image that they'd offer to users. > > People could regenerate the image themselves, but it would be difficult > to verify that it matches what is offered by Serveraptor. And to clarify my previous question: Should this QEMU image be created by me, or should it be created by a Guix maintainer as part of the Guix release process? signature.asc Description: PGP signature
Re: Advice about GuixSD on Serveraptor?
Leo Famulari transcribed 3.0K bytes: > On Tue, Mar 21, 2017 at 03:22:43PM -0500, Christopher Allan Webber wrote: > > Leo Famulari writes: > > > I can easily create an image to use for this, but I don't want to do it > > > if others think I am going beyond the level of trust placed in me by the > > > Guix project. > > > > So, if you provided the source scheme to generate the image, and signed > > the image, people would both have the option to generate the image > > themselves, or download your signed binary image if they trust you? > > Not exactly... > > Serveraptor offers users a set of images to choose from, but they don't > have a method by which users can upload their own images. You'd have to > make a special arrangement for that. > > So what I'm doing here is trying to provide Serveraptor with a GuixSD > image that they'd offer to users. > > People could regenerate the image themselves, but it would be difficult > to verify that it matches what is offered by Serveraptor. > > There are VPS providers that provide an image upload system but, as far > as I know, none of them accept raw QEMU images. They all want > ISO-formatted images. IN-Berlin wants a raw image (they have read our documentation). The way their system works is that you sent them your ssh pubkey, they initialize a basic Debian system depending on the size you chose, and you can login once you get the hostname etc. They have an out-of-band consoleserver where the ssh key is placed aswell for the machine. I don't work with this non-profit organization, but having a way to define ssh pubkeys in the system config would be super useful for this. Right now I'm about to create my own system and just sent it to them as soon as I feel up to it. If they could simply create the system in their infrastructure, that would be an incredible speedup and reproducible. I don't know much about the out of band consoleserver, I have to ask if that's somehow relevant or if it simply needs some initrd settings to expose it to the server. > > Honestly, at this point the most important thing is to get things to the > > point where we have *a* documented process to install GuixSD on these > > servers; once we have that, and assuming we also have documentation / > > tooling where people could reproduce the whole process (even if they > > used the image you provided, as long as they could reproduce that step > > too) I think we're in a much better state than we are... and we could > > refine further from there. > > My idea is to create a bare-bones GuixSD image using `guix system > vm-image` and provide that to Serveraptor. Users would boot directly > into the system and reconfigure it to fit their needs. > > If by "install GuixSD" you mean "boot the GuixSD USB install and > initialize the system", that does work, but it's not very satisfying > because Serveraptor's management interface does not expose the > virtualized storage devices, so it's difficult (impossible?) to reclaim > the partition used by the installer.
Re: Let’s freeze and build ‘core-updates’!
On Mon, 20 Mar 2017 14:41:45 -0400 Leo Famulari wrote: > We are at this stage... please help :) > > Here is a list of packages that are failing on core-updates but not on > the master branch: > > https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail > > It might take a while to load the web page; please have patience :) Hi, zsh (https://hydra.gnu.org/build/1883646) failed but the last line is: build-succeeded /gnu/store/8q928a90f08qc3nfsdf4h39lx8yyr8pm-zsh-5.2.drv
guix in discussion on ycombinator hacker news
In case you missed it: https://news.ycombinator.com/item?id=13914260
Re: Let’s freeze and build ‘core-updates’!
Julien Lepiller writes: > zsh (https://hydra.gnu.org/build/1883646) failed but the last line is: > > build-succeeded /gnu/store/8q928a90f08qc3nfsdf4h39lx8yyr8pm-zsh-5.2.drv That was probably a transient failure. It’s currently marked as “Scheduled to be built”. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Let’s freeze and build ‘core-updates’!
On Tue, Mar 21, 2017 at 10:19:02PM +0100, Julien Lepiller wrote: > On Mon, 20 Mar 2017 14:41:45 -0400 > Leo Famulari wrote: > > > We are at this stage... please help :) > > > > Here is a list of packages that are failing on core-updates but not on > > the master branch: > > > > https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail > > > > It might take a while to load the web page; please have patience :) > > Hi, > > zsh (https://hydra.gnu.org/build/1883646) failed but the last line is: > > build-succeeded /gnu/store/8q928a90f08qc3nfsdf4h39lx8yyr8pm-zsh-5.2.drv Thanks, I've restarted the build. signature.asc Description: PGP signature
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
On Tue, 21 Mar 2017 10:17:26 +0100
John Darrington wrote:
> On Tue, Mar 21, 2017 at 09:09:28AM +, Sergei Trofimovich wrote:
> On Tue, 21 Mar 2017 02:22:11 +0100
> John Darrington wrote:
>
> > --- a/gnu/packages/image.scm
> > +++ b/gnu/packages/image.scm
> > @@ -80,6 +80,8 @@
> > (sha256
> > (base32
> "0ylgyx93hnk38haqrh8prd3ax5ngzwvjqw5cxw7p9nxmwsfyrlyq"
> > (build-system gnu-build-system)
> > + (arguments
> > +`(#:configure-flags '("LDFLAGS=-lpthread")))
>
> That's libpng-1.6.28, right? I've tried to reproduce the failure on
> current
> 'core-updates' master (x86_64-linux). It builds just fine:
>
> $ git describe
> v0.12.0-2306-gf826c8c7e
>
> $ ./pre-inst-env guix build libpng --check --no-grafts -K
> /gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28
>
> At a glance source code of libpng and it's tests does not contain any
> pthread calls.
>
> Do you have a build log with the failure? I wonder where missing symbols
> come from.
>
>
> Yes *IT* builds fine. It's just the thing that depend upon it that don't.
> For example look at the most recent build attempt for pspp.
Aha. I was not sure where to look at. Assuming hydra build at:
https://hydra.gnu.org/jobset/gnu/core-updates#tabs-jobs
I've filtered on 'pspp' in there.
amd64 and i686 fail roughly the same at test phase. Linking phase looks OK.
https://hydra.gnu.org/build/1927214/nixlog/1/raw
https://hydra.gnu.org/build/1930649/nixlog/1/raw
Looks exactly as local build failure on master for me.
To get an error text you are fixing I looked at test failures.
For example
/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/tests/testsuite.dir/0001/testsuite.log
That runs something like ../../../src/ui/terminal/pspp --testing-mode
--error-file=- --no-output epoch.sps
# -*- compilation -*-
1. calendar.at:3: testing epoch ...
./calendar.at:89: pspp --testing-mode --error-file=- --no-output epoch.sps
--- /dev/null 2017-02-25 15:55:49.60431 +
+++
/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/tests/testsuite.dir/at-groups/1/stderr
2017-03-21 22:02:35.240095562 +
@@ -0,0 +1,2 @@
+/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/src/ui/terminal/.libs/pspp:
Relink
`/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16'
with
`/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0'
for IFUNC symbol `longjmp'
+/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/src/ui/terminal/.libs/pspp:
Relink
`/gnu/store/b837wr8ffw2ppbx1744a2xll70bh8h4c-freetype-2.7.1/lib/libfreetype.so.6'
with
`/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0'
for IFUNC symbol `longjmp'
1. calendar.at:3: 1. epoch (calendar.at:3): FAILED (calendar.at:89)
It's a glibc-2.25 change that added runtime checking of IFUNC functions.
(Functions that choose their implementation at application load time)
Looks like a glibc bug.
The behaviour was introduced in
https://sourceware.org/bugzilla/show_bug.cgi?id=20019
I'll try to write minimal reproducer with setjmp/longjmp and report it upstream.
--
Sergei
pgp7CfslHspuh.pgp
Description: Цифровая подпись OpenPGP
Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.
On Tue, 21 Mar 2017 22:42:49 + Sergei Trofimovich wrote: > The behaviour was introduced in > https://sourceware.org/bugzilla/show_bug.cgi?id=20019 > > I'll try to write minimal reproducer with setjmp/longjmp and report it > upstream. Found existing one: https://sourceware.org/bugzilla/show_bug.cgi?id=21041 -- Sergei pgpbjBaDAJ97l.pgp Description: Цифровая подпись OpenPGP
