Re: [fis-gtm] ready for upload - needs sponsor
On Nov 23, 2013, at 4:48 PM, Andreas Tille wrote: > Hi Amul, > > since my first upload was rejected due to some licensing issue of some > documentation file we have some chance for an update. However, I think > you totally missed the point what we need to build the package. As I > said from the beginning the difference between the > gtm__linux_i686_pro.tar.gz and > gtm__linux_i686_src.tar.gz are not clear to me. You claimed > that V60003 would have been the latext fis-gtm version and I can confirm > that there is > > gtm_V60003_linux_i686_pro.tar.gz > > available but this file does not contain the SOURCE. The latest > download file which really contains source files is > > gtm_V60001_linux_i686_src.tar.gz > > Amul, please pretty please, if you do not understand the principles > behind packaging just tell us so to enable to be more verbose and to > teach you. Providing wrong information is not helpful and drains time > of others. > > After having fixed Git now to fit ftpmasters requirements I'm idling > until I get reliable information about the latest upstream source for > download. If I do not see any newer source than 60001 for download > until Wednesday next week I will reupload this version to not loose more > time. As I said we can upload later new versions way more quickly once > the package might have passed the new queue. > > Kind regards > > Andreas. [snip] Hi Andreas, Getting rejected has some benefits. :) To clarify, the GT.M binary archive has never shipped with the sources. Previously, we uploaded to SourceForge two archives per platform, one for the binaries and one for the sources. FIS releases GT.M as open source on VMS and Linux IA32 and x86_64. As part of the after hackathon (many thanks to Luis, Brad and Yaroslav for their help then and afterwards) todo items, I merged all sources into one unified tar archive containing the sources for Linux (IA32 and x86_64) and VMS. I also renamed the archive to use fis-gtm---.tar.gz which unpacked into a directory with the same name as the archive without the tar.gz. Previously the archive untarred to the current working directory which meant that someone had to create the target directory for the sources, change directory into it and untar the archive. The binary archives are available from the following links: http://sourceforge.net/projects/fis-gtm/files/GT.M-amd64-Linux/V6.0-003/ http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux/V6.0-003/ The source archive is available from the following link: http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/V6.0-003/ The same sources are also available via SourceForge CVS. I have a strong feeling that I’m not saying anything new to you. With respect to not understanding the principles behind packaging, I would say that I don’t know what the principles are. Hence no understanding. For that I apologize. My knowledge is completely adhoc. To get this going forward, do I need to push the archive somewhere as part of the GIT repository? Or is it the watch file that needs fixing? Is FIS expected to ship binaries and sources in the same archive for Debian packaging? thanks, Amul -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/840eecc8-b7ca-4c88-8290-3a80c3a4b...@amulz.com
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
Hi, just builded successfully and pushed some slight polishing changes. Would you mind writing a man page for mne? Moreover you did not yet commented my suggestion to drop the term "python" inside the software name. Kind regards Andreas. On Sat, Nov 23, 2013 at 10:46:07PM +0100, Alexandre Gramfort wrote: > hi, > > > I adapted packaging in Git to 0.7~rc3 and we are down to only one failed > > test: > > > > - > > TOTAL 20945 817361% > > -- > > Ran 290 tests in 366.180s > > > > FAILED (SKIP=89, failures=1) > > make[2]: *** [test-no-sample] Error 1 > > > > See full build log attached. Seems it is either > > > > Test Yule-Walker against statsmodels ... SKIP: XFailed Test > > this was not a failure. I made the message more informative though. > > > but more probably: > > > > Test file downloading ... > > this one is the failure. I tried something to make it work. > > and pushed tag v0.7rc4 > > the test should pass without internet connection. > > see: > > https://github.com/mne-tools/mne-python/blob/master/mne/tests/test_utils.py#L202 > > >> > occures in the build log. You need to know that the package build > >> > process needs to run on a computer without internet connection and you > >> > can/should easily simulate this by using pdebuild. Since you are > >> > upstream you might be able to inject some option to the tests to ignore > >> > all those that need to download something. > >> > >> it's what test-no-sample should hopefully do. > > > > Tried this (see d/rules in Git). > > you commented: > > #MNE_SKIP_SAMPLE_DATASET_TESTS=true \ > # xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 > -ac +extension GLX +render -noreset" \ > # $(NOSETESTS) mne > > which was "supposed" to do the job and also avoid failure when running > tests requiring X such as tests relying on mayavi if present. > > the xvfb-run should not be in the Makefile. > > let me know if tests pass now. If not I'll comment the test. > > thanks again > > Alex > -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131123232147.gi15...@an3as.eu
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
hi, > I adapted packaging in Git to 0.7~rc3 and we are down to only one failed > test: > > - > TOTAL 20945 817361% > -- > Ran 290 tests in 366.180s > > FAILED (SKIP=89, failures=1) > make[2]: *** [test-no-sample] Error 1 > > See full build log attached. Seems it is either > > Test Yule-Walker against statsmodels ... SKIP: XFailed Test this was not a failure. I made the message more informative though. > but more probably: > > Test file downloading ... this one is the failure. I tried something to make it work. and pushed tag v0.7rc4 the test should pass without internet connection. see: https://github.com/mne-tools/mne-python/blob/master/mne/tests/test_utils.py#L202 >> > occures in the build log. You need to know that the package build >> > process needs to run on a computer without internet connection and you >> > can/should easily simulate this by using pdebuild. Since you are >> > upstream you might be able to inject some option to the tests to ignore >> > all those that need to download something. >> >> it's what test-no-sample should hopefully do. > > Tried this (see d/rules in Git). you commented: #MNE_SKIP_SAMPLE_DATASET_TESTS=true \ # xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 -ac +extension GLX +render -noreset" \ # $(NOSETESTS) mne which was "supposed" to do the job and also avoid failure when running tests requiring X such as tests relying on mayavi if present. the xvfb-run should not be in the Makefile. let me know if tests pass now. If not I'll comment the test. thanks again Alex -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadeotzqiqfu360os6u_1qwoaq6gsn9v8z9+cuquaqepwjdk...@mail.gmail.com
Re: [fis-gtm] ready for upload - needs sponsor
Hi Amul,
since my first upload was rejected due to some licensing issue of some
documentation file we have some chance for an update. However, I think
you totally missed the point what we need to build the package. As I
said from the beginning the difference between the
gtm__linux_i686_pro.tar.gz and
gtm__linux_i686_src.tar.gz are not clear to me. You claimed
that V60003 would have been the latext fis-gtm version and I can confirm
that there is
gtm_V60003_linux_i686_pro.tar.gz
available but this file does not contain the SOURCE. The latest
download file which really contains source files is
gtm_V60001_linux_i686_src.tar.gz
Amul, please pretty please, if you do not understand the principles
behind packaging just tell us so to enable to be more verbose and to
teach you. Providing wrong information is not helpful and drains time
of others.
After having fixed Git now to fit ftpmasters requirements I'm idling
until I get reliable information about the latest upstream source for
download. If I do not see any newer source than 60001 for download
until Wednesday next week I will reupload this version to not loose more
time. As I said we can upload later new versions way more quickly once
the package might have passed the new queue.
Kind regards
Andreas.
On Thu, Oct 24, 2013 at 11:38:30PM -0400, Amul Shah wrote:
>
> >
> >> I'm still working on recollecting where I left off.
> >
> > Please be as verbose as possible about any problem you might face. Luis
> > mentioned some login problems (which I do not remember). Just let us
> > know any hurdle you need to take.
>
> Hi Andreas,
> Well, I have no clue as to where I left off. :( It took me a bit to find my
> GIT debmed workspace.
>
> Apparently I was sitting on a commit for V6.0-002. I merged my changes with
> yours and bumped the version to V6.0-003 in debian/control and
> debian/get-orig-source. Please take a look.
>
> I don't fully grasp how the watch file works, but that URL looks wrong. This
> is the URL that get-orig-source uses:
>
> http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/${PKGVERSION}/fis-gtm-${PKGVERSION}.tar.gz
>
> get-orig-source is a script that Luis gave me. The watch file from my branch
> seemed to use that script.
>
> If it helps, the SourceForge CVS repo is up to date.
>
> I have not tried to do a build yet, because I don't remember how to do it.
> Apparently it's so drop dead easy that I didn't bother to leave myself any
> notes.
>
> thanks,
> Amul
>
>
> --
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/ced87f6a-d39f-47ca-9e70-85a9c89ba...@amulz.com
>
>
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131123214807.gg15...@an3as.eu
Re: [fis-gtm] ready for upload - needs sponsor
Hi, any news from testing? ftpmaster rejected the package so we have some chance for changing if anything was wrong. KInd regards Andreas. On Fri, Oct 25, 2013 at 02:38:21PM -0400, Laurent Parenteau wrote: > Hi Andreas, > > I would be happy to test it in advance. Let me know where you upload it > and I'll grab it. > > Thanks, > Laurent > > > On Wed, Oct 23, 2013 at 2:38 AM, Andreas Tille wrote: > > > Hi Laurent, > > > > On Tue, Oct 22, 2013 at 05:22:40PM -0400, Laurent Parenteau wrote: > > > Is there any (automated) ways to be notified once the package will be > > > available in unstable? > > > > Besided the answer Dominique has given I could easily upload the > > packages to some web space where you can download and test in advance. > > Just ask me to do so. > > > > Kind regards > > > > Andreas. > > > > -- > > http://fam-tille.de > > > > > > -- > > To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact > > listmas...@lists.debian.org > > Archive: http://lists.debian.org/20131023063857.gb3...@an3as.eu > > > > -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131123212712.gf15...@an3as.eu
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
Hi Alexandre, On Sat, Nov 23, 2013 at 03:50:20PM +0100, Alexandre Gramfort wrote: > > I have tried to build the package and noticed that not all the test > > are passing. For instance: > > the full test suite requires a large download but it can be skipped while > maintaining > 60% coverage of the code. See target test-no-sample > in Makefile. > > test-no-sample: in > @MNE_SKIP_SAMPLE_DATASET_TESTS=true \ > $(NOSETESTS) mne > > it should be good enough? I adapted packaging in Git to 0.7~rc3 and we are down to only one failed test: - TOTAL 20945 817361% -- Ran 290 tests in 366.180s FAILED (SKIP=89, failures=1) make[2]: *** [test-no-sample] Error 1 See full build log attached. Seems it is either Test Yule-Walker against statsmodels ... SKIP: XFailed Test but more probably: Test file downloading ... FAIL > > occures in the build log. You need to know that the package build > > process needs to run on a computer without internet connection and you > > can/should easily simulate this by using pdebuild. Since you are > > upstream you might be able to inject some option to the tests to ignore > > all those that need to download something. > > it's what test-no-sample should hopefully do. Tried this (see d/rules in Git). Kind regards Andreas. -- http://fam-tille.de mne-python_0.7~rc3-1_amd64.build.gz Description: Binary data
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
hi Andreas, > Hmmm, I tried the same and it went fine so far (see latest commit; weird >> here is my git config: >> >> gramfort@tsilinuxd74:mne-python(master)$ cat .git/config >> [core] >> repositoryformatversion = 0 >> filemode = true >> bare = false >> logallrefupdates = true >> [remote "origin"] >> fetch = +refs/heads/*:refs/remotes/origin/* >> url = ssh://git.debian.org/git/debian-med/mne-python.git >> [branch "master"] >> remote = origin >> merge = refs/heads/master >> [branch "upstream"] >> remote = origin >> merge = refs/heads/upstream >> >> --- > > If I create a fresh clone in addition to your config I have > > [branch "pristine-tar"] > remote = origin > merge = refs/heads/pristine-tar I appended this but no success. git import-orig --pristine-tar ../mne-python_0.7~rc3.orig.tar.gz fails but at least creates the commit on upstream and I can push it manually. maybe it's good enough? see 6f7c0563066ba434033479decec10815dc43e467 > I have tried to build the package and noticed that not all the test > are passing. For instance: the full test suite requires a large download but it can be skipped while maintaining > 60% coverage of the code. See target test-no-sample in Makefile. test-no-sample: in @MNE_SKIP_SAMPLE_DATASET_TESTS=true \ $(NOSETESTS) mne it should be good enough? > occures in the build log. You need to know that the package build > process needs to run on a computer without internet connection and you > can/should easily simulate this by using pdebuild. Since you are > upstream you might be able to inject some option to the tests to ignore > all those that need to download something. it's what test-no-sample should hopefully do. Thanks Best, Alex > Kind regards > >Andreas. > > -- > http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadeotzrt23d1kg4m96x+pk+5svmmdfls7e_-wgpggasrbpu...@mail.gmail.com
