From manuel.schneckenreither at student.uibk.ac.at Thu Sep 18 00:21:10 2014 From: manuel.schneckenreither at student.uibk.ac.at (Manuel Schneckenreither) Date: Thu, 18 Sep 2014 02:21:10 +0200 Subject: Cabal Preprocessor Defines Message-ID: <87vbolye15.fsf@student.uibk.ac.at> Hi all, I got some prepocessor constrains in one of my library I use for my new project. The section look like this: ... #ifdef DEBUG [ppSig sig | sig <- sigs ] #else [ppSig sig | sig <- filter ((\(_,_,r) -> not r) . lhsRootSym) sigs ] #endif ... Due to the reason that I am still developing wanted to specify the DEBUG preprocessor symbol to cpphs, gcc, ghc, or whatever program needs it. My suggestion was that cpphs should handle these definitions. So I tried several things, like: cabal configure --cpphs-options="--cpp -DDEBUG" --ghc-options=-DDEBUG --gcc-options=-DDEBUG && cabal build && cabal install , cabal configure --cpphs-options="-DDEBUG" --ghc-options=-DDEBUG --gcc-options=-DDEBUG && cabal build && cabal install or cabal configure && cabal build --cpphs-options="--cpp -DDEBUG" --cpphs-options=-DDEBUG --gcc-options=-DDEBUG && cabal install I tried it also in the cabal file: default-extensions: CPP -- also tried with other-extensions if flag(debug) CPP-Options: -DDEBUG if !os(windows) CC-Options: -DDEBUG else CC-Options: -DNDEBUG and compiling with cabal configure --flags=debug && cabal build && cabal install. None of them worked. Am I doing it wrong, or is there something wrong with cabal, cpphs, ghc, etc. Thanks for your reply, Manuel -- To reply secure use GnuPG encryption: Key Block to use (http://www.pinselzone.com/pgp/public_gpg_key.asc) What is GnuPG? (http://www.gnupg.org/) From hesselink at gmail.com Thu Sep 18 07:46:49 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 18 Sep 2014 09:46:49 +0200 Subject: Cabal Preprocessor Defines In-Reply-To: <87vbolye15.fsf@student.uibk.ac.at> References: <87vbolye15.fsf@student.uibk.ac.at> Message-ID: The way I usually do this, is your last option: I define 'CPP-Options: -DDEBUG' in the cabal file. I don't know why this doesn't work for you. Perhaps it is the final 'install' command, which duplicates the configure and build, but doesn't have the flag? You could try again with only 'cabal install -fdebug'. If that doesn't help, run cabal with '-v' to see what options are passed to all tools. Regards, Erik On Thu, Sep 18, 2014 at 2:21 AM, Manuel Schneckenreither wrote: > Hi all, > > I got some prepocessor constrains in one of my library I use for my new > project. The section look like this: > > ... > #ifdef DEBUG > [ppSig sig | sig <- sigs ] > #else > [ppSig sig | sig <- filter ((\(_,_,r) -> not r) . lhsRootSym) sigs ] > #endif > ... > > Due to the reason that I am still developing wanted to specify the DEBUG > preprocessor symbol to cpphs, gcc, ghc, or whatever program needs it. My > suggestion was that cpphs should handle these definitions. So I tried > several things, like: > > cabal configure --cpphs-options="--cpp -DDEBUG" > --ghc-options=-DDEBUG --gcc-options=-DDEBUG && cabal build > && cabal install > , > > cabal configure --cpphs-options="-DDEBUG" > --ghc-options=-DDEBUG --gcc-options=-DDEBUG && cabal build > && cabal install > or > > cabal configure && cabal build --cpphs-options="--cpp -DDEBUG" > --cpphs-options=-DDEBUG --gcc-options=-DDEBUG && cabal install > > > I tried it also in the cabal file: > > > default-extensions: CPP -- also tried with other-extensions > if flag(debug) > CPP-Options: -DDEBUG > if !os(windows) > CC-Options: -DDEBUG > else > CC-Options: -DNDEBUG > > and compiling with cabal configure --flags=debug && cabal build && cabal > install. > > > None of them worked. Am I doing it wrong, or is there something wrong > with cabal, cpphs, ghc, etc. > > > Thanks for your reply, > > Manuel > > > -- > To reply secure use GnuPG encryption: > Key Block to use (http://www.pinselzone.com/pgp/public_gpg_key.asc) > What is GnuPG? (http://www.gnupg.org/) > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel From carter.schonwald at gmail.com Tue Sep 23 03:47:52 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 22 Sep 2014 23:47:52 -0400 Subject: add an x86_64 linux build for cabal-install on the binaries site? Message-ID: Hey All, http://www.haskell.org/cabal/download.html current lacks an x86_64 linux build, and while most linux distros DO provide a relatively recent cabal-install, might be good to make that available, it is one of the most widely used platforms for haskell! (also the 32bit linux build can't really be used on 64bit linux without installing the 32bit userland stuff afaict) perhaps it'd be good to add that? (if only because it'll help some poor soul on some gnarly distro) -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue Sep 23 12:26:13 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 23 Sep 2014 14:26:13 +0200 Subject: add an x86_64 linux build for cabal-install on the binaries site? In-Reply-To: References: Message-ID: Hi, On 23 September 2014 05:47, Carter Schonwald wrote: > Hey All, > http://www.haskell.org/cabal/download.html > current lacks an x86_64 linux build, and while most linux distros DO provide > a relatively recent cabal-install, might be good to make that available, it > is one of the most widely used platforms for haskell! (also the 32bit linux > build can't really be used on 64bit linux without installing the 32bit > userland stuff afaict) > > perhaps it'd be good to add that? (if only because it'll help some poor soul > on some gnarly distro) I don't have x86-64 Linux installed ATM, so we need someone to provide the binaries. From nikita at karetnikov.org Sat Sep 27 00:30:06 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Sat, 27 Sep 2014 04:30:06 +0400 Subject: RFC: Finding the needed OpenPGP key (was: Proposal: cabal-install: verify OpenPGP signatures) In-Reply-To: <87bns7stbf.fsf@karetnikov.org> (Nikita Karetnikov's message of "Wed, 30 Jul 2014 02:17:56 +0400") References: <87eh0fafsq.fsf@karetnikov.org> <1399287343.18197.190.camel@dunky.localdomain> <87iopjuq7j.fsf@karetnikov.org> <87zjhh349d.fsf@karetnikov.org> <87oaxel7rf.fsf@karetnikov.org> <87bns7stbf.fsf@karetnikov.org> Message-ID: <87oau1hpm9.fsf_-_@karetnikov.org> There is a problem with the current OpenPGP spec: only an 8-octet key id is included in a signature, not the whole fingerprint [1,2]. I?d like to get some feedback on how to address this issue. This branch [3] contains the code that adds available OpenPGP keys and corresponding usernames to the index tarball. This information is used during ?cabal update? [4] to establish a set of trusted keys, which is then cached. When a user runs ?cabal install?, they only get a source tarball and possibly a signature. How would you find the right key in the cache? I see two options: 1. Match on 8-octet key ids. 2. Get an uploader name somehow and match on it instead. The first option is more simple, which is a good thing. But it would require to forbid clashing key ids. I think that?d be too restrictive (fingerprints could be different) and would require querying the cache for every key in the index tarball, which?d probably need a database. The second one means sending an additional web request for each package version during ?install?, which would also add input validation burden and potential security issues. Since I dislike both options, I?ve talked to Mikhail on IRC who suggested adding an ?x-hackage-uploader? field to .cabal files (similar to the already used ?x-hackage-revision?). That?d be done in the index tarball without changing the original files. I like this idea because it?s simple and would allow to avoid fingerprint collisions [5]. What would you do? [1] https://tools.ietf.org/html/rfc4880#section-5.2.3.5 [2] https://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html [3] https://gitorious.org/hackage-server/hackage-server/commits/openpgp [4] https://gitorious.org/cabal/cabal/commits/openpgp [5] https://www.ietf.org/mail-archive/web/openpgp/current/msg07195.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From carter.schonwald at gmail.com Sat Sep 27 16:40:31 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 27 Sep 2014 12:40:31 -0400 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> Message-ID: Currently released cabal-install on hackage doesn't know how to do linkery for ghc head afaik, but I could be wrong On Sat, Sep 27, 2014 at 12:26 PM, Reid Barton wrote: > On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang wrote: > >> Hey all, >> >> SPJ pointed out to me today that if you try to run: >> >> cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 >> >> with the latest GHC HEAD, this probably will not actually work, because >> your system installed version of Cabal is probably too old to deal with >> the new package key stuff in HEAD. So, how do you get a version >> of cabal-install (and Cabal) which is new enough to do what you need >> it to? >> >> The trick is to compile Cabal using your /old/ GHC. Step-by-step, this >> involves cd'ing into libraries/Cabal/Cabal and running `cabal install` >> (or install it in a sandbox, if you like) and then cd'ing to >> libraries/Cabal/cabal-install and cabal install'ing that. >> > > Hi all, > > The new cabal-install I built last month following the instructions above > started failing with recent GHC HEAD with messages like > > ghc: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with > the correct format. > > I found that repeating these steps with the latest libraries/Cabal > submodule gave me a cabal-install that, so far, appears to be working with > GHC HEAD. So if your cabal-install has stopped working with HEAD, try > building the latest version as outlined in Edward's email. > > Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware > of? > > Regards, > Reid Barton > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sat Sep 27 16:43:13 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 27 Sep 2014 09:43:13 -0700 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> Message-ID: <1411836134-sup-3864@sabre> Hi Reid, Ah yes, this is fallout from commit da7289882610ccae3f16c74be7440d19c29ecd20 Author: Duncan Coutts Date: Wed Aug 27 16:33:20 2014 +0100 Change testsuite to not use old-style file package databases Now uses ghc-pkg init. The file-style databases are no longer supported. So yes, you will need a new version of cabal-install for GHC HEAD. Cheers, Edward Excerpts from Reid Barton's message of 2014-09-27 09:26:08 -0700: > On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang wrote: > > > Hey all, > > > > SPJ pointed out to me today that if you try to run: > > > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > > > with the latest GHC HEAD, this probably will not actually work, because > > your system installed version of Cabal is probably too old to deal with > > the new package key stuff in HEAD. So, how do you get a version > > of cabal-install (and Cabal) which is new enough to do what you need > > it to? > > > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > > (or install it in a sandbox, if you like) and then cd'ing to > > libraries/Cabal/cabal-install and cabal install'ing that. > > > > Hi all, > > The new cabal-install I built last month following the instructions above > started failing with recent GHC HEAD with messages like > > ghc: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with > the correct format. > > I found that repeating these steps with the latest libraries/Cabal > submodule gave me a cabal-install that, so far, appears to be working with > GHC HEAD. So if your cabal-install has stopped working with HEAD, try > building the latest version as outlined in Edward's email. > > Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware > of? > > Regards, > Reid Barton From jakewheatmail at gmail.com Sun Sep 28 15:14:21 2014 From: jakewheatmail at gmail.com (Jake Wheat) Date: Sun, 28 Sep 2014 18:14:21 +0300 Subject: tweaks to cabal-install bootstrap.sh Message-ID: Hello, I've made some tweaks to the bootstrap.sh here: https://github.com/JakeWheat/cabal/tree/bootstrap-tweaks 1. It avoids downloading the additional haskell package tarballs if these tarballs are already present in the current directory. Motivation: easily install on machines not connected to the internet, and make install more robust against local internet connection problems (we have a lot of these). 2. The SCOPE_OF_INSTALLATION variable use is slightly changed to allow installing cabal-install executable without either using or altering the user's package database, or replacing any cabal-install executable which they already have. Example: ghc-pkg init /home/jake/test_cabal/ SCOPE_OF_INSTALLATION='--global --package-db=/home/jake/test_cabal/packagedb' PREFIX=/home/jake/test_cabal/prefix ./bootstrap.sh Is it possible to put these changes into the main cabal repo? If there are some changes which would make the patch acceptable then please let me know. Also, is there a simpler way to meet these goals which I missed? Thanks, Jake Wheat -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Sun Sep 28 16:23:50 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sun, 28 Sep 2014 18:23:50 +0200 Subject: tweaks to cabal-install bootstrap.sh In-Reply-To: References: Message-ID: Hi, On 28 September 2014 17:14, Jake Wheat wrote: > [...] > Is it possible to put these changes into the main cabal repo? Sure, please send us a pull request.