Re: Joint statement on the GNU Project

[Jelle Licht]

Taylan Kammer  writes:

> [snip]
>
> All other political conflicts should IMO be decided on a case by case 
> basis with the goal of reaching mutual compromise within the confines of 
> the communication channels of the GNU project.  That is, 1. no favorites 
> on who gets to silence who and 2. the silencing shall be limited to the 
> project's communication channels.  For example let's take homosexuality 
> and religion.  A gay community member could request another member to 
> refrain from expressing religious views critical of homosexuality within 
> the project's communication channels, as it offends her or him.  On the 
> flip side, a religious person could request another member to refrain 
> from expressing political views in support of normalizing homosexuality 
> within society, because that in turn offends them.  

The difference being that in this example, the bigotry can have
disastrous effects on the safety of the individuals in question, sadly
still in many places in the world.

This is in no shape or way comparable to simply "being offended". To
equate it to a simple difference of opinion does a great injustice to
those who struggle, and have struggled in the past for the right to
simply exist as they are.

I understand this is simply an example, and will give you the benefit of
the doubt that you only meant to illustrate different perspectives on
the interactions that can exist between individuals. I respectfully
disagree with it being a good example though :-)

- Jelle

Re: Joint statement on the GNU Project

[Christophe Poncy]

On 2019-10-11 20:41, Taylan Kammer wrote:

[…]  What position does he
hold within today's GNU project other than being a wise old person
(wise with respect to his topics of expertise) who is respected a lot?



As a simple user, I see him as the guardian of the temple ("Chief 
GNUisance"), and that reassures me because he embodies the free software 
philosophy on its own.



the maintainers and contributors collectively
hold a lot more power than any single person.


IMO, the GNU essence is more powerful than the sum of its hackers.


So in a way I guess I  don't really see what the statement
is trying to accomplish


It visibly sets the scapegoat mechanism in motion, see 
https://en.wikipedia.org/wiki/Scapegoating#Scapegoat_mechanism

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: Joint statement on the GNU Project

[Dmitry Alexandrov]

Taylan Kammer  wrote:
> On 07.10.2019 16:32, Ludovic Courtès wrote:
>>https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/
>
> Some drama about this leaked out of my mailing list-specific sub-folders 
> (which I only skim occasionally) into my main INBOX, so of course I had to 
> jump straight into it even though I'm barely around these days. ;-)
>
> Jokes aside, I wanted to ask:
>
> Hasn't RMS already officially stepped down?  What position does he hold 
> within today's GNU project other than being a wise old person (wise with 
> respect to his topics of expertise) who is respected a lot?

Relevant mails from RMS himself are below.  (Please note, that newsgroup, as it 
often happens on Gmane, is misnamed, it’s GNU’s ML, not FSF’s.)

--- Begin Message ---
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

On September 16 I resigned as president of the Free Software
Foundation, but the GNU Project and the FSF are not the same.
I am still the head of the GNU Project (the Chief GNUisance),
and I intend to continue as such.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)



-- 
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.--- End Message ---
--- Begin Message ---
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I recently resigned as president of the FSF, but the FSF continues to
provide several forms of crucial support for the GNU Project.  As head
of the GNU Project, I will be working with the FSF on how to structure
the GNU Project's relationship with the FSF in the future.

Suggestions can be sent to gnu-and-...@gnu.org.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)



-- 
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.--- End Message ---
--- Begin Message ---
As Chief GNUisance, I'd like to reassure the community
that there won't be any radical changes in the GNU Project's
goals, principles and policies.

I would like to make incremental changes in how some decisions are
made, because I won't be here forever and we need to ready others to
make GNU Project decisions when I can no longer do so.  But these
won't lead to unbounded or radical changes.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)



-- 
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.--- End Message ---


signature.asc
Description: PGP signature

Re: Joint statement on the GNU Project

[Taylan Kammer]

On 07.10.2019 16:32, Ludovic Courtès wrote:
> Hello Guix!
>
> We, a group of GNU maintainers sharing a vision for a stronger GNU
> Project, are publishing this statement today:
>
>https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/
>
> We are somewhat abusing the Guix blog here, for lack of a better
> place, but OTOH the future of GNU is obviously relevant to Guix.
> (Ricardo and I started this initiative before Tobias, Maxim, and
> Marius were on-board.)
>
> This mailing list is maybe not the best place to discuss this in
> detail but your local GNU maintainers will surely be happy to answer
> any questions you may have.  :-)
>
> Ludo’.


Hi all,

Some drama about this leaked out of my mailing list-specific sub-folders 
(which I only skim occasionally) into my main INBOX, so of course I had 
to jump straight into it even though I'm barely around these days. ;-)



Jokes aside, I wanted to ask:

Hasn't RMS already officially stepped down?  What position does he hold 
within today's GNU project other than being a wise old person (wise with 
respect to his topics of expertise) who is respected a lot?


From what I can tell, the GNU project is a collection of very loosely 
coupled sub-projects and the maintainers and contributors collectively 
hold a lot more power than any single person.  So in a way I guess I 
don't really see what the statement is trying to accomplish, although I 
agree with the sentiment of it.  What is the desired effect and end 
result of publishing the statement?


I'm not asking rhetorically, I think it would help the discussion a lot 
to clarify concrete goals instead of just signaling a sentiment.



A second question:

Assuming the talk about RMS's behavior includes his voicing of certain 
unpopular opinions, rather than just behavior that directly targets a 
person (like undesired advances), are we going to have a discussion 
about which opinions are considered "taboo" within the GNU project?


That is, opinions which shall not be expressed while working with other 
GNU contributors, or not expressed publicly at all by high ranking 
representatives such as maintainers of important (or any) packages?


(I'm not referring to any particular opinions voiced by RMS.  I'm asking 
generally.)


I wouldn't be *categorically* opposed to such limitations.  For instance 
I would welcome a rule that officially bans sympathizing with neo-Nazis. 
 However, I frequently see people go overboard with what they consider 
to be "hateful" ideas that ought to be taboo and banned from communities.


I've been banned from some places myself, and decided to quit some other 
places after receiving hostility.  I've seen some of the very people who 
support the banning others for being "hateful" against minorities defend 
or even openly celebrate threats or real acts of physical harm and 
vandalism against other political minorities.


(My hiatus from contributing to free software has, I would say, about 
10% to do with sensing such vibes from some community members who see 
themselves as socially progressive, though it's 90% about things related 
to me and not the community.  Still, if I find time to come back, I'd 
like to know how much self-censorship I have to apply and how much I 
have to tolerate opinions which I in turn find offensive.)



Personal suggestions re. second question follow; feel free to stop 
reading here if you don't want to get into more and more off-topic 
territory.



My personal suggestion would be to keep a very small list of explicit 
limitations, probably just the support or apologia of neo-Nazism and 
child sexual exploitation.  Voicing such opinions on any channel of the 
GNU project would be a reason to terminate someone's access to the 
channel.  Voicing them on any public channel would disqualify someone 
from maintainer and similar positions, and perhaps allow other members 
to raise a complaint against their involvement as a contributor too.


I think it's important to have such an explicitly and clearly laid out 
set of rules on what world-views get to be silenced, as otherwise you 
get repeated arguments about free speech.


All other political conflicts should IMO be decided on a case by case 
basis with the goal of reaching mutual compromise within the confines of 
the communication channels of the GNU project.  That is, 1. no favorites 
on who gets to silence who and 2. the silencing shall be limited to the 
project's communication channels.  For example let's take homosexuality 
and religion.  A gay community member could request another member to 
refrain from expressing religious views critical of homosexuality within 
the project's communication channels, as it offends her or him.  On the 
flip side, a religious person could request another member to refrain 
from expressing political views in support of normalizing homosexuality 
within society, because that in turn offends them.  Outside channels of 
communication of the project, both 

RE: [Hangout - NYLXS] ---> "RMS" : ?? if you are going to use acronyms unknown to many in the audience, footnote them ! + "FUD"

[Mancini, Sabin (DFS)]

--->  "RMS" :  ??   if you are going to use acronyms unknown to many in the 
audience, footnote them !   +  "FUD"
__


Sent: Thursday, October 10, 2019 5:03 PM
To: Dmitry Alexandrov <321...@gmail.com>
Cc: guix-devel@gnu.org; gnu-system-disc...@gnu.org; help-g...@gnu.org
Subject: Re: [Hangout - NYLXS] Proposal to remove the off-topic, not free 
software related thoughtcrime accusations from the Guix project pages on 
GNU.ORG websitew

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.

On October 10, 2019 8:29:06 PM UTC, Dmitry Alexandrov <321...@gmail.com> wrote:
>Jean Louis  wrote:
>> How are you?
>
>Ehm...  Fine.  What is the occasion to ask?

We are then from different cultures simply. At my side it is always used 
similarly as hand shaking.

>> I [] see absolutely no problem there.
>
>I’m afraid, Dr. Stallman would see.

My protest is not to align all my thoughts with Dr. Stallman, my protest is 
that defamation and harassment of RMS is taking place on Guix.GNU.org website.

>> What is point in backstabbing of RMS? I asked and never got answers but FUD.
>
>To get rid of him, of course.  Why to ask for obvious answer?

Well I don't see it that way. I see it as a hostile fact-less thought police 
punishing and degrading GNU, Guix, FSF and RMS for the thought crime. See the 
book 1984

Reason that they don't have guts is all the comfort they got from FSF and GNU 
which is, was and is being caused by RMS.

Comfort like this 
https://guix.gnu.org/blog/2018/gnu-guix-receives-donation-from-the-handshake-project/
 is hard to resist to get their things straight.

>> They have no respect for RMS.
>


___
Hangout mailing list
hang...@nylxs.com

[completion] Completion scripts not loaded from ~/.guix-profile/etc/profile

[YOANN P]

Hi guix,

Not sure if it needs to be add to the guix documentation or directly included 
in "~/.guix-profile/etc/profile" generation process, 
but the completion scripts provided by packages seem not to be loaded.
For example, if i only install the package "git", the completion scripts for 
"git" reside in "~/.guix-profile/etc/bash_completion.d/git".
But there is no loading instructions for those files in 
"~/.guix-profile/etc/profile".
So after sourcing "~/.guix-profile/etc/profile", a user need to loop over files 
in "~/.guix-profile/etc/bash_completion.d/" 
and "~/.guix-profile/share/bash-completion" to source them manually because 
native bash/bash-completion from the user distribution 
are not aware of the new completion scripts available in 
"~/.guix-profile/etc/bash_completion.d/" and  
"~/.guix-profile/share/bash-completion".

I think a "bash loop" need to be added for this purpose in the generation of 
"~/.guix-profile/etc/profile" and in the meantime add a section for this
inside "2.6 Application Setup" section be cause i didn't find any instructions 
about this on the documentation.

Regards,
Yoann

Re: Proposal to remove the off-topic, not free software related thoughtcrime accusations from the Guix project pages on GNU.ORG websitew

[Ruben Safir]

too bad.  Do you need more email space?  I can lend you some



On Thu, Oct 10, 2019 at 04:44:03PM +, ng0 wrote:
> Oi.
> Shut up and get another audience for your monologue theater act.
> I am no longer involved in guix that much, but your trash keeps
> piling up in my inbox.

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013

Re: Overhauling the cargo-build-system

[Efraim Flashner]

On Fri, Oct 11, 2019 at 12:33:18AM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Efraim Flashner  skribis:
> 
> > I'd like to challenge the assumption that packages are both libraries
> > and source. A 'library' in rust compiles into one of three types: a
> > static library (libfoo.a), a shared library (libfoo.so), or a
> > 'rust-library' (libfoo.rlib).
> 
> Why don’t we create .so files, then?  They have NEEDED and RUNPATH, so
> that could work like for C, no?
> 

It is possible to force a library to produce .so files, but then we'd
have to force all the other packages to link against them, and then at
that point we're basically rewriting 'cargo build'. For some packages,
like icecat, that does seem to be what they do.

> > Let me repeat that. We have 192 rust packages that no one needs or
> > wants, except in source form.
> 
> Ouch!  So the rlib file is never actually used?!
> 

As I understand it, it gets treated as a build artifact. It'll be
compiled as libfoo_X.rlib and then, if some other program comes
around as asks for "foo with feature baz" it'll be reused. At some point
it gets compiled directly into the final binary, so it's really more of
an intermediary stage.

> You said “it is not possible to link an rlib to another rlib”, but
> that’s not necessarily a problem, it’s like .a libraries, no?
> 

if libfoo depends on libbar, then pre-building libbar_X.rlib doesn't
allow us to call "rustc --crate-name foo src/lib.rs --crate-type lib
--extern (string-append bar=(assoc-ref %build-inputs bar)
/lib/libbar.rlib)" (note the --crate-type lib in there), it'll just not
work and want to recompile libbar for just the few functions it uses
from it. The only difference I've seen is if our foo is also a "binary
crate", ie produces a binary, then it'll sometimes accept rlibs for its
own rlib lib output.

Going back to forcing it to produce .so files, if we changed the
crate-type to dylib then we'd get libfoo.so. The two parts of the
problem is now we need to change all the other libraries and programs
that depend on foo to take our libfoo.so and not expect an rlib, and
that if foo has 3 options then we have to decide how to build libfoo so
it's useful for everything (obviously all 3) but without dragging in
everything (easiest with none of the 3), or to have some combination,
which becomes a nightmare very quickly.

That sentence was way too long.

> > PROPOSAL:
> > Change all the rust packages we have now to be source-only. Rename them
> > from rust-foo to rust-foo-src or rust-src-foo.
> 
> In the current scheme, can you actually do, say:
> 
>   guix environment --ad-hoc rust rust-foo rust-bar
> 
> and then (pseudo syntax):
> 
>   rustc mystuff.rust -lfoo -lbar
> 
> ?

Ignoring that we don't actually install the libraries here's a copy of
a check phase I wrote trying to use installed libraries. I think in the
end it did consume the rlibs as requested, but it never did link to
them, it just absorbed them into the final binary.

(replace 'check
  (lambda* (#:key inputs #:allow-other-keys)
(let ((ndarray(assoc-ref inputs "ndarray"))
  (rand   (assoc-ref inputs "rand"))
  (rayon  (assoc-ref inputs "rayon"))
  (serde  (assoc-ref inputs "serde"))
  (serde-json (assoc-ref inputs "serde-json"))
  (structopt  (assoc-ref inputs "structopt")))
  (invoke "rustc" "--edition=2018" "--crate-name" "qtlreaper"
  "src/lib.rs"
  "-C" "opt-level=3"
  "--test" "-C" "metadata=test" "-C" "extra-filename=-test"
  "--out-dir" "target/release/deps"
  "--extern" (string-append "ndarray=" ndarray 
"/lib/libndarray.rlib")
  "--extern" (string-append "rand=" rand "/lib/librand.rlib")
  "--extern" (string-append "rayon=" rayon "/lib/librayon.rlib")
  "--extern" (string-append "serde=" serde "/lib/libserde.rlib")
  "--extern" (string-append "serde_json=" serde-json 
"/lib/libserde_json.rlib")
  "--extern" (string-append "structopt=" structopt 
"/lib/structopt.rlib")
  "--cap-lints" "allow" "-C" "rpath" "-C" "prefer-dynamic")
  (invoke "rustc" "--edition=2018" "--crate-name" "qtlreaper"
  "src/main.rs"
  "-C" "opt-level=3"
  "--test" "-C" "metadata=test" "-C" "extra-filename=-test"
  "--out-dir" "target/release/deps"
  "--extern" "qtlreaper=target/release/deps/libqtlreaper-test.rlib"
  "--extern" (string-append "ndarray=" ndarray 
"/lib/libndarray.rlib")
  "--extern" (string-append "rand=" rand "/lib/librand.rlib")
  "--extern" (string-append "rayon=" rayon "/lib/librayon.rlib")
  "--extern" (string-append "serde=" serde "/lib/libserde.rlib")
  "--extern" (string-append "serde_json=" serde-json 
"/lib/libserde_json.rlib")
  "--extern" (string-append "structopt=" structopt 
"/lib/structopt.rlib")
  

Fabe build system

[pinoaffe]

Hi guix!

Lately I've been trying to package some FOSS FPGA toolkit stuff for 
guix,
and as a dependency of a dependency I ran into python-boost 
https://github.com/boostorg/python/,

which uses the "faber" build system.

Since this build system is not supported by guix (or any other distro as 
far as I can tell),

I went on to try to and add support for faber to guix.
My work in progress can be found at 
https://gitlab.com/pinoaffe/guix_fork/tree/fpga,
along with the sole package I've been able to find that makes use of the 
build system

and with nextpnr, which depends on python-boost.

So far I've been unable to get boost-python to work in order to build 
nextpnr,
so it'd be great if some more experienced guix geeks would take a look 
at my code

and at what is going wrong.

Thanks in advance,
pinoaffe

Re: Testing small changes to upstream Guix repo

[David Wilson]

Hi Danny,

Thanks so much for these steps, they worked perfectly for me.  The manual has 
the necessary commands laid out a bit too sparsely; having them concisely 
presented like this got me over the hurdle.

David

On Tue, Oct 8, 2019, at 3:33 PM, Danny Milosavljevic wrote:
> Hi,
> 
> > 2. Clone the Guix repo myself, change the file, and somehow replace the 
> > upstream channel with my local repo path
> 
> $ git clone -b master --depth 1 
> https://git.savannah.gnu.org/git/guix.git guix-foobar
> $ cd guix-foobar
> $ guix environment --pure guix --ad-hoc git guile-readline guile-json 
> nano
> (env)$ ./bootstrap
> (env)$ ./configure --localstatedir=/var
> (env)$ make -j5
> # Make sure it succeeds.
> # Lately it was broken for unrelated reasons (po files)--you don't want 
> to
> # confuse those errors with errors your change could have caused.
> (env)$ nano gnu/packages/baz.scm
> # Edit your package or whatever it is
> (env)$ make -j5
> (env)$ exit
> $ ./pre-inst-env guix build -K blah
> # On build failure, examine /tmp/guix-build-blah* directory
> # If you want, install the new package into your profile:
> $ ./pre-inst-env guix package -i blah
>

Re: i686-linux GCC package on x86_64

[Mathieu Othacehe]

> Now the only issue is that the libc is placed in a
> "/gnu/store/...-gcc-cross-i686-unknown-linux-gnu-5.5.0/i686-unknown-linux-gnu"
> subfolder.
> I wonder why.  How are dependencies supposed to find the libs in there?
>
> Is it possible to move the libs to the usual "lib" folder at the root?

The gcc and glibc includes and libraries and add to CPATH and
LIBRARY_PATH env variables respectively. That's how they are found
during build.

Mathieu

Re: Joint statement on the GNU Project

[František Kučera]

Dne 11. 10. 19 v 9:45 Ludovic Courtès napsal(a):
> Nice.  This list is about Guix development though.  My email was
> directed at the Guix developers and it’s not helpful when “outsiders”
> chime in.

Your activities are (negatively) affecting whole FSF/GNU and free
software movement in general. So the comments from „outsiders“ are relevant.

Franta

Re: i686-linux GCC package on x86_64

[Mathieu Othacehe]

> This works but cross-gcc only delivers GCC and the libc.
> The "lib" output of the regular GCC is missing.
>
> In particular, I'd need libstdc++.so.

Then, that should be fine:

--8<---cut here---start->8---
(native-inputs
 `(,@(if (not (string-prefix? "i686" (%current-system)))
   `(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"
  #:libc (cross-libc 
"i686-unknown-linux-gnu")))
 ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
   '(
--8<---cut here---end--->8---

By default the #:libc field of cross-gcc is #f which seems to be the
issue for you.

Mathieu

Re: Joint statement on the GNU Project

[Ludovic Courtès]

Hi Quiliro,

Quiliro Ordóñez  skribis:

> * Ricardo Wurmus  [2019-10-10 07:09]:
>> I have previously asked you privately to stop spamming our mailing
>> lists.  I am asking you a second time publicly.  If you keep disrupting
>> our mailing lists your posts will be moderated.
>
> Censorship [...]

There is no censorship.

By joining Guix, one agrees to follow the rules at
.
These are simple rules to keep this space welcoming.  We all benefit
from their application.

Again, expressing disagreement is fine; harassing people like Jean Louis
has been doing (first on IRC, then on this mailing list and via their
web site) is not.

My initial message in this thread was directed at Guix developers.
Evidently we’ve now got quite a lot of feedback from people not involved
in Guix.  Yet, this remains a mailing list intended for Guix development.

So, to everyone who wants to discuss GNU matters further, please let’s
use gnu-misc-disc...@gnu.org.

Thanks!

Ludo’.

[FOSDEM] FOSDEM 2020 Minimalistic, Experimental and Emerging Languages Devroom CfP

[Manolis Ragkousis]

We are excited to announce a devroom on minimalistic, experimental
and/or emerging languages (with big ideas) at FOSDEM on Sunday
February 2nd 2020!

FOSDEM is one of the most important free software conferences and is
hosted annually at Université libre de Bruxelles in Brussels,
Belgium. FOSDEM is fantastic, check last year's schedule for Saturday
(https://archive.fosdem.org/2019/schedule/day/saturday/)

We accept talks from languages that have interesting ideas or
prospects, but are not considered main stream (yet). If you are
working on an experimental or emerging language feel free to
submit a talk proposal.

Minimalism is an important topic for this devroom. Minimalism
matters. Minimalism allows for smaller systems that take less
resources and consume less energy. More importantly, free and open
source minimalism allows for secure systems that are easy to
understand. Finally, we believe that minimalism is educational and
brings back the fun of the early days of computing where people learn
to understand systems from the ground up. Speakers will be asked to
accentuate the educational side of their projects.

We have a room Sunday 2 February 2020. We want to invite you to submit
a talk on the use of minimalistic, experimental and/or emerging
languages that fits that description. We are especially happy to
receive talk submissions from members of any underrepresented groups.

If you have something you’d like to share with your fellow developers,
please E-mail us! Talks considered for the devroom will have to
be entered in

  - https://penta.fosdem.org/submission/FOSDEM20

The deadline for submission is November 26th. If you have a FOSDEM
pentabarf account from a previous year, please use that
account. Otherwise add one on
https://penta.fosdem.org/user/new_account. Reach out to
pjotr.public...@thebird.nl if you run into any trouble.

When submitting your talk make doubly sure to select "Minimalistic
devroom" as track (if you don't we won't find it), and include the
following information:

  * The title and subtitle of your talk
  * A short abstract of one paragraph
  * A longer description if you wish to do so
  * Links to related websites/blogs etc

To see what a final talk looks like see

  https://archive.fosdem.org/2019/schedule/event/gnumes/

Let's make this a fun day!

= Organisers =

Manolis Ragkousis, Peter Munch-Ellingsen, Steph Hobbs, Ludovic
Courtès, Jan Nieuwenhuizen & Pjotr Prins (pjotr.public...@thebird.nl)

= Code of conduct =

  - https://fosdem.org/2020/practical/conduct/

= Original proposal =

  - https://libreplanet.org/wiki/FOSDEM2020-devroom-proposal

= Important dates: =

  - Nov 26th 2019:  submission deadline for talk proposals
  - Dec 15th 2019:  announcement of the final schedule
  - Feb  2nd 2020:  FOSDEM!

Re: 'core-updates' Q4 2019

[Ludovic Courtès]

Hi,

Svante Signell  skribis:

> On Thu, 2019-10-10 at 16:32 +0200, Ludovic Courtès wrote:
>> Hi!
>> 
>> Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to
>> ‘core-updates’ if nobody’s done it yet.
>> 
>> Let’s get the ball rolling!
>
> What's the status of the GNU/Hurd port with this core-updates release,
> better or worse?

It’s most likely unchanged.

Thanks,
Ludo’.

Re: Questions about packaging

[Tanguy Le Carrour]

Hi Danny !

Thanks for your answer.


Le 10/10, Danny Milosavljevic a écrit :
> > 1) Updating a package
> > So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
> > Should I create a python-cachecontrol-0.11.6 and fix all the packages
> > that depend on it? Only the one that would break?
> 
> The latter.  That's one of the things we do at Guix but I would not do at 
> work.

OK. I'll do that!
My next question would be "when would someone create a versionned package name?"
Like for instance `openjdk`?


> > Btw, python-cachecontrol seems to be broken. I'll work on that. But
> > before I'll have to find an answer to question 3.
> 
> Then the answer is to update it, and to update everything else that
> depends on it (since it didn't work anyway, what's the harm?  The situation
> can only improve).

"The situation can only improve". Can you believe I didn't think of
that! ^_^'
This makes total sense! Thanks.


> On Wed, 9 Oct 2019 11:56:33 +0200
> Tanguy Le Carrour  wrote:
> 
> > As I understand it, to make sure that a package works with the
> > dependencies provided by the distrubution (Guix), tests must pass!
> 
> Well, it's better if the tests pass, yes.  If the tests fail that's definitely
> bad.  If you absolutely can't get the tests to execute in the first place, 
> let's
> talk about it (with upstream if necessary).

OK. I'll push the discussion upstream.


> > So I guess that one should always make sure that the tests can be
> > executed from the Pypi download, or use Git to get the sources.
> 
> I'd use git (and a tag).  There's no downside that I can see.

Neither can I! I'll do that.


Thanks again for your time and advice !

-- 
Tanguy