Re: [RFS] blitz++ 1:1.0.2+ds-3
Hi Jerome, great, good to see blitz++ in good shape again :-) Best, Philip Am 30. Juli 2022 20:35:11 MESZ schrieb Jerome BENOIT : >Hello Philip, >I have just uploaded the package after minor modifications. > >In particular I merged the new patches into the d/debianization.patch . >And I added the magic line `include /usr/share/dpkg/pkg-info.mk' at the >beginning of the d/rules script: this inclusion may help reproducibility. >Furthermore the package is now maintained within Debian Math Team. > >On 26/07/2022 18:14, Philip Rinn wrote: >> Hi Jerome, >> >> on 24.07.22 at 21:10, Jerome BENOIT write: >>> Hello Again, I had a quick. It looks great. >>> I will upload by the next week-end because right now I am melting >>> (and this can generate a chain of mistakes). >> >> great, thanks! >> >>> Otherwise, have you try to process the texi with pdftex ? > >It is actually compose with pdftex . >Including the dpkg material in d/rules was the missing part of the story. > >> >> That doesn't seem to work, texi2pdf seems the only option to get that pdf - >> though, one could just drop the pdf as the html documentation in provided as >> well. >> >> Best, >> Philip > >Thanks for your work. >Jerome >
Re: [RFS] blitz++ 1:1.0.2+ds-3
Hi Jerome, on 24.07.22 at 21:10, Jerome BENOIT write: Hello Again, I had a quick. It looks great. I will upload by the next week-end because right now I am melting (and this can generate a chain of mistakes). great, thanks! Otherwise, have you try to process the texi with pdftex ? That doesn't seem to work, texi2pdf seems the only option to get that pdf - though, one could just drop the pdf as the html documentation in provided as well. Best, Philip OpenPGP_signature Description: OpenPGP digital signature
[RFS] blitz++ 1:1.0.2+ds-3
Hi,
my main goal was to make blitz++ reproducible - unfortunately that's not
(easily) possible at the moment, as texi2pdf introduces the absolute
path of included files into the resulting pdf :-/
Anyway, I guess it's good to get blitz++ in a better shape:
blitz++ (1:1.0.2+ds-3) unstable; urgency=medium
* Team upload
* debian/control:
- debhelper, bump to 13
- Standards Version, bump to 4.6.1 (no change)
- Mark libblitz0v5 and libblitz0-dev as 'Multi-Arch: same'
- Mark libblitz-doc as 'Multi-Arch: foreign'
- Add 'Rules-Requires-Root: no'
* Remove unused debian/source/include-binaries
* Make bzconfig.h reproducible:
- Remove -{file|debug}-prefix-map from BZ__compiler_options
- Add patch to use SOURCE_DATE_EPOCH in BZ__config_date (Closes:
#977001)
- Thanks Vagrant Cascadian for the patch
- Add patch to use DEB_HOST_MULTIARCH as BZ__os_name (Closes: ##977003)
- Thanks Vagrant Cascadian for the patch
-- Philip Rinn Wed, 20 Jul 2022 18:54:45 +0200
I could have pushed the changes to the repository directly but I thought
it was politer to do it via a MR:
https://salsa.debian.org/science-team/blitzxx/-/merge_requests/2
Could anyone of you please review and sponsor?
Thanks & best regards
Philip
OpenPGP_signature
Description: OpenPGP digital signature
Re: Debian Upstream Metadata and citation file format
Hi Andreas, > $ doi2cff init 10.1093/bioinformatics/btp347 you probably tried that but just to make sure - shouldn't it be $ doi2cff init https://doi.org/10.1093/bioinformatics/btp347 according to https://github.com/citation-file-format/doi2cff#usage ? Best regards, Philip
Re: State of shiny-server packaging
Hi Andreas, On Mon, Sep 17, 2018 at 20:49:47 +0200, Andreas Tille wrote: > On Mon, Sep 17, 2018 at 05:25:41PM +0200, Philip Rinn wrote: >> > Please do not RM existing stuff. If you want to get rid of that package >> > personally I can add myself as Uploaders and take over ownership of the >> > ITP/RFPs. I think the latter will be automagically turned into RFPs so >> > there is not really any work needed. >> >> Yes, please add yourself to Uploders of node-pinkyswear (and remove myself) > > Done in upload of node-pinkyswear_2.2.3+dfsg-2. Thanks. >> please take ownership of the ITP/RFP bugs. > >>From my point of view its sufficient if those bugs stay as they are and > someone who is informed about the status (for instance due to this > thread) that anybody is kindly invited to close that ITP. I do not feel > my time productively spent in maintaining these bug metadata and just > grab another RC bug meanwhile. Uh, I'm confused. Taking ownership of the ITP is what you said you'd do if I want (see just some lines above). Anyway, shiny-server-client[1] is ready for upload (modulo compat and standards bumps). Best, Philip [1] https://salsa.debian.org/science-team/node-shiny-server-client
Re: State of shiny-server packaging
Hi Andreas, On Mon, Sep 17, 2018 at 11:52:10 +0200, Andreas Tille wrote: > Hi Philip, > > On Sun, Sep 16, 2018 at 06:57:22PM +0200, Philip Rinn wrote: >> the packaging effort for shiny-server stalled some month ago. I totally lost >> interest in packaging it as I now use shinyproxy[1] at $work. > > There is interest remaining here (local users and I was asked by Debian > friends). > >> As we are heading towards the freeze, I think it's time to discuss how to >> proceed. >> Getting shiny-server into Debian is still a lot of work, see [2]. Actually >> only >> one out of 13 nodejs packages that need to be packaged hit the archive. > > Yes. > >> Is anyone willing to step in and finish the work? Andreas, are you still >> interested? > > I admit there are lots of existing packages with open RC bugs and I simply > have > not found the time to do anything in this direction. > >> If no one steps in until end of October I'll file a RM bug for >> node-pinkyswear and >> close the ITP/RFP bugs that are listed in [2]. > > Please do not RM existing stuff. If you want to get rid of that package > personally I can add myself as Uploaders and take over ownership of the > ITP/RFPs. I think the latter will be automagically turned into RFPs so > there is not really any work needed. Yes, please add yourself to Uploders of node-pinkyswear (and remove myself) and please take ownership of the ITP/RFP bugs. Thanks for taking care of shiny-server (and so many other packages)! Best, Philip >> [1] https://www.shinyproxy.io >> [2] https://salsa.debian.org/science-team/shiny-server/wikis/Packaging-ToDo signature.asc Description: OpenPGP digital signature
Re: State of shiny-server packaging
On 16.09.18 at 20:31, Dirk Eddelbuettel wrote: > [...] > Yes. Not everything that exists in open source land needs to be in Debian. > > Some things are simply hard to package. Just how Tobias et al bundled Shiny > in their (competing, but also both free-as-in-beer + commercially supported) > shinyproxy (which I do understand is awesome for larger deployments) so have To avoid misinterpretation, shinyproxy is Open Source, not just free-as-in-beer: https://github.com/openanalytics/shinyproxy But it's true, there are more alternatives to shiny-server than just shinyproxy which might be a little complex for smaller deployments. Best, Philip signature.asc Description: OpenPGP digital signature
State of shiny-server packaging
Hi, the packaging effort for shiny-server stalled some month ago. I totally lost interest in packaging it as I now use shinyproxy[1] at $work. As we are heading towards the freeze, I think it's time to discuss how to proceed. Getting shiny-server into Debian is still a lot of work, see [2]. Actually only one out of 13 nodejs packages that need to be packaged hit the archive. Is anyone willing to step in and finish the work? Andreas, are you still interested? If no one steps in until end of October I'll file a RM bug for node-pinkyswear and close the ITP/RFP bugs that are listed in [2]. Best, Philip [1] https://www.shinyproxy.io [2] https://salsa.debian.org/science-team/shiny-server/wikis/Packaging-ToDo signature.asc Description: OpenPGP digital signature
Re: Re: RFS: texmaker/5.0.2-2 [fixes RC bug]
Andreas Tille wrote: > I've uploaded to fix those RC bugs. However, we should do some effort > to get rid of the library code copies that come with pdfium. This can > be either done by striping the code from pdfium/third_party and patch > the build system or (even better) by packaging pdfium separately as > development package and link TeXMaker against this. Thanks for uploading! I did some bug triage meanwhile and could get the bug count down to 5 resp. 4 on Debian/Ubuntu. Unfortunately upstream only offers a mail contact (or am I missing something?) which makes forwarding bugs a little annoying. Regarding pdfium I think it should be coordinated with all packages embedding pdfium at the moment which are at least chromium-browser, firefox, qtwebengine-opensource-src and texmaker. Packaging it separately seems to be the best solution to me. > Any volunteer? Sorry, no. Best, Philip signature.asc Description: OpenPGP digital signature
Re: Re: RFS: texmaker/5.0.2-2 [fixes RC bug]
Dear Sébastien, On 04.05.2018 at 11:43, Sébastien Villemot wrote: > Dear Philipp, > > On Thu, May 03, 2018 at 06:13:49PM +0200, Philip Rinn wrote: > >> I was just hit by texmaker crashing on start and fixed it right away :-) >> >> Could someone with upload rights please review and upload? >> texmaker (5.0.2-2) unstable; urgency=medium >> >> * Team upload. >> * d/patches: fix crash with new libsynctex (fixes: #896656, #897071) >> + Add 60-fix-for-new-libsynctex1-API.patch to fix crash on startup >> * Update Vcs URLs in d/control to point to salsa.d.o >> >> -- Philip Rinn <ri...@inventati.org> Thu, 03 May 2018 17:36:23 +0200 > Shouldn't you also close #896567 ? sure, I missed this one fist but fixed the changelog entry after I sent the mail. Best, Philip signature.asc Description: OpenPGP digital signature
Re: RFS: texmaker/5.0.2-2 [fixes RC bug]
Hi Andreas, hi Julian, yesterday I was hit by an RC bug in texmaker wich hindered my work - so I fixed it and prepared a new upload (hope that's fine with you. Feel free to change that if you want). I sent a RFS to debian-schience@l.d.o yesterday but it never showed up in the web-archive - that's why I write to you directly now (and cc'ing the list) Would you review & sponsor (or do whatever you feel is appropriate to fix the RC bugs)? Best, Philip On 03.05.2018 at 18:13, Philip Rinn wrote: > Hi, > > I was just hit by texmaker crashing on start and fixed it right away :-) > > Could someone with upload rights please review and upload? > > Thanks > > Philip > > > https://salsa.debian.org/science-team/texmaker > > > texmaker (5.0.2-2) unstable; urgency=medium > > * Team upload. > * d/patches: fix crash with new libsynctex (fixes: #896656, #897071) > + Add 60-fix-for-new-libsynctex1-API.patch to fix crash on startup > * Update Vcs URLs in d/control to point to salsa.d.o > > -- Philip Rinn <ri...@inventati.org> Thu, 03 May 2018 17:36:23 +0200 > signature.asc Description: OpenPGP digital signature
RFS: texmaker/5.0.2-2 [fixes RC bug]
Hi, I was just hit by texmaker crashing on start and fixed it right away :-) Could someone with upload rights please review and upload? Thanks Philip https://salsa.debian.org/science-team/texmaker texmaker (5.0.2-2) unstable; urgency=medium * Team upload. * d/patches: fix crash with new libsynctex (fixes: #896656, #897071) + Add 60-fix-for-new-libsynctex1-API.patch to fix crash on startup * Update Vcs URLs in d/control to point to salsa.d.o -- Philip Rinn <ri...@inventati.org> Thu, 03 May 2018 17:36:23 +0200 signature.asc Description: OpenPGP digital signature
Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi Andreas, On 16.02.2018 at 12:04, Andreas Tille wrote: > On Fri, Feb 16, 2018 at 11:29:08AM +0100, Philip Rinn wrote: >> There is still a lot to do, especially coordinating with Debian JavaScript >> Maintainers to get most of the packages under their umbrella. Unfortunately >> one >> needs to be subscribed to post to their mailing list :-(. > > Please let me know if you need a sponsor for any of the packages or if > you even need help for packaging. Just let me know explicitly which one > you would prefer to be taken by somebody else to avoid duplicated > effort. to be honest, I'm not interested to be Uploader for all those node.js packages. I'd propose to file RFP bugs for - node-client-sessions - node-http-proxy - node-morgan - node-pause - node-rewire - node-sockjs - node-stable as they seem to be more widely used and I hope others will do the packaging. This would leave us with these three funny, 3 - 100 LoC, node.js modules - node-bash -> https://github.com/felixge/node-bash - node-regexp-quote -> https://github.com/dbrock/node-regexp-quote - node-unixgroups -> https://github.com/rstudio/node-unixgroups So, filing RFP bugs would help much, I'll take care of the three node.js modules left. Best, Philip signature.asc Description: OpenPGP digital signature
Re: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi, to keep track of what is still needed to be packaged for shiny-server I created a wiki page: https://salsa.debian.org/science-team/shiny-server/wikis/Packaging-ToDo There is still a lot to do, especially coordinating with Debian JavaScript Maintainers to get most of the packages under their umbrella. Unfortunately one needs to be subscribed to post to their mailing list :-(. Best, Philip BTW: If you don't want to use the gitlab interface to edit the wiki: git clone g...@salsa.debian.org:science-team/shiny-server.wiki.git
Re: Project creation in science-team (Was: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories))
Hi Andreas, On 05.02.2018 at 11:43, Andreas Tille wrote: >> The packaging is here (I'd like to move it to .../science-team/... before >> uploading) >> >> https://salsa.debian.org/rinni-guest/node-pinkyswear > > Could you please move to science-team first to make me evaluate the final > status of the package? Done: https://salsa.debian.org/science-team/node-pinkyswear [The remarks for debian/control hold here as well. But I'd prefer to not change it for this package as I still hope to get it under the javascript umbrella sometime.] >> And here it the packaging of node-shiny-server-client which should be in >> science-team anyway >> >> https://salsa.debian.org/science-team/node-shiny-server-client > > I've requested a release tag on Github[1]. This would help to create a > sensible watch file. Ah, that's a good idea! > Moreover some cosmetic remark: I'm very used to the cme file layout of > debian/control. You get it when using > > cme fix dpkg-control > > ... at least under normal conditions. Cme is not yet adapted to salsa > so it does not yet work with the current control file. I hacked around > this and commited the result. I do not insist in this form but in teams > with lots of contributors its nice to have some common layout to let > the packages look somehow "familiar" for sponsors. If you have strong > esthetic reasons to insist on your old formatting feel free to revert > my last commit. > > Both things are no reason to stop me from sponsoring. So if you confirm > that my last commit is fine for you I'll upload as it is now - otherwise > I'll upload your latest commit. For me it's OK. I tried to stick to the Node.js packaging template to make it easier for Noe.js people to review it. As this package will stay in science-team anyway I think using the cme file layout is fine. Thanks for the review! Philip
Re: Next python-mote pre-condition test issue: python-jsondiff trows ModuleNotFoundError: No module named 'nose_random'
Hi Andreas, The answer is hidden in https://salsa.debian.org/science-team/python-jsondiff/blob/master/dev-requirements.txt https://github.com/ZoomerAnalytics/nose-random Best, Philip
Project creation in science-team (Was: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories))
Hi, I packaged node-shiny-server-client (see ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887089). As the package seems to be only useful for shiny-server I think the best choice is to maintain it in Debian-science. As I'm not able to create a project in scince-team on salsa myself, could anyone please create the project node-shiny-server-client and give me (rinni-guest) "master" privileges? I'll send a RFS after all it's dependencies are in unstable. Thanks & happy hacking, Philip
Re: Help needed for licnse review (Was: r-cran-utf8_1.1.3-1_amd64.changes REJECTED)
> to upgrade r-cran-tibble this package is needed. I noticed that the code (see > Git[2]) contains a file > > src/utf8lite/LICENSE.Unicode > > with an extra license. However, I don't see to what files the license might > apply. My interpretation is that the license covers all files accessible from the URLs listed in the first three paragraphs of src/utf8lite/LICENSE.Unicode. One would need to check if any of those files is included in the source tree. If not, the license file is just pointless. Hope that helps, Philip
Re: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi, > Actually, packaging node modules is really easy. I recommend it for > people learning to package. The npm2deb does a lot of the hard work for you: > https://wiki.debian.org/Javascript/Nodejs Ah, good to know, I'll give it a try with node-shiny-server-client and report back how it worked. BTW: We could probably ask the Debian Javascript Maintainers if they are interested in team maintenance for the nodejs packages (except for node-shiny-server-client probably). Keeping them under the debian-science umbrella seems odd to me. Best, Philip
Re: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
On 12.012018 at 22:43:55, Phili Rinn wrote: > Yes, there are a lot of nodejs dependencies which seem not to be packaged > (didn't > check ITPs / RFPs): missed: node-bash Best, Philip
Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi, On 10.01.2018 at 14:40, Andreas Tille wrote: > Feel free to commit any changes you consider an enhancement! already did and the package builds now at least. > I would work down the list or r-cran-* packages step by step and than see how > complicated the actual shiny-server packaging is. As I said, I don't think there are any left (besides rmarkdown, which you are working on). > I vaguely remember the nodejs stuff was quite complex - specifically for me > since I have no idea about all this nodejs / JS stuff at all. Yes, there are a lot of nodejs dependencies which seem not to be packaged (didn't check ITPs / RFPs): node-client-sessions node-http-proxy node-morgan node-pause node-regexp-quote node-rewire node-shiny-server-client -> https://github.com/rstudio/shiny-server-client/ node-sockjs node-stable node-unixgroups -> https://github.com/rstudio/node-unixgroups/ I have absolutely no experience in packaging this stuff :-( Best, Philip
Re: Re: How to get some replacement for a commit list
Hi,
> We are now supposed to use the email notifications from GitLab ("Emails on
> push" under "Settings -> Integrations").
there is a script for this if you don't want to use the web interface (I didn't
test it though)
https://salsa.debian.org/mehdi/salsa-scripts/blob/master/emails_on_push.sh
Best,
Philip
Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi,
On 10.01.2018 at 14:40, Andreas Tille wrote:
> Some local manual installation of shiny-server installs the following not yet
> packaged R packages:
>
>r-cran-broom
>r-cran-bubbles
>r-cran-dbplyr
>r-cran-ggvis
>r-cran-highcharter
>r-cran-leaflet
>r-cran-mclust
>r-cran-psych
>r-cran-rlist
>r-cran-shinysignals
>r-cran-shinythemes
>r-cran-wordcloud
>r-cran-rmarkdown
>
> This list possibly needs to be worked down.
are you sure? grep'ing the source code for those packages ('broom', ... of
course)
only shows 'rmarkdown' occurring in the source.
I only see shiny, ggplot2, reshape2, devtools and rmarkdown being used when
grep'ing for 'library(', 'require(' and 'install.package'
> I had an *old*, *non-working* packaging attempt on my local disk. I now
> imported the latest upstream of shiny-server into this Git repository, did
> **not** yet any test build yet (so expect that the build will fail!) and
> commited it to
>
> https://salsa.debian.org/science-team/shiny-server.git
>
> Feel free to commit any changes you consider an enhancement! I would work
> down the list or r-cran-* packages step by step and than see how complicated
> the actual shiny-server packaging is. I vaguely remember the nodejs stuff
> was
> quite complex - specifically for me since I have no idea about all this
> nodejs
> / JS stuff at all.
OK, I'll have a look (unfortunately I don't have much time until beginning of
February).
Best,
Philip
Re: Help with libgit2 needed to strip code copy from r-cran-git2r
Hi, I looked into this as well this evening and didn't really understand what they are doing. Did you ask the upstream authors why they didn't just depend on libgit2 as they did for libssh2, OpenSSL, ...? It's probably easier to understand the problem with their help. [If you don't want to do that I can do...] Best, Philip
Re: Re: New GitLab-Salsa service and Debian-Science Team
Hi, > Hi David, > > On Thu, Dec 28, 2017 at 08:38:33AM -0400, David Bremner wrote: >> > I *really* hope that there will be a solution which does not need any >> > VCS-field replacement. I'm pretty bored by replacing VCS-fields every >> > third year (or so). >> >> I sympathize with your boredom (although that is really something >> doesn't need an upload by itself). My understanding is that the current >> plan is not have any alias for salsa, so some change will be needed. > > If there is no alias for salsa, we'll need an upload. Otherwise UDD > will feature wrong VCS URLs and all Blends pages become wrong. Its not > only that I'm bored but there are several services relying on that > information. My point is that I'm simply questioning the current plan. Now that this seems to be solved by: https://salsa.debian.org/salsa/AliothRewriter I added a file (definitions/debian-science.conf) to start the mapping, see my merge request: https://salsa.debian.org/salsa/AliothRewriter/merge_requests/10 Please add all the migrated repositories there. Hope that helps Philip
RFS: r-cran-scatterplot3d
Dear debian-science subscribers, I am looking for a sponsor for my package scatterplot3d. * Package name: scatterplot3d Version : 0.3-30-1 Upstream Author : Uwe Ligges * URL : http://cran.r-project.org/web/packages/scatterplot3d/ * License : GPL-2 Section : gnu-r Scatterplot3d is an GNU R package for the visualization of multivariate data in a three dimensional space. Basically scatterplot3d generates a scatter plot in the 3D space using a parallel projection. Higher dimensions (fourth, fifth, etc.) of the data can be visualized to some extent using, e.g. different colors, symbol types or symbol sizes. It builds the binary packages r-cran-scatterplot3d. I renamed it to fit the pattern of CRAN packages for R in Debian. The package appears to be lintian clean and it would fix bug #565682. It can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/s/scatterplot3d I'd be glad if someone could upload this package for me, as it would supplement the collection of CRAN packages in Debian especially for 3D plotting. Kind regards Philip Rinn PS: would you please CC me, as I'm not on the list. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: r-cran-scatterplot3d
On 24.01.2010 19:10, Dirk Eddelbuettel wrote: On 24 January 2010 at 18:24, Philip Rinn wrote: | Dear debian-science subscribers, | | I am looking for a sponsor for my package scatterplot3d. | | * Package name: scatterplot3d | Version : 0.3-30-1 | Upstream Author : Uwe Ligges | * URL : http://cran.r-project.org/web/packages/scatterplot3d/ | * License : GPL-2 | Section : gnu-r | | Scatterplot3d is an GNU R package for the visualization of multivariate data in | a three dimensional space. Basically scatterplot3d generates a scatter plot in | the 3D space using a parallel projection. Higher dimensions (fourth, fifth, etc.) | of the data can be visualized to some extent using, e.g. different colors, | symbol types or symbol sizes. | | | It builds the binary packages r-cran-scatterplot3d. I renamed it to fit the | pattern of CRAN packages for R in Debian. | | The package appears to be lintian clean and it would fix bug #565682. | It can be found on mentors.debian.net: | http://mentors.debian.net/debian/pool/main/s/scatterplot3d Building CRAN packages is trivial, it usually takes me about five minutes max per package. Yet I am not convinced that is what we want to sponsor more as some folks who have sponsored / packaged / uploaded are not keeping up with the new versions at CRAN (I think that holds for matchit, pscl, sp, vgam, zelig per [1] and other pages). I try to keep up with mine, and it really is not a large effort. Yet someone has to make it for the sponsored / team-managed packages too. I'm not sure if I got your point. Should I just have filed an RFP bug because maintaining CRAN packages is so easy and it's not worth getting new people involved? Or do you think we shouldn't have random CRAN packages in Debian? | | I'd be glad if someone could upload this package for me, as it would supplement | the collection of CRAN packages in Debian especially for 3D plotting. Are you aware of http://debian.cran.r-project.org which gets you 2000+ CRAN packages as deb files for testing on i386 and amd64 ? That is an automated process not suitable for injection into Debian proper, but one that could be extended to other arches etc given suitable hardware donations. Nice to know. I wasn't aware of it, but I have ppc at work. Philip Dirk [1] http://qa.debian.org/developer.php?login=debian-science-maintain...@lists.alioth.debian.org | | Kind regards | Philip Rinn | | PS: would you please CC me, as I'm not on the list. | | | -- | To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org | with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org | -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
