From magnus at therning.org Wed Nov 5 08:35:02 2014 From: magnus at therning.org (Magnus Therning) Date: Wed, 5 Nov 2014 09:35:02 +0100 Subject: [arch-haskell] Recent change to Hackage causes delay in updates In-Reply-To: <20141029151350.GA5271@mtcomp.evidente.local> References: <20141027190701.GD12570@tatooine.lan> <5450BDDF.3080807@orbitalfox.com> <20141029151350.GA5271@mtcomp.evidente.local> Message-ID: <20141105083502.GB3950@mtcomp.evidente.local> On Wed, Oct 29, 2014 at 04:13:50PM +0100, Magnus Therning wrote: > On Wed, Oct 29, 2014 at 10:13:51AM +0000, SP wrote: > > What exactly is the unclear problem? Signalling the process of patching, > > or how the patching process works? > > I'm not sure it's unclear. The problem is that the 00-index and the > package now may contain different .cabal files for the same version of > the package. This is a feature that apparently has been in the works > for a while, but I wasn't aware of it until it bit me during an update > yesterday (pandoc 1.13.1 is in this state on Hackage). > > Cblrepo is written with the assumption that the 00-index and the > source tar-ball on Hackage *always* contain the same .cabal. So it > clearly needs some work before it's back to being usable again. Silly me! There's a rather obvious work-around that will allow me updating while working on a more convenient way to deal with this. Another update is building as I write this now :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From sp at orbitalfox.com Wed Nov 5 09:13:29 2014 From: sp at orbitalfox.com (SP) Date: Wed, 05 Nov 2014 09:13:29 +0000 Subject: [arch-haskell] Recent change to Hackage causes delay in updates In-Reply-To: <20141105083502.GB3950@mtcomp.evidente.local> References: <20141027190701.GD12570@tatooine.lan> <5450BDDF.3080807@orbitalfox.com> <20141029151350.GA5271@mtcomp.evidente.local> <20141105083502.GB3950@mtcomp.evidente.local> Message-ID: <5459EA39.4050209@orbitalfox.com> On 05/11/14 08:35, Magnus Therning wrote: > Silly me! There's a rather obvious work-around that will allow me > updating while working on a more convenient way to deal with this. How are you doing it in the end? -- SP From magnus at therning.org Thu Nov 6 08:55:00 2014 From: magnus at therning.org (Magnus Therning) Date: Thu, 6 Nov 2014 09:55:00 +0100 Subject: [arch-haskell] Recent change to Hackage causes delay in updates In-Reply-To: <5459EA39.4050209@orbitalfox.com> References: <20141027190701.GD12570@tatooine.lan> <5450BDDF.3080807@orbitalfox.com> <20141029151350.GA5271@mtcomp.evidente.local> <20141105083502.GB3950@mtcomp.evidente.local> <5459EA39.4050209@orbitalfox.com> Message-ID: <20141106085500.GB30537@mtcomp.evidente.local> On Wed, Nov 05, 2014 at 09:13:29AM +0000, SP wrote: > On 05/11/14 08:35, Magnus Therning wrote: > > Silly me! There's a rather obvious work-around that will allow me > > updating while working on a more convenient way to deal with this. > > How are you doing it in the end? It's so embarrassingly simple... I extract the changes from the new .cabal into a patch on the source level. Specifically, I extract the changed .cabal for pandoc, which only existed in the index file, and put the changes into `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`. It's not a very good long-term solution, but it makes it workable until I have finished refactoring `cblrepo` so it can deal with the situation more intelligently. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From sp at orbitalfox.com Thu Nov 6 09:55:30 2014 From: sp at orbitalfox.com (SP) Date: Thu, 06 Nov 2014 09:55:30 +0000 Subject: [arch-haskell] Recent change to Hackage causes delay in updates In-Reply-To: <20141106085500.GB30537@mtcomp.evidente.local> References: <20141027190701.GD12570@tatooine.lan> <5450BDDF.3080807@orbitalfox.com> <20141029151350.GA5271@mtcomp.evidente.local> <20141105083502.GB3950@mtcomp.evidente.local> <5459EA39.4050209@orbitalfox.com> <20141106085500.GB30537@mtcomp.evidente.local> Message-ID: <545B4592.4040807@orbitalfox.com> On 06/11/14 08:55, Magnus Therning wrote: > Specifically, I extract the changed .cabal for pandoc, which only > existed in the index file, and put the changes into > `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`. Without experience in this, I was thinking that searching for diffs and automatic patching of the old cabals was one of doing it. But Apparently you don't care for the cabal? I mean it is only for deps anyway mostly right? > It's not a very good long-term solution, but it makes it workable > until I have finished refactoring `cblrepo` so it can deal with the > situation more intelligently. What is coming up? -- SP From magnus at therning.org Thu Nov 6 14:19:42 2014 From: magnus at therning.org (Magnus Therning) Date: Thu, 6 Nov 2014 15:19:42 +0100 Subject: [arch-haskell] Recent change to Hackage causes delay in updates In-Reply-To: <545B4592.4040807@orbitalfox.com> References: <20141027190701.GD12570@tatooine.lan> <5450BDDF.3080807@orbitalfox.com> <20141029151350.GA5271@mtcomp.evidente.local> <20141105083502.GB3950@mtcomp.evidente.local> <5459EA39.4050209@orbitalfox.com> <20141106085500.GB30537@mtcomp.evidente.local> <545B4592.4040807@orbitalfox.com> Message-ID: <20141106141942.GA851@mtcomp.evidente.local> On Thu, Nov 06, 2014 at 09:55:30AM +0000, SP wrote: > On 06/11/14 08:55, Magnus Therning wrote: >> Specifically, I extract the changed .cabal for pandoc, which only >> existed in the index file, and put the changes into >> `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`. > > Without experience in this, I was thinking that searching for diffs > and automatic patching of the old cabals was one of doing it. But > Apparently you don't care for the cabal? I mean it is only for deps > anyway mostly right? The .cabal is of course used to get to the dependencies, but beyond that it's not used for much in `cblrepo`, that's right. Automatic diffing would be one way. I was planning on simply copying in the correct .cabal (found in the index file) from the generated PKGBUILD. In either case the .cabal file has to be extracted from the index at `cblrepo pkgbuild`, something that hasn't been required earlier. >> It's not a very good long-term solution, but it makes it workable >> until I have finished refactoring `cblrepo` so it can deal with >> the situation more intelligently. > > What is coming up? The plan is to do the following: - modify the database format to hold the x-revision - modify `cblrepo list` to show the x-revision - modify `cblrepo updates` to pull out the .cabal from the index when looking for updates (previously it was enough to just look at the path in the .cabal to determine if an updated package was available) - modify `cblrepo add` to deal with x-revision - modify `cblrepo pkgbuild` to extract the .cabal from the index and generate PKGBUILDs having it as a source and copying it into the build folder, the version number of the packages also should include the x-revision Before all of this I want to rewrite the handling (reading, patching, copying) of .cabal files slightly. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: