Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2016-01-15

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:18 Big_G joined #darcs
02:34 mizu_no_oto joined #darcs
02:47 ilbot3 joined #darcs
02:47 Topic for #darcs is now Sprint in Seville, Spain 15-17th January | http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.10.0 is out http://darcs.net/Releases/2.10
08:50 gal_bolle joined #darcs
09:01 gal_bolle sprint is open!
09:02 gh_ joined #darcs
09:03 gh_ hi \o/
10:40 gh_ we discussed the items of this weekend. today and tomorrow we're having video calls with pierre-etienne of pijul
11:44 nomeata joined #darcs
11:45 nomeata Hi. I’m surprised to see that darcs is not part of stackage, so LTS now bumped (among other things) vector to a version not compatible with darcs.
11:45 nomeata Are there plans to add darcs to stackage?
11:47 Heffalump the last time I looked, some of its dependencies weren't there
11:48 nomeata Heffalump: that’s not a show-stopper; they will be pulled in together with darcs.
11:48 nomeata (instructions on http://www.stackage.org/authors)
11:50 nomeata Filed http://bugs.darcs.net/msg18913 so that it is not forgotten.
11:50 nomeata Independent of that: Do you plan a point release that’s compatible with vector-0.11 soon, or should I see check if I can patch it in Debian?
11:54 Heffalump (talking in person at the sprint - will reply in more detail in abit)
11:55 nomeata ah, there is a sprint right now?.. ok, it’s in the title. Perfect time to add darcs to stackage, and make a point release with updated build dependencies :-)
11:58 nomeata If you do not know the page: http://packdeps.haskellers.com/feed?needle=darcs is a good place to check what of your dependencies have newer versoins on hackage (ATM: binary, HTTP, HUnit, process, tar, time, transformers and vector)
13:52 Heffalump nomeata: I thought the package maintainer had to agree to the maintainer's agreement? So if there are dependencies not in stackage, it requires some agreement from a third party to pull them in.
13:52 Heffalump nomeata: yes, I know about and monitor packdeps. The real issue here is the frequency of our updates, I think; we don't have a really lightweight point-release process and we don't even necessarily update our own repository quickly.
13:53 Heffalump which is independent of stackage, likely to always be an issue for distro maintainers. I'm not entirely sure what the answer is.
13:53 nomeata Heffalump: well, it is somewhat a best effort approach. By pulling in your build-dependencies, you are in a way responsible for them, e.g. by contacting them if there are problems. And if that does not help, the stackage guys are not too shy to just drop something again.
13:54 nomeata agda is a similar project that pulled in a few extra packages, I believe.
13:58 Heffalump specifically for the current outstanding deps, happy to fix those in the repo during the sprint, gh_ is in charge of releases
13:59 * nomeata currently tries to build it against vector-0.11
14:00 Heffalump I think that's already fixed in the repo: http://darcs.net/releases/branch-2.10
14:19 nomeata I really wish there was a tool or central service that would automatically indicate upper bounds that can be relaxed without breaking the build or the test suite
15:03 sm go sprinters!
15:24 sm nomeata: +1
15:25 sm are you working on this ? I just updated my stack patch from last year, and didn't notice any problem with vector 0.11: http://hub.darcs.net/simon/darcs-screened/compare/darcs/darcs-screened
15:26 nomeata sm: it built, yes
15:26 nomeata so for now I am fine with carrying that patch in the Debian repo.
15:27 sm oh, are you involved in the darcs there ?
15:27 sm darcs packaging
15:30 sm Heffalump, gh_: ^ pull request
15:41 Heffalump sm: pull request for what?
15:42 sm http://hub.darcs.net/simon/darcs-screened/compare/darcs/dar\|102520238
15:42 sm ackkk.. computers
15:42 Heffalump :-)
15:42 Heffalump AFAIK screened already supports vector 0.11
15:42 sm stack config, I linked to the changes above
15:43 gal_bolle joined #darcs
15:43 Heffalump ah, right
15:44 Heffalump should we just give you push access to darcs to maintain stack.yaml ?
15:44 sm ok, that works
15:46 sm my darcs.net login is defunct, shall I PM my public key ?
15:48 Heffalump there's a simon@joyful.com public key already setup, do you have that?
15:49 gh_ joined #darcs
15:50 sm yes.. it's rsa and ssh -v says it's trying only id_dsa. Hmm.
15:52 sm and it rejects that even I force it with -i
15:53 sm this pub key ends with PCs7, is that the one you have ?
15:56 Heffalump yes, it does. But you push to the darcs repo by sshing to darcs-unstable@darcs.net, not to your own user account
15:57 Heffalump so maybe you're sshing to the wrong thing
15:57 sm ah! that was it
15:57 Heffalump your simonmichael account has a simon@white.local public key
15:57 sm ah! and simonmichael is the username for that one. Thanks
15:58 Heffalump where are you going to push, just to screened?
15:58 sm that was my next question.. that sounds right
15:58 sm let's see..
15:58 Heffalump hmm, that's a slight complication, because we won't know when it's safe to merge them to reviewed
15:58 sm oh
15:58 gh_ hi again (got disconnected for an hour sorry)
15:58 sm any chance we can abolish the screened/reviewed split this year ? :)
15:59 Heffalump You mean "can we stop doing code review"? :-)
15:59 sm review can still happen (a) in contributor branches on darcs hub before merging and (b) on master before being picked to a release branch, no ?
16:00 Heffalump think of reviewed as a release branch if you like
16:01 sm ok.. I find it a tad complicated but you guys are doing the work. I'm happy to follow whatever process, just tell me where to push :)
16:01 sm or pull the stuff, if it's easier
16:02 Heffalump I guess it's up to you where you push, actually: it depends on what you want to keep working. The only "rule" is don't push a patch to reviewed without also pushing it to screened. Any complaints about stack.yaml not working in any repository will be sent your way :-)
16:03 sm that's not clear enough.. the darcs project should specify this process
16:06 gh_ sm, there is a "getting started" guide on the wiki but maybe we can make it clearer http://darcs.net/Development/GettingStarted
16:07 gh_ this page is.. too long
16:07 Heffalump the thing that's special about stack.yaml is that none of the other darcs maintainers want to take responsibility for maintaining it - normally when someone submits a patch, people do it in screened and we as maintainers handle everything else
16:07 gh_ considering there's also a separated patch review page http://darcs.net/Development/PatchReview
16:08 sm I think that page is telling me the process is:  darcs send --mail http://darcs.net/screened
16:08 sm but Heffalump has asked me to push
16:08 Heffalump I'm not really sure what to do, it was just an idea really.
16:09 Heffalump the thing is, I don't know how to review a stack.yaml patch.
16:09 Heffalump (or at least, I don't want to know how to review it)
16:10 Heffalump I guess the simplest would be for you to just push to screened and reviewed simultaneously.
16:11 gh_ [ that was 7 years ago: http://lists.osuosl.org/pipermail/darcs-users/2009-January/017233.html ]
16:14 sm how to review patches one is not interested in is independent of the contribution process, perhaps
16:14 sm or should be
16:15 sm re stack patches, I think they are pretty shallow in terms of impact, and don't affect anyone not using stack, so review is always valuable but not required
16:15 sm for stack users and distro packagers, I think any stack patches are better than none
16:15 Heffalump right, so the way to bypass review is to push straight to reviewed (and also to screened)
16:15 Heffalump do distro packagers care about stack.yaml?
16:16 Heffalump I thought they just care about it supporting the full set of versions
16:16 sm yes, they are beginning to use stackage snapshots as the basis for their work
16:16 Heffalump that doesn't mean they need stack.yaml, it means they care about the project building with the set of versions in stackage
16:16 sm stack.yaml is how you get into stackage, and take advantage of stackage's snapshot compatibility testing
16:17 Heffalump are you sure about that? That's not how I understood the process.
16:18 Heffalump #darcs: any opinions on http://bugs.darcs.net/patch1417
16:18 sm Heffalump: I don't understand your view of stackage
16:19 Heffalump sm: I understood stack.yaml to be about explaining how a package can be built against stackage in a slightly non-standard way.
16:19 sm that's what extra-deps is
16:19 sm (in stack.yaml)
16:19 Heffalump If a package supports the latest snapshot - i.e. all the stackage versions - why would it be needed?
16:19 sm stack.yaml is the requirement for being in stackage at all
16:19 Heffalump HTTP is in hackage and doesn't have a stack.yaml
16:20 sm and for being installable with the stack tool
16:20 sm hmm
16:21 sm true
16:24 sm so currently, darcs requires a stack.yaml to declare one dependency that's not on stackage: regex-compat-tdfa
16:26 sm to enter stackage, and be installable with stack, darcs can drop that dependency, or regex-compat-tdfa can be added to stackage, or darcs can have a stack.yaml file
16:27 Heffalump I don't think stack.yaml would help us enter stackage without regex-compat-tdfa being on stackage
16:27 Heffalump AFAIK the dependencies "in" stackage need to be closed
16:27 sm true, also true
16:31 sm so we should simmply request darcs and regex-compat-tdfa be added to stackage. A stack.yaml isn't important right now
16:32 Heffalump which comes back to the point I mentioned above to nomeata - that requires us to commit to bumping our deps on hackage quickly
16:32 sm but, I've tested only with darcs-screened, and it's the hackage release that needs to build. Which is what nomeata is talking about
16:33 Heffalump and once we commit to doing that, stackage only helps by keeping us honest, it doesn't actually add anything otherwise
16:34 nomeata sm: you do not need stack.yaml to get into stackage, and I do not care about stack.yaml
16:34 sm nomeata: yes, I've just come to that realization
16:34 sm Heffalump: are you saying being in stackage is bad for darcs ?
16:35 Heffalump not really, I'm saying that it's not as simple as "we should simply request darcs and regex-compat-tdfa to be added to stackage"
16:35 sm what do you think we should do ?
16:36 Heffalump well, personally I care about distro maintainers like nomeata, and not about hackage
16:36 Heffalump I mean not about stackage
16:36 sm nomeata said "It would greatly simplify the work of the Debian package maintainers if
16:36 sm darcs would join stackage."
16:37 Heffalump right, but (I think) that's because darcs joining stackage means that darcs has to promptly deal with dependency bumps.
16:37 Heffalump and that's the bit I'm not sure we can actually commit to
16:39 sm if the darcs project is unable to handle that, what's the worst that can happen ? It gets dropped from stackage
16:39 sm I think
16:40 sm which is bad enough, but not a reason to not try and be in stackage surely
16:41 Heffalump I'm not sure I see the point of joining if we don't think we would be able to meet the requirements
16:41 sm this shouldn't be this hard. I will be darcs stackage czar for 2016
16:41 sm how does that sound
16:42 nomeata Note that some problems can be solved by editing the cabal meta-data on hackage, without doing a full release
16:42 nomeata The vector bump is one such example.
16:43 nomeata And I would know that I can do the same patch to the Debian package with good conscience
16:43 sm I would rely on gh_ for hackage release updates like that
16:43 Heffalump sm: sure
16:43 sm sound good gh_ ?
16:44 Heffalump having someone picking up upper bounds changes promptly would be great
16:44 gh_ sm, I'm okay with this
16:44 Heffalump nomeata: hmm, true. We've never done that with darcs before, but it kind of makes sense.
16:44 sm gh_: of course if you'd rather handle it yourself, with support from me, I'd much prefer that
16:45 Heffalump not creating a "new" point release for the upper-bound makes sense because we're not really changing the darcs code itself
16:46 gh_ sm, I can do it, at least for a while. if I get bored of it I can ask you for support.
16:46 gh_ it=release new versions on hackage
16:47 sm gh_: I was talking about managing our stackage presence
16:48 gh_ sm, oh great! I'm glad you can help with this
16:48 sm ok then
16:54 gh_ I'm going to release 2.10.3 soon with a few dependency bumps
16:54 sm let's chat about that
16:55 gh_ and a few changes that apply cleanly to the branch
16:55 gh_ yes sm
16:55 gh_ and whatever we consider useful during this weekend
16:55 sm I think darcs 2.10.2 needs three changes to build in stackage lts-4.1 - well, the regex-compat-tdfa extra-dep, and two changes that impact you. First I guess you'll allow vector-0.11 ?
16:57 sm second, can you make use-time-1point5 default: True ?
16:57 sm brb
17:01 gh_ sm, vector-0.11 is already in the 2.10 branch.
17:05 gh_ sm, about regex-compat-tdfa, what change is necessary?
17:06 sm gh_: which means vector-0.11 support will be landing on hackage soon, right
17:07 sm for regex-compat-tdfa you don't need to change anything, I just need to get it added to stackage. (Or, we could stop depending on it, I don't know how big that is)
17:08 gh_ the regex-compat-tdfa was introduced a couple of years ago to fix some bug
17:11 gh_ related to unicode
17:11 sm gh_: what about use-time-1point5 default: True
17:12 sm do you want me to push that to darcs-screened ?
17:13 gh_ sm, if ghc 7.4 can compile time 1.5, we can do this change to branch 2.10 and screened
17:13 gh_ in screened we support ghc from version 7.6
17:14 sm it's a flag which Cabal can toggle automatically, so changing the default shouldn't affect buildability with old ghc versions
17:14 gh_ ah, you're talking about changing the default
17:14 gh_ yes? ok nice. I wasn't sure of that.
17:14 sm stack can't toggle it automatically, so it needs to support ghc 7.10 by default (I believe). Plus it's just the right default now
17:14 sm yeah
17:15 gh_ sm, let me change it right now
17:15 sm great
17:15 gh_ hmm how does cabal know that a certain version of GHC need to toggle this flag to False?
17:15 gh_ in fact I don't even know how it toggled it to True when needed
17:16 sm yeah, cabal's solver will flip flags as needed unless you add Manual: true to them
17:17 gh_ TIL
17:17 gh_ :)
17:18 sm it'll flip it if it makes the dependencies work out. I think most flags should have manual: true to prevent this source of complexity, but dep compatibility flags like this one are ok
17:25 Heffalump is that a bug in stack? (that it can't toggle it automatically)
17:26 Heffalump it seems a bit of a weird thing to have to constrain ourselves on, though perhaps it doesn't matter in practice
17:26 Heffalump In general I'd expect we might need to choose a default to accomodate an old cabal with a broken solver
17:27 gh_ did that solver always exist in cabal? when was it introduced?
17:28 Heffalump it's existed for a long time, but it's also been through many iterations
17:28 sm Heffalump: stack is all about repeatable fully specified builds, it's not into toggling things
17:29 Heffalump but the cabal solver would do it automatically if given the version dependencies
17:29 Heffalump and if stack is trying to fix specific flag settings for itself, doesn't it need to store them somewhere?
17:30 gh_ ok, about this particular flag, how common is ghc < 7.10 among people who build darcs? i do have 7.10 since I upgraded to ubuntu 16.04 (current unstable)
17:31 sm Heffalump: yes, if a project requires non-default flag settings you have to specify them in stack.yaml
17:31 Heffalump gh_: Debian will be the most common case
17:46 gh_ ok, it does indeed seem weird to constrain ourselves to please stack, but old cabal's are supposed to cope, and the tradeoff in terms of which users we please seems worth it. If a similar situation occurs again we will weight the pros and cons.
17:47 Heffalump or we can have a stack.yaml, I guess
17:47 gh_ yeah
17:47 Heffalump but it does seem pretty arbitrary - we're in stackage to help distros, and cabal works fine with either default, so I doubt distros would care
17:48 sm what's the constraint ? do you think changing the default impacts anything ?
17:50 gh_ sm, people with broken cabal on debian would be impacted I guess IIUC
17:50 gh_ in general we simply want to err on the safe side
17:50 sm ok would you prefer I add a stack.yaml
17:54 gh_ sm, yes. if it contains only this kind of data (which does not seem to require that much update) I think it's ok. personally I'm a little afraid of bitrot but if you can maintain it it's fine
17:56 sm feels like the bitrot danger's in darcs.cabal :)
17:57 sm but I understand, I'm just researching the details a little more with the stack folks
17:57 Heffalump we (as maintainers) look after darcs.cabal
17:58 gh_ well it's big and we have to support many ghc versions, but all people present at the sprint do use darcs.cabal so we do discover things to update there
18:39 gh_ how about PatchSemantics1 and PatchSemantics2 as new names for Patch and RealPatch?
18:43 gh_ ConflictSemantics{1,2}
18:43 gh_ may not be worth it..
18:58 Heffalump I wonder what camp calls these layers
18:58 Heffalump there are three layers, but I don't have good names for them. On top there's the "named" patch layer with Named, PatchInfoAnd etc - these are the things in repos
18:59 Heffalump At the bottom is the "Prim" patch layer that expresses hunks, token replaces, filesystem operations. That layer doesn't have a total merge operation.
18:59 Heffalump And in the middle is the conflict-adding layer, that adds a total merge operation.
19:25 gal_bolle [nix-shell:~/projets_perso/darcs/with_pijul_export]$ dist/build/darcs/darcs convert pijul .
19:25 gal_bolle WARNING: the repository produced by this command is not understood by
19:25 gal_bolle Darcs itself, and patches cannot be exchanged between repositories in
19:25 gal_bolle darcs and pijul formats.
19:26 gal_bolle Please confirm that you have read and understood the above
19:26 gal_bolle by typing `I understand the consequences of my action': No, I'm a fool
19:26 gal_bolle User didn't understand the consequences, proceeding anyway
19:26 gal_bolle Directory '/home/florent/projets_perso/darcs/with_pijul_export/with_pijul_export' already exists, creating repository as '/home/florent/projets_perso/darcs/with_pijul_export/with_pijul_export_1'
19:26 gal_bolle (not) Creating a pijul repository at /home/florent/projets_perso/darcs/with_pijul_export/with_pijul_export_1
19:26 gal_bolle pijul is from the future, did you expect to be able to convert now?
20:09 JamesJRH joined #darcs
21:10 Riastradh joined #darcs
22:34 nomeata joined #darcs
23:10 gal_bolle joined #darcs
23:20 gal_bolle joined #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary