Re: changing priority optional->extra
On 06.11.2013 08:49, Andreas Tille wrote: > Hi, Hello Andreas, > general statement for everybody: Please use > >Priority: optional > > for all your packages which are not *-dbg (Debug) packages. Everything > else is some kind of wrong shyness / understatement because you might > think your package is "not so important". As explained below the > differences between optional and extra are not very large.[1] I have > also read somewhere that not all QA tools we have in Debian are extended > to priority extra packages - but we *really* want to have all those nifty > tools running on our software. OK, got it. Will keep this in mind for my next package to do it the right way from the start. [...] >> I see. I remember that during the first upload the priorities were set >> to extra, and only later changed to optional to comply with the DebMed >> policy -- I guess that's where the disparities came from in the first >> place. Do you think it is worth the while to file a change request? > > I vaguely remember that these things are changed at some point in time > without filing such requests. However, it seems that the previous > uploads did not showed some "healing" effect - so perhaps filing the > change request might make sense. I will look into this when I find the time. [...] > BTW, I'd also check out the 'oldlibs' issue. Yep, I will switch the pango deps from the transitional libpango1.0-0 to the new modular libpango*-1.0-0 packages soon. [...] >>> In the case of the sections, libraries should be in the “libs” >>> section so here it is definitely the source package that has to be >>> corrected. By the way, the override disparities are a minor >>> problem, so there is no need to immediately upload if it is only to >>> propagate the changes. >> Great, thanks for the information! I will make the necessary >> adjustments to the packages and upload with the next updated upstream >> release. > Charles is right here to use "Section: libs" for the library. If I > remember right the usage of d-shlibs will check this - one nice reason > to use this for library packages. (We have examples for d-shlibs usage > in our Vcs, the most extensive example is probably staden-io-lib.) Ah, thanks for the hint. I will definitely have a look at that. > I also agree with Charles, that there is no really need to hurry up > with an upload. I personally would go with a commit to Vcs of the > relevant change to make sure it will not be forgotten. (Make sure > you set target distribution to "UNRELEASED".) Okay, will do this maybe later in the evening ;) > Kind regards > > Andreas. Kind regards Sascha -- Sascha Steinbiss Center for Bioinformatics University of Hamburg Bundesstr. 43 20146 Hamburg Germany Email: steinb...@zbh.uni-hamburg.de URL:http://www.zbh.uni-hamburg.de/steinbiss Phone: +49 (40) 42838 7322 FAX:+49 (40) 42838 7312 -- 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/527a38f5.30...@zbh.uni-hamburg.de
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
Hi Alexandre, On Tue, Nov 05, 2013 at 05:52:29PM +0100, Alexandre Gramfort wrote: > please have a look at our debian branch: > > https://github.com/mne-tools/mne-python/tree/debian Looks good from quick view without doing an actual build. I have attached a fix for the debian/watch file - the file in your repository does not report anything when trying `uscan --verbose --report`. > let me know if I can do anything. Considering they are in the Uploaders field it seems you are just in contact with Michael and Yaroslav which is not surprising because your package is perfectly interesting for NeuroDebian as well. Just to let you know about the relation between NeuroDebian and Debian Med: We are naturally interested in a common set of packages but there is no point in competing who maintains what. Some packages are maintained technically by NeuroDebian team and some by Debian Med team but both projects are including the packages in their tasks (which are kind of categories in specific work fields - you can see the Debian Med tasks here[0] and I guess mne-python would make a good fit into "practice"). (BTW, NeuroDebian is presenting their packages in a different way but we are trying to make use of the same toolset in the future.) The Debian Med team has some policy to define certain workflows in using Git and this does not fit exactly to your preparation. Shortly speaking we are only importing upstream release tarballs and adding a debian/ directory. I have seen in your debian/gbp.conf that you have done means to copy with different branches and I guess you would like to keep this workflow. From what I have heard from NeuroDebian people they have other packages with a similar workflow which somehow would be a good reason to let them take over the maintenance / sponsoring. Michael, Yaroslav: Any comment? In any case it has several advantages to at least maintain a clone in one of our repositories at git.debian.org because we have some tools browsing the repositories and doing some general analysis over the VCS status. It would be good if we could do this also for mne-python but the NeuroDebian people might have the last word in case they agree that they take over the package. In any case it would be really interesting to describe the workflow they are using in some kind of policy document. In case this sounds convincing we could take over this into Debian Med policy[1]. > Our official 0.7 release should be in the next couple of weeks. > It would be great to have it then in debian. I do not see any general problem here, except that you need to remember that new packages can only go to unstable / testing and if you want to have the package in Debian stable you need to wait for the next release (Jessie, Debian 8). Kind regards Andreas. [0] http://debian-med.alioth.debian.org/tasks/ [ leaving full quote for NeuroDebian team list ... ] > On Tue, Nov 5, 2013 at 5:03 PM, Andreas Tille wrote: > > Hi Alexandre, > > > > thanks for your ITP which is very interesting for Debian Med. We would > > be really happy if you would maintain this package in the Debian Med > > team. The procedure to do so is described in our team policy[1]. > > > > Please do not hesitate to contact us via our (see CC) mailing list if > > something might remain unclear. > > > > Kind regards > > > > Andreas. > > > > > > [1] http://debian-med.alioth.debian.org/docs/policy.html > > > > On Tue, Nov 05, 2013 at 04:38:42PM +0100, Alexandre Gramfort wrote: > >> Package: wnpp > >> Severity: wishlist > >> Owner: Alexandre Gramfort > >> > >> * Package name: python-mne > >> Version : 0.7.git > >> Upstream Author : Alexandre Gramfort > >> * URL : https://github.com/mne-tools/mne-python > >> * License : BSD > >> Programming Lang: Python > >> Description : Python modules for MEG and EEG data analysis > >> > >> This package is designed for sensor- and source-space analysis of MEG and > >> EEG > >> data, including frequency-domain and time-frequency analyses and > >> non-parametric statistics. > >> > >> > >> -- > >> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > >> with a subject of "unsubscribe". Trouble? Contact > >> listmas...@lists.debian.org > >> Archive: > >> http://lists.debian.org/20131105153842.12599.38463.report...@tsilinuxd74.enst.fr > >> > >> > > > > -- > > 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/cadeotzoq2+m6fyd0mqp67z+1i8sypgicxpbxpnv0hn1pwn3...@mail.gmail.com > > -- http://fam-tille.de version=3 opts="dversionmangle=s/.dfsg$//,filenamemangle=s/.*v([\d\.]+)\..*/mne-python_$1.orig.tar.gz/" \ https://github.com/mne-tools/mne-python/tags .*/archive/v([\d\.a-z]+)\.(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz))
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
hi Andreas, > On Tue, Nov 05, 2013 at 05:52:29PM +0100, Alexandre Gramfort wrote: >> please have a look at our debian branch: >> >> https://github.com/mne-tools/mne-python/tree/debian > > Looks good from quick view without doing an actual build. I have > attached a fix for the debian/watch file - the file in your repository > does not report anything when trying `uscan --verbose --report`. fixed in debian branch >> let me know if I can do anything. > > Considering they are in the Uploaders field it seems you are just in > contact with Michael and Yaroslav which is not surprising because your > package is perfectly interesting for NeuroDebian as well. Just to let > you know about the relation between NeuroDebian and Debian Med: We are > naturally interested in a common set of packages but there is no point > in competing who maintains what. Some packages are maintained > technically by NeuroDebian team and some by Debian Med team but both > projects are including the packages in their tasks (which are kind of > categories in specific work fields - you can see the Debian Med tasks > here[0] and I guess mne-python would make a good fit into "practice"). > (BTW, NeuroDebian is presenting their packages in a different way but we > are trying to make use of the same toolset in the future.) > > The Debian Med team has some policy to define certain workflows in using > Git and this does not fit exactly to your preparation. Shortly speaking > we are only importing upstream release tarballs and adding a debian/ > directory. I have seen in your debian/gbp.conf that you have done means > to copy with different branches and I guess you would like to keep this > workflow. From what I have heard from NeuroDebian people they have other > packages with a similar workflow which somehow would be a good reason > to let them take over the maintenance / sponsoring. Michael, Yaroslav: > Any comment? Honestly I have no preference as long as python-mne can be apt-get installed. Just let me know what's best and the easiest for me. > In any case it has several advantages to at least maintain a clone in > one of our repositories at git.debian.org because we have some tools > browsing the repositories and doing some general analysis over the > VCS status. It would be good if we could do this also for mne-python > but the NeuroDebian people might have the last word in case they agree > that they take over the package. In any case it would be really > interesting to describe the workflow they are using in some kind of > policy document. In case this sounds convincing we could take over > this into Debian Med policy[1]. having python-mne in both would be great. Yaroslav has helped me up to now to meet neurodebian's requirements. I'd appreciate any help (pull request) to meet Debian Med policy. >> Our official 0.7 release should be in the next couple of weeks. >> It would be great to have it then in debian. > > I do not see any general problem here, except that you need to remember > that new packages can only go to unstable / testing and if you want to > have the package in Debian stable you need to wait for the next release > (Jessie, Debian 8). no problem. Thanks for your insights and help Alex > Kind regards > > Andreas. > > [0] http://debian-med.alioth.debian.org/tasks/ > > [ leaving full quote for NeuroDebian team list ... ] > >> On Tue, Nov 5, 2013 at 5:03 PM, Andreas Tille wrote: >> > Hi Alexandre, >> > >> > thanks for your ITP which is very interesting for Debian Med. We would >> > be really happy if you would maintain this package in the Debian Med >> > team. The procedure to do so is described in our team policy[1]. >> > >> > Please do not hesitate to contact us via our (see CC) mailing list if >> > something might remain unclear. >> > >> > Kind regards >> > >> > Andreas. >> > >> > >> > [1] http://debian-med.alioth.debian.org/docs/policy.html >> > >> > On Tue, Nov 05, 2013 at 04:38:42PM +0100, Alexandre Gramfort wrote: >> >> Package: wnpp >> >> Severity: wishlist >> >> Owner: Alexandre Gramfort >> >> >> >> * Package name: python-mne >> >> Version : 0.7.git >> >> Upstream Author : Alexandre Gramfort >> >> * URL : https://github.com/mne-tools/mne-python >> >> * License : BSD >> >> Programming Lang: Python >> >> Description : Python modules for MEG and EEG data analysis >> >> >> >> This package is designed for sensor- and source-space analysis of MEG and >> >> EEG >> >> data, including frequency-domain and time-frequency analyses and >> >> non-parametric statistics. >> >> >> >> >> >> -- >> >> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >> >> with a subject of "unsubscribe". Trouble? Contact >> >> listmas...@lists.debian.org >> >> Archive: >> >> http://lists.debian.org/20131105153842.12599.38463.report...@tsilinuxd74.enst.fr >> >> >> >> >> > >> > -- >> > http://fam-tille.de >> >> >> -- >> To UNSUBSCRIBE, email to debian-med-re
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
On Wed, 06 Nov 2013, Andreas Tille wrote: > > > In any case it has several advantages to at least maintain a clone in > > > one of our repositories at git.debian.org because we have some tools > > > browsing the repositories and doing some general analysis over the > > > VCS status. It would be good if we could do this also for mne-python > > > but the NeuroDebian people might have the last word in case they agree > > > that they take over the package. In any case it would be really > > > interesting to describe the workflow they are using in some kind of > > > policy document. Hi guys -- nice to see a live discussion ;) Indeed we do not have yet as clear policy/workflow as Debian Med does... in majority of the cases I am trying to "integrate" packaging within the (clone of) upstream repository, so to bring lives of both "developments" into a single history. Thus it is not an 'overlay' repository as Debian Med usually does, but rather a 'debian' branch which contains the packaging and merges from upstream's master or release branches (if those are divergent from master, it becomes a bit more dance). I guess this should be the major difference from how Debian Med does it, right Andreas? > > > In case this sounds convincing we could take over > > > this into Debian Med policy[1]. > > having python-mne in both would be great. Yaroslav has helped me > > up to now to meet neurodebian's requirements. I'd appreciate any > > help (pull request) to meet Debian Med policy. > "Having in both" is the wrong expression. Debian Med is pure Debian and > thus we bring the package into official Debian and it is available for > all users in medicine and neuroscience. You might like to understand > the idea of Debian Pure Blends[1]. I guess Alexandre meant "in both Debian and NeuroDebian", because we would immediately provide backport builds for all supported Debian and Ubuntu releases. > The actual Debian Med policy describes some conventions and workflows we > have agreed upon inside the packaging team. I somehow have the feeling > that it might create less work for you if you follow the advise of > Yaroslav and he might sponsor the package. I am yet to do thorough review, so if you have a moment indeed it would be helpful... e.g. overlooked adding debian/upstream file ;) and actually this upcoming release AFAIK is rushed to get mne-python publication out (so it could be added to debian/upstream for references), right Alexandre? ;-) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20131106214313.gx9...@onerussian.com
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
Hi Alexandre, On Wed, Nov 06, 2013 at 05:26:13PM +0100, Alexandre Gramfort wrote: > > Looks good from quick view without doing an actual build. I have > > attached a fix for the debian/watch file - the file in your repository > > does not report anything when trying `uscan --verbose --report`. > > fixed in debian branch :-) > > In any case it has several advantages to at least maintain a clone in > > one of our repositories at git.debian.org because we have some tools > > browsing the repositories and doing some general analysis over the > > VCS status. It would be good if we could do this also for mne-python > > but the NeuroDebian people might have the last word in case they agree > > that they take over the package. In any case it would be really > > interesting to describe the workflow they are using in some kind of > > policy document. In case this sounds convincing we could take over > > this into Debian Med policy[1]. > > having python-mne in both would be great. Yaroslav has helped me > up to now to meet neurodebian's requirements. I'd appreciate any > help (pull request) to meet Debian Med policy. "Having in both" is the wrong expression. Debian Med is pure Debian and thus we bring the package into official Debian and it is available for all users in medicine and neuroscience. You might like to understand the idea of Debian Pure Blends[1]. The actual Debian Med policy describes some conventions and workflows we have agreed upon inside the packaging team. I somehow have the feeling that it might create less work for you if you follow the advise of Yaroslav and he might sponsor the package. However, in case NeuroDebian people might face some time constraints I'd happily work as fallback for the final push to the Debian mirror. We have some record of teaching people inside our team[2] and considering, that the packaging status looks quite advanced I see no problem to finalise the process. > > I do not see any general problem here, except that you need to remember > > that new packages can only go to unstable / testing and if you want to > > have the package in Debian stable you need to wait for the next release > > (Jessie, Debian 8). > > no problem. > > Thanks for your insights and help You are welcome Andreas. [1] http://blends.alioth.debian.org/blends/ [2] http://wiki.debian.org/DebianMed/MoM -- 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/20131106213000.gb13...@an3as.eu
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
Hi,
just one point I always forget to append at the end of my mails: I'm
personally quite irritated when the language a program is written in is
part of the name. Considering a
linux-c/asm
apache-c
kde-c++
eclipse-java
...
you get the idea. From a users perspective it is perfectly
uninteresting in what programming language some software is written in.
Just a personal hint.
On Wed, Nov 06, 2013 at 04:43:13PM -0500, Yaroslav Halchenko wrote:
> On Wed, 06 Nov 2013, Andreas Tille wrote:
> > > > In any case it has several advantages to at least maintain a clone in
> > > > one of our repositories at git.debian.org because we have some tools
> > > > browsing the repositories and doing some general analysis over the
> > > > VCS status. It would be good if we could do this also for mne-python
> > > > but the NeuroDebian people might have the last word in case they agree
> > > > that they take over the package. In any case it would be really
> > > > interesting to describe the workflow they are using in some kind of
> > > > policy document.
>
> Hi guys -- nice to see a live discussion ;)
:-)
> Indeed we do not have yet as clear policy/workflow as Debian Med does...
The workflow as described in policy is a consequence of enabling
effective cooperation in a larger team and (as I mentioned before) the
fact that some tools are relying on the existence of certain files at
certain places (debian/ dir in VCS at {git,svn}.debian.org).
> in majority of the cases I am trying to "integrate" packaging within the
> (clone of) upstream repository, so to bring lives of both
> "developments" into a single history. Thus it is not an 'overlay'
> repository as Debian Med usually does, but rather a 'debian' branch
> which contains the packaging and merges from upstream's master or
> release branches (if those are divergent from master, it becomes a bit
> more dance). I guess this should be the major difference from how
> Debian Med does it, right Andreas?
I think this is correct. The rationale why we are importing only
released tarballs is, that usually a Debian package is based on a
downloadable release tarball provided by upstream. "Usually" means that
I'm aware that since the advent of Git some people found other ways to
do so and I do not intend to block people from finding new ways which
might fit better under certain circumstances. Debian Med is kind of
conservative to lower the entrance barrier from a packagers point of
view.
The point in policy where it is described is here:
http://debian-med.alioth.debian.org/docs/policy.html#git-tips
In case we might agree to follow this I'd volunteer to create such a
repository based on the last released tarball (version 0.6) and the
current packaging stuff - if this is not to divergent from what is
needed for the 0.7 release. In the later case it might be a good
idea to have some v0.7~rc1 tarball with the current state and I'll
base everything on this until v0.7 is out. For the future I would
like Alexandre to become a member of the Debian Med team and do the
needed updates in the Git repository at git.debian.org/debian-med.
> > "Having in both" is the wrong expression. Debian Med is pure Debian and
> > thus we bring the package into official Debian and it is available for
> > all users in medicine and neuroscience. You might like to understand
> > the idea of Debian Pure Blends[1].
>
> I guess Alexandre meant "in both Debian and NeuroDebian", because we
> would immediately provide backport builds for all supported Debian and
> Ubuntu releases.
Yep. I think I understand what Alexandre meant - we just tried to
explain from different angles.
> I am yet to do thorough review, so if you have a moment indeed it would
> be helpful... e.g. overlooked adding debian/upstream file ;)
It would be easy for me to write such a file if I'd get some link
to the publication. The documentation of debian/upstream files can
be found here:
https://wiki.debian.org/UpstreamMetadata#Fields
It is sufficient to provide the Reference fields only and for the
sake of simplicity I'm always using this very easy template:
http://anonscm.debian.org/viewvc/debian-med/trunk/package_template/upstream?view=markup
> and
> actually this upcoming release AFAIK is rushed to get mne-python
> publication out (so it could be added to debian/upstream for
> references), right Alexandre? ;-)
If you are in a pre-publication phase please think about my hint about
possibly removing the programming language from the name.
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/20131106220616.gc13...@an3as.eu
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
On Wed, Nov 06, 2013 at 11:06:16PM +0100, Andreas Tille wrote: > Hi, > > just one point I always forget to append at the end of my mails: I'm > personally quite irritated when the language a program is written in is > part of the name. Considering a > >linux-c/asm >apache-c >kde-c++ >eclipse-java >... > > you get the idea. From a users perspective it is perfectly > uninteresting in what programming language some software is written in. > Just a personal hint. Remark: If I might have missunderstood the main point of the package and bin/mne is not the main user interface but the package is rather oriented to developers who create their own python applications around the Python modules provided by python-mne - just forget what I wrote. 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/20131106221837.ge13...@an3as.eu
Debian builds of ITK for non-x84/amd64 architectures
Hi Steve, Dominique, Marco, [list-cross-post] Jean-Christophe noted this bug [1] at the CTK hackfest, which is blocking CTK for other architectures. Is it possible to get some of these architectures reporting nightly builds [2] to the ITK software quality dashboard [3], so they can be cleaned up? Thanks, Matt [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711 [2] http://www.itk.org/Wiki/ITK/Git/Dashboard [3] http://open.cdash.org/index.php?project=Insight -- 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/CALzTN-QXOsH4vWhYQHzijdx4T3dnewcOLk7dvtkXLxfh=ul...@mail.gmail.com
Re: Debian builds of ITK for non-x84/amd64 architectures
Hi Matt, Thank you for looking into this. Per Debian policy the build machines cannot submit any build reports, but you can get all build logs (with all failing tests) here: https://buildd.debian.org/status/logs.php?pkg=insighttoolkit4 I see that the ITK build time on Debian's build machines can take up to 3 days. So it might be worth to setup a local build machine in your office. Luis did something similar a while ago: Cross Compiling ITK for Raspberry Pi http://www.kitware.com/blog/home/post/428 Google Chromebook likes ITK with Crouton http://www.kitware.com/blog/home/post/532 It is good to fix build issues on those platforms, but given the very long build time I support Steve's decision to support only popular architectures. Cheers -Dominique On Wed, Nov 6, 2013 at 5:43 PM, Matt McCormick wrote: > Hi Steve, Dominique, Marco, [list-cross-post] > > Jean-Christophe noted this bug [1] at the CTK hackfest, which is > blocking CTK for other architectures. Is it possible to get some of > these architectures reporting nightly builds [2] to the ITK software > quality dashboard [3], so they can be cleaned up? > > Thanks, > Matt > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711 > [2] http://www.itk.org/Wiki/ITK/Git/Dashboard > [3] http://open.cdash.org/index.php?project=Insight >
Re: Debian builds of ITK for non-x84/amd64 architectures
Hello Matt, On November 6, 2013 05:43:37 PM Matt McCormick wrote: > Jean-Christophe noted this bug [1] at the CTK hackfest, which is > blocking CTK for other architectures. Is it possible to get some of > these architectures reporting nightly builds [2] to the ITK software > quality dashboard [3], so they can be cleaned up? It's a great idea in principle for all the debian architectures to submit to the ITK dashboard -- and now that we're down to just two, we do have full coverage! :-) If we want better coverage, the hard truth is that we need more volunteers and on a sustained basis. As Dominique mentioned, policy for the official build daemon machines forbids network access from the build. So, a while back, I asked around for some other machines to use for nightly builds. I got a couple of offers of a login, but I lacked the time to set up and maintain the nightly. The other hard truth is that having a nightly build is not enough. Each architecture needs a champion who will investigate the failures, do extra testing or develop patches. The ITK community won't do it on their own. Even with a nightly build submitted to cdash. I'm willing to help out with advice but I simply lack the time to do very much follow-up for non-mainstream architectures. Truthfully, I don't have much time even for amd64 so more blood for Debian packaging would be welcome! Cheers, -Steve signature.asc Description: This is a digitally signed message part.
Re: Debian builds of ITK for non-x84/amd64 architectures
Hi Dominique and Steve, As Dominique mentioned, policy for the official build daemon machines > forbids > network access from the build. So, a while back, I asked around for some > other machines to use for nightly builds. I got a couple of offers of a > login, > but I lacked the time to set up and maintain the nightly. > Thanks for the information here. It is good to have both an understanding of Debian's build machine policies, and a link to the current builds. A lack of fast enough hardware for these architectures is a challenge. The cross architecture build system that Debian has set up is impressive. For some of these architectures, cross-compiling with limited testing on the native architecture may be the only feasible option, but that requires extra build configuration. > The other hard truth is that having a nightly build is not enough. Each > architecture needs a champion who will investigate the failures, do extra > testing or develop patches. The ITK community won't do it on their own. > Even > with a nightly build submitted to cdash. > > I'm willing to help out with advice but I simply lack the time to do very > much > follow-up for non-mainstream architectures. Truthfully, I don't have much > time even for amd64 so more blood for Debian packaging would be welcome! > Yes! Thanks for your much appreciated work. Matt
Re: Debian builds of ITK for non-x84/amd64 architectures
- re-send with address for lists - Hi Dominique and Steve, > As Dominique mentioned, policy for the official build daemon machines forbids > network access from the build. So, a while back, I asked around for some > other machines to use for nightly builds. I got a couple of offers of a > login, > but I lacked the time to set up and maintain the nightly. Thanks for the information here. It is good to have both an understanding of Debian's build machine policies, and a link to the current builds. A lack of fast enough hardware for these architectures is a challenge. The cross architecture build system that Debian has set up is impressive. For some of these architectures, cross-compiling with limited testing on the native architecture may be the only feasible option, but that requires extra build configuration. > > The other hard truth is that having a nightly build is not enough. Each > architecture needs a champion who will investigate the failures, do extra > testing or develop patches. The ITK community won't do it on their own. Even > with a nightly build submitted to cdash. > > I'm willing to help out with advice but I simply lack the time to do very much > follow-up for non-mainstream architectures. Truthfully, I don't have much > time even for amd64 so more blood for Debian packaging would be welcome! Yes! Thanks for your much appreciated work. Matt On Wed, Nov 6, 2013 at 10:31 PM, Steve M. Robbins wrote: > Hello Matt, > > On November 6, 2013 05:43:37 PM Matt McCormick wrote: > >> Jean-Christophe noted this bug [1] at the CTK hackfest, which is >> blocking CTK for other architectures. Is it possible to get some of >> these architectures reporting nightly builds [2] to the ITK software >> quality dashboard [3], so they can be cleaned up? > > It's a great idea in principle for all the debian architectures to submit to > the ITK dashboard -- and now that we're down to just two, we do have full > coverage! :-) > > If we want better coverage, the hard truth is that we need more volunteers and > on a sustained basis. > > As Dominique mentioned, policy for the official build daemon machines forbids > network access from the build. So, a while back, I asked around for some > other machines to use for nightly builds. I got a couple of offers of a > login, > but I lacked the time to set up and maintain the nightly. > > The other hard truth is that having a nightly build is not enough. Each > architecture needs a champion who will investigate the failures, do extra > testing or develop patches. The ITK community won't do it on their own. Even > with a nightly build submitted to cdash. > > I'm willing to help out with advice but I simply lack the time to do very much > follow-up for non-mainstream architectures. Truthfully, I don't have much > time even for amd64 so more blood for Debian packaging would be welcome! > > Cheers, > -Steve -- 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/calztn-rbxvdgsj+es6ygrgxaq4qr1tss4tdir3v_inyjv9a...@mail.gmail.com
