Re: MRs on salsa and letting janitor automate things
Hi Andreas I admit I share the old fashioned view and we asket Jelmer to not run Janitor on Debian Med and R-pkg-team. The rationale is that we are running routine-update on all our packages. Routine-update is running all scripts that are called by Janitor and thus you have the same effect. It's not quite the same effect. While there is a substantial overlap in the feature sets, one is not a subset of the other. - routine-update does some great things like normalising packaging. That's something Janitor can't do because people would scream about an automated tool touching their precious whitespace. - Janitor applies multi-arch hints, and looks at obsolete versioned dependencies — these are things that routine-update can't do because it doesn't have a holistic view of the archive. Janitor is also run automatically rather than only when the maintainer is seeking to update the package, meaning that improvements can accrue over time. Janitor updates also cause CI to be run, meaning that regressions such as a FTBFS caused by other packages changing get spotted earlier. I don't see any reason to say that tools are mutually exclusive — let's let Janitor make improvements and when packages need updating, we can have routine-update make some more? regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
On 28/11/2022 18:22, Nilesh Patra wrote: On Mon, Nov 28, 2022 at 05:45:02PM +1100, Stuart Prescott wrote: On 28/11/2022 10:55, Dima Kogan wrote: Hi. I've been manually checking the merge requests, and have been accepting most of them. There is one thing the janitor does that I don't agree with, and I'd be against any automated merging of those patches. This is adding Build-Depends: debhelper-compat (=WHATEVER). Such dependencies break building of the package on anything other than sid, and are thus unhelpful. If you can stop the janitor from making this change, that'd probably be good. Can you expand on this a bit? There are plenty of packages with B-D on debhelper-compat (= 13) that are backported to the current stable and oldstable releases without any changes. I _suppose_ this is their use-case: https://lists.debian.org/debian-devel/2022/07/msg00304.html I short, Dima maintains apt repos for packages that are used in many distributions and setting compat as 13 or whatever breaks the build for them. Sounds like throwing a backport of debhelper into the local repos for backports would be a good idea too. It's a trivially backportable package which then lets everything else backport more easily. (Dima, please let me know if I can help with that) Thanks for the extra context, Nilesh! cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
Hi Dima On 28/11/2022 10:55, Dima Kogan wrote: Hi. I've been manually checking the merge requests, and have been accepting most of them. There is one thing the janitor does that I don't agree with, and I'd be against any automated merging of those patches. This is adding Build-Depends: debhelper-compat (=WHATEVER). Such dependencies break building of the package on anything other than sid, and are thus unhelpful. If you can stop the janitor from making this change, that'd probably be good. Can you expand on this a bit? There are plenty of packages with B-D on debhelper-compat (= 13) that are backported to the current stable and oldstable releases without any changes. I'm not sure how using debhelper-compat (= X) is any worse than debhelper (> X) + debian/compat=X — in terms of backporting, they all require that the relevant version of debhelper is in the release that you're targetting. The value of the compat level can certainly make a difference to backporting, since you need that version of debhelper in the release or in backports. But with debhelper 12 in oldoldstable-backports and debhelper 13 in oldstable-backports and stable/stable-backports, that's not really a restriction, is it? (likewise in supported ubuntu releases) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
Hi David On 27/11/2022 23:29, David Bremner wrote: Personally I often find it hard to prioritize understanding the MRs from the janitor, and I'm not comfortable with having a bot commit to a repo that I am responsible for. Perhaps I'm just old fashioned. I'm an uploader only for a tiny fraction of the team's packages, so my views should not block anything. A few years ago when Janitor was new, I felt the same uneasiness about letting it commit things. I've since changed my view for a few reasons: * Nothing gets uploaded without human eyes looking at it anyway * It's git, so you can you just revert anything that is a problem, should that actually be the case in reality (and having processed many hundreds of Janitor merges, I am yet to see any that were); and the issues I speculated about at first with this have turned out to be imagined rather than real * Janitor's ability to edit files without reformatting them has improved and so its changes are small, targeted, and easily readable * its commits are small and simple — the vast majority of the commits I just merged from Janitor were (a) fixing whitespace errors, (b) removing obsolete and unneeded version constraints, (c) adding simple multi-arch headers. These are all nice to have, safe, and simple. * Janitor has been a member of some big Debian teams for a couple of years and has been successful in those teams — Janitor has been committing directly to git repos in both the Perl and Python teams for around two years. > I guess I can always pull a few packages from > the team space on Salsa. That is quite contrary to what both Janitor and I are hoping to do here. The point is to enhance the team and to remove the boring work. Given Janitor has been committing directly to Perl repos that you are responsible for already, perhaps this isn't as much of a change as feared? cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
On 27/11/2022 19:30, Julien Puydt wrote: Perhaps people didn't get notified they had MRs ? Entirely possible, hence the suggestions in my message were that we should: a) automate what can be automated so that attention is not needed b) check our individual salsa notification settings for repos we care about c) check the dd-list of outstanding MRs Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
MRs on salsa and letting janitor automate things
Hi folks tl;dr: there lots of untriaged MRs on salsa; let's permit Janitor to automatically commit its updates There are lots of MRs on salsa for science-team packages that are open. Many of these have been open for months and many have no comments, triage or feedback visible on salsa. Many of these have been made by first time contributors who, by virtue of their MRs sitting unacknowledged and unmerged for months, think we don't care. That's not our intended message! Attached are: * a list of MRs that are currently open on salsa (sorted by package) * associated dd-list of maintainers/uploaders for these packages If you don't currently get notified about MRs being opened for packages you are interested in, I encourage you to tweak your salsa notification preferences. My approach to this is to "star" packages for which I am maintainer, uploader, or otherwise interested enough in that I'd like to see notifications for MRs. In amongst the human-generated MRs, there was also a huge number of automated MRs from the Janitor bot. Over the last couple of days I've been through Janitor's MRs (about 200 of them). These are all really simple changes, each of which I checked and almost all of them I have merged. For those not familiar with Janitor, it looks for easy to fix issues in the packaging that are flagged by lintian (or other similar tools) and fixes them. Unlike lintian, it has internet access and knowledge of the Debian archive, so it can do extra things like update upstream homepages or remove obsolete version constraints on packages. Janitor's fixes range from pedantic to very useful; even the more pedantic ones steadily improve the signal:noise of lintian and so lintian becomes more useful on those packages. https://janitor.debian.net/ I propose that we let Janitor make these commits directly rather than opening MRs; quite a few other teams in Debian have done this and it is working well. Janitor has proven itself to be reliable and useful. Since we've now been able to see that Janitor's changes are OK for a few years, we can safely cut out the manual work and just let the bot get on with its work. Comments? regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7Alastair McKinstry cylc libdap paraview (U) qd (U) Andreas Tille python-jsondiff (U) virtuoso-opensource (U) Ansgar dune-pdelab (U) Anton Gladky freeimage (U) libqglviewer (U) solvespace (U) vtk9 (U) Balint Reczey irstlm (U) Debian QA Group bcolz Debian Science Maintainers armadillo bornagain calculix-ccx-doc dune-pdelab freeimage hepmc3 irstlm libqglviewer python-jsondiff python-meshplex qd siconos solvespace tango virtuoso-opensource xtensor Debian Science Team gftl-shared paraview vtk9 Drew Parsons python-meshplex (U) xtensor (U) Gert Wollny vtk9 (U) Ghislain Antony Vaillant freeimage (U) Giulio Paci irstlm (U) HepMC developers hepmc3 (U) Koichi Akabe irstlm (U) Kumar Appaiah armadillo (U) Mika Pflüger bornagain (U) Mo Zhou hepmc3 (U) Nico Schlömer vtk9 (U) Ole Streicher gftl-shared (U) Picca Frédéric-Emmanuel bornagain (U) tango (U) Sebastien Delafond bornagain (U) Stephen Sinclair siconos (U) whitequark solvespace (U) Will Daniels virtuoso-opensource (U) Wolfgang Fütterer calculix-ccx-doc (U) science-team/armadillo Id: 26203 Title: Install cmake package and pkgconfig files. Closes #954927 Author: lasall Status: cannot_be_merged_recheck Url: https://salsa.debian.org/science-team/armadillo/-/merge_requests/1 science-team/aweather Id: 8074 Title: fix libgps API change (Closes: #926534) Author: paelzer-guest Status: can_be_merged Url: https://salsa.debian.org/science-team/aweather/-/merge_requests/1 science-team/bcolz Id: 48290 Title: Import Debian changes 1.2.1+ds2-8 Author: byang Status: can_be_merged Url: https://salsa.debian.org/science-team/bcolz/-/merge_requests/3 Id: 48289 Title: Import Debian changes 1.2.1+ds2-7 Author: byang Status: can_be_merged Url: https://salsa.debian.org/science-team/bcolz/-/merge_requests/2 science-team/bibus Id: 5149 Title: Fix #707338 Author: jscott Status: can_be_merged Url: https://salsa.debian.org/science-team/bibus/-/merge_requests/1 science-team/bornagain Id: 48297 Title: Update watch file Author: mikapfl-guest Status: can_be_merged Url: https://salsa.debian.org/science-team/bornagain/-/merge_requests/1 science-team/calculix-ccx-doc Id: 43365 Title: pristine-tar data for calculix-ccx-doc_2.17.orig.tar.bz2 Author: linqigang Status: can_be_merged Url: https://salsa.debian.org/science-team/calculix-ccx-doc/-/merge_requests/4 Id: 43352 Title: Updates to deb
Re: Science Subgroups [was Re: Debian Math Team]
Hi folks From this discussion it seems that the main advantages of separate teams are - bespoke views of packages via tracker/dppo/udd - mailing lists where the signal:noise is higher (if you're lucky) However, the disadvantages of separate teams are - differing conventions in each team around VCS layout, interactions etc - niceties around team upload vs NMU reduces the number of people who feel able to help with the packages - fewer people looking at packages across the inevitably-smaller teams Separate teams are optimised for the "main" maintainer of a handful of packages who doesn't routinely work on any other packages; they are optimised _against_ bugsquashers, generalists or people trying to land big projects across large sets of packages. These are some of the biggest annoyances of package maintenance in Debian and are what make it very hard to produce a good quality distribution. Collectively, we need to make big changes on a regular basis (GCC bumps, large transitions, Python 2 removal, ...) and for each of them we need people to be able to work on lots of packages with minimal friction. In the recent Python 2 removal work, for instance, it was easy for me to work on debian-science packages as I've been a team member since the dawn of time. Working with packages in the smaller teams was *much* more work involving additional git dances, MRs or BTS round-trips. There were also fewer people looking at those packages and it was more likely that there was lots of outstanding QA work, unpackaged upstream versions and packages effectively maintained by NMU. We should remember that having blends packages, blends web pages and informative wiki pages are completely independent of having a defined team with separate VCS and mailing list. All that needs is one or more people to curate them. On Tuesday, 2 November 2021 20:55:47 AEDT Timo Röhling wrote: [...] > As one of the "instigators" of the new Debian Robotics Team, I like > this idea very much and we will adopt it, too. That's excellent news :) > Jochen and I also discussed that we would like to consider the > Robotics Team more of a subgroup of the Science Team rather than a > completely independent team. I think that's an excellent idea! > Maybe this concept might also work for the Math Team and other > science-related groups? Yes please! I believe that we should think of this as good practice for maintenance of scientific software in Debian and that we should encourage all the other science-related teams to do this. Scientific software in Debian has a bit of a reputation problem that stems from many different causes that include upstream motivations, the vagaries of research funding, non-expert development work… but also because we are spread too thinly in Debian maintenance and many of our teams are nothing more than a VCS namespace and not actual teams. Making subgroups with a common way of working (i.e. policy) and having more permissive salsa configurations could help us a lot. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework
Hi Daniele I've not looked carefully at this package at all, but this one stood out: >librobottestingframework-python2 - Robot Testing Framework - > RTF_python library Now is not the time to be introducing things that depend on Python 2, given that Python 2 is almost completely removed from the next release of Debian. Can this package support Python 3 instead? If not, can the Python 2 bindings be omitted? (Perhaps upstream would like some help in porting the code to Python 3?) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: unanswered merge requests
On Saturday, 7 March 2020 08:19:02 AEDT Rebecca N. Palmer wrote: > Andreas Tille wrote: > > I was just > > astonished about the long list of unattended merge requests in Debian > > Science team. I wonder whether we should somehow prevent people from > > dumping code there which will simply bitrot since nobody realy cares. > > Salsa allows users to request notifications of merge requests [0], or > project admins to disable merge requests [1]. > > This was previously discussed on d-d - Sam Hartman wrote (as part of a > > list of recommended-but-not-required practices) [2]: > > You should make sure that at least one person sets their notification > > level to 'watch' rather than global. This way you will receive > > notifications of merge requests and changes. > > > > Hopefully you will choose to monitor merge requests for your > > repository. If not, turn off merge requests. If you enable merge > > requests, you should be as responsive to merge requests as you are > > patches in the BTS. Our problem is packages that are sitting within teams pretending to be maintained, that are actually unmaintained. Unactioned MRs on salsa are a symptom of that just like untriaged bugs in the BTS or unpackaged upstream versions. Patches bitrot in the BTS just as fast as they bitrot in an MR. I would very much hope that we do not turn of merge requests on salsa. Doing so would just mean that we go from: having unmaintained packages where others willing to help fix a bug can make MRs to having unmaintained packages where people interested in helping out occasionally cannot make MRs … which is not an improvement. We need a little more of a spring clean through packages within some of our teams. Working towards the Python 2 removal has highlighted quite a lot packages where we have a problem. A starting point could be to look at packages that have only had Team Uploads and not maintainer/uploader uploads in the last x years or in the last y release cycles. Perhaps those packages are actually orphaned packages and we should treat them as such. We could get those data from UDD if there isn't already a PET-like interface that is exposing that info. regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#949126: RFP: xraylarch -- X-ray absorption, fluorescence spectroscopy and diffraction data analysis
Package: wnpp Severity: wishlist * Package name: xraylarch Version : 0.9.46 Upstream Author : Matthew Newville, The University of Chicago * URL : http://xraypy.github.io/xraylarch/ * License : BSD-2-clause Programming Lang: Python Description : X-ray absorption, fluorescence spectroscopy and diffraction data analysis Larch is a library and set of applications for processing and analyzing X-ray absorption and fluorescence spectroscopy data and X-ray fluorescence and diffraction image data from synchrotron beamlines. It is especially focussed on X-ray absorption fine-structure spectroscopy (XAFS) including X-ray absorption near-edge spectroscopy (XANES) and extended X-ray absorption fine-structure spectroscopy (EXAFS). It also supports visualization and analysis tools for X-ray fluorescence (XRF) spectra and XRF and X-ray diffraction (XRD) images as collected at scanning X-ray microprobe beamlines. This package replaces the iffeffit and horae applications.
Re: Need review of my package
Hi Cyril > Many thanks for pointing me out my errors. > However, the language used by "watch file" is very obscur to me. yes, it's almost like you need to know what uscan's perl is going to do with it. I'd love to see a simple deb822-style replacement of that syntax. > version=4 > opts=uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/, > \ > filenamemangle=s/.*\/archive\/(\d\S+)\/@PACKAGE@.*\.tar\.gz/@PACKAGE@-$1\.t > ar\.gz/g \ https://gitlab.com/lock042/spview/tags?sort=updated_desc > .*/archive/(\d\S+)/.*\.tar\.gz.* this second entry looks right if you add a 'v' before the version in the last line. 'uscan --debug' tells me that the files for download for the tags appear to be: https://gitlab.com/lock042/spview/-/archive/v2.0.0-beta1/spview-v2.0.0-beta1.tar.gz but that regular expression doesn't have the 'v' just before the version string in the directory. This is because the tags there contain the 'v' -- some git repos do that while others do not. (You'll see on the wiki that some people like to use "v?" in their regexp as an optional letter v before the tag to try to help this) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Need review of my package
Hi, > I: spview source: debian-watch-contains-dh_make-template (line 2) > N: > N: The watch file contains a standard template included by dh_make. Please > N: remove them once you have implemented the watch file. > N: > N: Severity: wishlist, Certainty: certain > N: > N: Check: debian/watch, Type: source > N: > > I don't understand why the watch file depends of dh_make in this case. The string "" needs to be updated to point to the actual name of the project; it's there as a template for you to complete, not as a token that uscan will automatically replace for you: version=4 opts=filenamemangle=s/.*\/archive\/(\d\S+)\/.*\.tar\.gz/- $1\.tar\.gz/g \ https://gitlab.com/lock042/spview/tags?sort=updated_desc .*/archive/ (\d\S+)/.*\.tar\.gz.* (This token often comes from a maintainer having started off with dh-make which is why lintian is talking about that tool; however, you could also end up copying strings like from the wiki. It might be worth reporting a bug against lintian to consider that this boilerplate could come from places other than dh-make and that pointing to dh-make is potentially confusing.) There are some replaceable tokens you can use in d/watch -- they are of the form @PACKAGE@ (see uscan(1)). The watch file also doesn't currently work btw, as you've not taught uscan how to turn the Debianish version 2.0.0~beta1 into the gitlabish version 2.0.0- beta1 (~ vs -). You could add a versionmangle to handle that, similar to what is on the wiki for that purpose. https://wiki.debian.org/debian/watch#Common_mistakes uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/ You can test your watch file with $ uscan --no-download --verbose (adding --debug for additional info, including all the HTML that it tried to parse) Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Need review of my package
Hi! As a first step, do you run lintian in a verbose mode (--info) or do you use lintian-info? Just in case you didn't know, lintian often has a really good explanation of the tag, some references for more reading and often info about how to fix the problem too. > P: spview source: rules-requires-root-missing $ lintian-info -t rules-requires-root-missing P: rules-requires-root-missing N: N: The debian/control file is missing an explicit Rules-Requires-Root N: field. N: N: Traditionally, Debian packages have required root privileges for some N: debian/rules target requiring a split between build and binary N: targets. This makes the builds slower due to the increased amount of N: invocations as well as the overhead of fakeroot itself. N: N: Please specify (eg.) Rules-Requires-Root: no in the debian/control N: source stanza, but packagers should verify using diffoscope(1) that N: the binaries built with this field present are identical. N: N: Refer to /usr/share/doc/dpkg-dev/rootless-builds.txt.gz, Debian Policy N: Manual section 4.9.2 (debian/rules and Rules-Requires-Root), and N: Debian Policy Manual section 5.6.31 (Rules-Requires-Root) for details. N: N: Severity: pedantic, Certainty: certain N: N: Check: debian/control, Type: source N: Very few packages actually need to be built as root (or even with fakeroot) so adding "Rules-Requires-Root: no" to the first stanza of debian/control tells the build system not to do this. Building is (slightly) faster in this mode and not building as root can actually make some test suites work better. > W: spview source: inconsistent-appstream-metadata-license > debian/spview.appdata.xml (cc0-1.0 != gpl-3+) This is about comparing metadata_license (which is the licence for the spview.appdata.xml file) and what the package says in debian/copyright about spview.appdata.xml. If you look at the debian/copyright in the package, it is asserting that the appstream file is GPL-3+ (by virtual of the Files: * paragraph). It's normal for the appstream data to be CC0 and documenting that in debian/copyright is the consequence. > I: spview source: testsuite-autopkgtest-missing BTW if you can add something that is at least a smoke test of the jar then that would be great (something that fails due to the manifest as you write below, for instance!). Even better if the application has a test suite that can be run against the installed jar. > Then, after all these things, it appears that my app does not work. After > installation I have: no main manifest attribute, in > /usr/share/java/spview.jar How does the user execute the jar? If you've got a wrapper script then you can call the explicit class name that should be instantiated from the jar. I can't spot anything wrong in your d/rules but then my java building skills have not kept up with the plethora of build system out there for java the debian- java mailing list or #debian-java on irc.debian.org / irc.oftc.net might be a better place to ask. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Orphaning some Debian-Science packages
Hi Anton Thanks for reminding everyone of this clean-up effort > - nexus this looks like something that I use so I guess I should put my hand up for it. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: New version of statsmodels is out possibly fixing important bug - any volunteer
Hi Andreas, > Currently the package in Git does not build due to #921779. I admit I > have no idea why #917754 occures but my comparison with python-cycler > (which is able to find the module named > 'matplotlib.sphinxext.only_directives') Gave me some hope that switching > back from python3-sphinx to python-sphinx will solve this. matplotlib.sphinxext.only_directives was removed from matplotlib but you should be fairly easily able to fix up the documentation build, for example: https://sources.debian.org/src/python-periodictable/sid/debian/patches/sphinx-only-directive.patch/ cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: running CI tests before package sponsorship
Hi Steve, You can run the test suite yourself on your local machine with either autopkgtest (using a chroot/schroot/pbuilder/vm/etc) or without isolation using sadt from devscripts. Running the tests yourself only tests against the hardware you have available and so isn't probing different architectures, but then ci.debian.net doesn't either. It is possible to build and run tests from gitlab CI. You can write your own code for that or see an existing project for it: https://salsa.debian.org/salsa-ci-team/pipeline (I'm not sure I like the way it has been implemented in that project but it's an option for you) Gitlab CI is still not probing many architectures. Established maintainers can get access to porterboxes with various architectures to do their own testing and debugging on different hardware. I don't know whether that's going to be an option for you, however. To the source of your problem -- what sort of comparisons are you having trouble with? It's generally best that numerical tests use some sort of "almost equals" test probing only an acceptable number of significant figures; that should then pass on all architectures. Would it help to point to the specific code at this stage? Cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: New GitLab-Salsa service and Debian-Science Team
On Monday, 8 January 2018 09:30:10 AEDT Sébastien Villemot wrote: > On Mon, Jan 08, 2018 at 06:48:56PM +1100, Stuart Prescott wrote: > > Are you also thinking to change the canonical URLs for git repos in the > > policy to point at salsa rather than anonscm? Let's not just yet. It > > seems premature to assume that the salsa name will be canonical rather > > than an implementation detail of the day; anonscm was, after all, > > supposed to be something that stayed with us to save us having to change > > 24k source packages. It's also not clear that the AliothRewriter is a > > permanent solution. (Perhaps Cool URLs Do Change.) > > It has been made clear by the Alioth/Salsa admins that anonscm.d.o is > deprecated and that the new canonical URL is salsa.d.o. See the > documentation for the anonscm URL rewriter: > > https://salsa.debian.org/salsa/AliothRewriter/blob/master/README.md > > “The existence of this list should not mean that VCS control fields > shouldn't get updated with the next upload. This map is just a workaround.” *sigh* Given that only half of the packages in the archive get uploaded in any given release cycle, the proposal is to needlessly upload the other half. Sounds like fun. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: New GitLab-Salsa service and Debian-Science Team
For this configuration > * Update the URL to salsa: > > git remote set-url origin > > https://salsa.debian.org/science-team/MYPACKAGE > >* Check the new URL: > > git remote -v > > origin g...@salsa.debian.org:science-team/MYPACKAGE.git (fetch) > origin g...@salsa.debian.org:science-team/MYPACKAGE.git (fetch) (I wonder why there's no protocol in that output?) Pushing to the https remote as specified above didn't work for me, only fetching. Adding the following to ~/.gitconfig fixes that: [url "git+ssh://salsa.debian.org/"] pushInsteadOf = https://salsa.debian.org > The next step is to update the Debian Policy. It needs to be refreshed > anyway. I will try to import it into the salsa and propose changes to > the text. Instructions for creating new repos clearly need to be updated (perhaps there could be a little tool that creates the repo, adds appropriate webhooks using some ~/.salsa_private_token?) It would be great if a coordinated effort on that could be made rather than ad hoc curl commands each time for each team. Are you also thinking to change the canonical URLs for git repos in the policy to point at salsa rather than anonscm? Let's not just yet. It seems premature to assume that the salsa name will be canonical rather than an implementation detail of the day; anonscm was, after all, supposed to be something that stayed with us to save us having to change 24k source packages. It's also not clear that the AliothRewriter is a permanent solution. (Perhaps Cool URLs Do Change.) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Python 3 Statsmodels & Pandas
Hi Diane, On Sunday, 17 September 2017 22:14:18 AEST Diane Trout wrote: > I just did it that way because it was the least disruptive change I > could make that would let me build and test the package. Sure, that's entirely sensible. > In my experience I'm much more likely to to notice a build time test > failure than one from the CI system. Absolutely agreed. I'm thinking that this is a rather exceptional situation because of the circular dependency and the fall-out that we regularly see from that. > What do other people think? If there are autopkgtests, should you still > let dh_auto_test run tests? (I know I'm not the 'other people' from whom you solicit replies, I was just perhaps unclear in what I was musing on before so I want to be more clear now) Like you, I would *normally* run all tests in both places: buildd tests catch severe problems right now; ci.d.n reruns the tests each time new versions of dependencies are uploaded too and later breakage is caught. Perhaps this is not a normal situation, however. Either one of "circular dependencies" or "packages that often FTBFS on one or more architectures" would be unusual enough to justify doing something different. All I am wondering (from my position of ignorance!) if in this case, perhaps the tests that cause the circular dependency can be disabled or xfailed, with the remaining tests run as normal. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Python 3 Statsmodels & Pandas
Hi Diane & other science+python people, Thanks for spending time on pandas and statsmodels. They are two very valuable but very painful packages to work on. I've not looked at pandas and statsmodels packages carefully beyond "why hasn't pandas migrated this time!?" investigations but the circular relationship between pandas and statsmodels and its associated problems has come up several times before. It seems to be an on-going point of pain that sucks in quite a lot of developer time. On Saturday, 16 September 2017 14:18:10 AEST Diane Trout wrote: > My solution was to use build-profiles to flag the test dependency with > !nocheck this is, of course, a very elegant solution and exactly what build profiles are for... I wonder though, is it really sustainable given this problem keeps coming up? For the maintainer upload, you can do this bootstrapping with build profiles. For other archs, however, I don't believe we can tell the buildd to use build profiles so we'd need it to built by hand on porter boxes for every arch and then uploaded. Is it feaible to completely break this circular dependency? If it is only needed for tests, would be possible to disable the build-time tests and rely on the tests run on ci.d.n instead? If it's used for generating documentation too, then would creating a separate source package for the documentation that build-depends on statsmodels and pandas be possible such that there is now no circular dependency? (thinking aloud) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: dpkg-buildflags bindnow
Hi Jonathon, > one proposed solution[1] is to add > > $(shell dpkg-buildflags --get LDFLAGS) > > to the LDFLAGS > > however, dpkg-buildflags does *not* add flags for bindnow by default[2], > and the system needs additional configuration to add these. Buried elsewhere on the wiki page is that you also need to enable additional hardening options for dpkg-buildflags to include bindnow. For lots of common build systems, dh will actually already include dpkg-buildflags --get LDFLAGS for you, the trick is to tell dpkg-buildflags to include yet more. Often, this is sufficient: export DEB_BUILD_MAINT_OPTIONS = hardening=+all Sometimes, though, the upstream build system resets the flags and so a little additional fiddling is required, patching Makefiles etc until it behaves better. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: RFP: levmar -- Levenberg-Marquardt nonlinear least squares algorithms in C/C++
Hi all, On Tue, 8 Oct 2013 05:56:14 Teemu Ikonen wrote: [...] All included code is from an older version than the latest levmar-2.6, so making levmar useful in Debian would require a considerable amount of forward porting and fixing of upstream sources. On the other hand, having the same code in six source packages is already a pretty bad case of duplication. When I looked at levmar a few years ago I had the distinct impression that its authors really wanted it to be statically linked. The result of that is the multitude of different (patched) versions of levmar that you see embedded in different projects. There's a lot of work to do to convince the upstreams of freemat, hugin, meshlab, sextractor, starlink-ast, stimfit and teem that they want to work with a non-patched and up-to-date levmar instead of just continuing with their own versions. Levmar upstream does have some support for building a shared object but I didn't feel confident that sovers would be properly managed and I didn't want to take on that responsibility myself which is why I abandoned my previous efforts with levmar too. (just an added data point for anyone thinking of taking up packaging levmar) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201310081034.54192.stu...@debian.org
Opening SigmaPlot files (.jnb)
Hi all, In the past we've discussed at length various different packages with which to plot data for publication. As a result of such discussions, I even ended up maintaining a couple of these packages in Debian... This time, I'm not looking for alternatives for plotting things but for a way of opening SigmaPlot files. I'm in the classic non-free software trap where I've been suckered in and am now trapped [1]: * I have with a set of data files that students and colleagues have prepared for me * They used the software that was preinstalled on their department-issued machines, meaning that I have lots of files in SigmaPlot as that was site- licensed at the time. * As soon as the site licence is no longer available (because you no longer renew it or because you no longer work at that institution), you can't use SigmaPlot. So... do we have any utility (in Debian or more widely in the free software ecosystem) that can open these .jnb files from SigmaPlot [2]? The ideal situation would be where I can import the entire notebook (data, calculated sets and then plots) into something [3], but would be happy to accept just being able to extract the data as columns in order to be able to plot it again using my graphics utility of choice. thanks in advance Stuart [1] Yes this is *exactly* the classic non-free software trap. You'd think I'd know better than to end up here... [2] JNB files are a notebook format of some description that contains sheets of data and pages of plots. The file format change incompatibly at SigmaPlot version 9ish (iirc); I have the newer format files. Magic information isn't very useful. $ file -k redacted.JNB redacted.JNB: Composite Document File V2 Document, Little Endian, Os 0, Version: 5.1, Title: Notebook, corrupt: Can't expand summary_info [3] I know packages like scidavis/qtiplot can open origin project files like this. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201307110206.48960.stu...@debian.org
Re: Code aster changelog
Dear Andrea, A quick note about python dependencies: I would be nice also if you could detail the reason behind: Builds only against python2.6 To summarize, ATM there are issues (still uninvestigated) when building with 2.7, so we agreed to make it build only against 2.6 to have a working package forn now, and work to fix this issue later. Maybe a line like builds only against python2.6 due to unresolved issues with python2.7 is better? python 2.6 will be removed from unstable as soon as we can after 2.7 is default (in the words of one of the python maintainers). This is likely to be done on the few weeks timescale rather than few months (although these sorts of python transitions do have a habit of taking a bit longer than everyone plans). Adding another thing that requires python 2.6 won't help this process; it might not necessarily hinder it either, but then you'd get an RC- buggy package straight away. Perhaps spending the time to work out what's wrong with the package under python 2.7 prior to upload would be better. The guys in #debian-python on irc.oftc.net (irc.debian.org) don't bite :) cheers Stuart -- Stuart Prescott--www.nanonanonano.net -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106081438.45993.stuart+lists-expires2...@nanonanonano.net
Re: r-cran-maptools_0.7.16-1_i386.changes REJECTED (fwd)
Hi Julia, A quick note that the public-use permission for the sample data files on our site (http://geodacenter.asu.edu/sdata) haven't changed and we don't intend to change them in the future. Thanks for your clarification -- perhaps you could answer a couple more questions about these data sets for me (as an interested observer to this discussion): It is obviously intended that I could download these datasets to work through the tutorials given on your site. Am I allowed to download the datasets and place them on a local server for my class to use them (with appropriate attribution) without each student having to download them directly from your site? Is it intended that other people are allowed to host these data sets on other websites (e.g. my personal website) and (with appropriate credit) allow others to download them from there rather than directly from the ASU website? If this *is* the case, then could you please state that somewhere on the page? Saying that the data is available for use is not the same as stating that I am allowed to also give away the data. (And if this is *not* the case, then the cran maptools people will need to remove the data sets from their downloads.) Copyright law generally needs an explicit permission to redistribute to be offered by the copyright holder, and available for use is not such a permission. Returning to my hypothetical class who are going to work through your tutorials, if I would like to work with simplified data (for didactic reasons), am I able to modify the data sets and offer the modified data sets to the class (with appropriate attribution)? If I were a researcher in the field, am I allowed to take these data sets and add to them or improve them through further work? (giving appropriate credit, of course!) May I then offer the derived data on my website for others to download? If this is the case, could you please explicitly state this on the website? Once again, available for use is not helpful in terms of copyright law, where distribution of a derivative work must be permitted by the owner of the original work. I don't think people are necessarily asking for a change to the public-use permission that you give -- it's wonderful to have such data available! But clearly stating the intentions of the licence would be most welcome. The more I think about the phrase available for use, the less I understand exactly what it means. regards Stuart (who is obviously no longer just an interested _observer_ to this discussion) -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] New task: science-dataacquisition
Hi all, Re: https://help.ubuntu.com/community/UbuntuScience [3] The Ubuntu list also mentions a third package in that category - Plot Digitizer - A Java program used to digitize scanned plots of functional data. I don't think it is packaged for Debian, and don't know how it compares with the other two. I use PlotDigitizer whenever I need such a tool and find it to be really good. The point and click axis alignment and plot selection is easy to use and on plots with lots of data, the autotrace facility works nicely (you just draw a broad line over where the data is approximately found and the autotrace library does the rest). I talked to the upstream of PlotDigitizer some time ago about integrating it better on linux machines (I vaguely recall that the upstream developer is a MacOS X user). He was very responsive in dealing with problems that I found and liked the idea of being packaged and used more widely. The last time I looked at it, however, it had all the usual problems of the java ecosystem (e.g. internal copies of libraries in the source download) and the prospect of packaging that was a little daunting. There were also problems with libraries that had been relicenced from GPL to GPL-incompatible and PlotDigitizer upstream wasn't sure what to do about that. Given that there have been no releases in 3 years, I think that probably tells us what he decided. Packaging PlotDigitizer has stayed on my todo list, however, and I may yet have a look at it. That said, there may be less fraught alternatives already in the archive. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Software for poster presentations
Today, A.E.Lawrence [EMAIL PROTECTED] wrote: As of today, I can't imagine why anyone would use anything but LaTeX for scientific purposes, at least in any quantitative science. The only exception might be when accessibility was of overriding importance - then something based around MathML and friends might be sensible, perhaps also via a suitable LaTex package. GIMP, inkscape and more can be used to prepare images that can then be handed to LaTeX. I agree with your sentiments about latex being quite useful; indeed, it is the only thing that I currently use for writing up my work. But I'm talking about a poster here not a paper. A poster is an entirely visual thing where you do the layout; latex is an entirely text-based thing where the TeX typesetting engine does the hard work and does the layout for you. These two things seem to be at the opposite ends of the scale hence my question about whether latex would be a viable alternative. Have you ever used latex to produce a poster? Care to share the latex code (and final product)? Learning by example is always easiest! I have heard of conferences which don't know how to accept LaTeX: just say no and submit elsewhere :-) The question of not accepting LaTeX is orthogonal to this discussion; the presenter of a poster turns up with a printed out posted and sticks it up on the poster board. The conference organisers never even know what software you used to prepare the poster. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: software for generating image files from gridded arrays of data?
Hi all, Perl+ImageMagick can still do this (use Image::Magick). Attached is a *very* dirty hack that I used to threshold an image according to my own strange criteria. It actually creates a new black white image and sets each pixel individually within that image. So that's how you can set a pixel... I'm doing it based on the data in another image but there's no reason why you couldn't do it from your own data. This, perhaps, is a useful example for you. good luck! Stuart PS in the example you can see that I've used xc: and png: to specify the file type, but I think there's also a raw: type that you might be able to use. YMMV. -- Stuart Prescott www.nanoNANOnano.net areacalc.pl Description: Perl program
Re: bibliography package
Dear Slimane, install Jabref and refbase and bibus but I had installation pb. Could you describe your symptoms? We might be able to help. For jabref, you must have the sun java installed: 1/ make sure you have contrib and non-free in your /etc/apt/sources.list deb http://www.debian.org/debian/ sarge main non-free contrib 2/ install apt-get install jabref sun-java5-jre 3/ make sure sun java is the jre update-alternatives --config java 4/ start up jabref from the command line (jabref) or your window-manager menu Untill know referencer was the best. I interact with latex I use Jabref for my references and Kile for editing my latex documents. Kile is the KDE latex editor and it's very nice. It also integrates well with Jabref (select the reference in jabref and press Ctrl+L to insert it into kile). I continu to find the bibliography saint Graal ! I guess you mean (in English) Holy Grail. That's an interesting difference between the languages. http://en.wikipedia.org/wiki/Monty_python_and_the_holy_grail :) good luck! Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bibliography package
Yes, good catch -- I have sarge, etch and sid in my sources.list but have my apt preferences keep me on etch for most of the time I just copied the wrong line out. 1/ make sure you have contrib and non-free in your /etc/apt/sources.list deb http://www.debian.org/debian/ sarge main non-free contrib That should read unstable rather than sarge. While sun-java5-jre would be available for etch at least, jabref is not. deb http://www.debian.org/debian/ etch main non-free contrib deb http://www.debian.org/debian/ sid main non-free contrib Of course, I should also have said that one should use a mirror not just www.debian.org (I actually have www.uk.debian.org in there). Not from official sources, though. Since the package is essentially just a jar file, the sid ones seem to work find under etch too. In fact, they would probably even work fine on other distros :) cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: embed fonts in eps from R?
Hi all, I can't speak for R, but perhaps some ideas here: The publisher (AIP) demands submission of separate eps file for each figure with all fonts embedded in it (even the standard 14 adobe fonts). what a pain. I recently published an article in an AIP journal but the EPS files that I submitted used didn't any font information. I'm not sure how I got away with that (but the article came out fine). Maybe I was lucky or perhaps they've changed the submission system. Is there a solution for problem within open source environment (without using of proprietary software)? I suspect that you would be able to convert from EPS to PS or PDF and then back again to get the fonts embedded. There are a lot of different tools already packaged within debian that can do this. The tools within the ghostscript packages are probably worth trying. The second picture format that AIP journals accept is TIFF, but R has no tiff device to produce that pictures. Is there a strait way to convert the EPS file into the high resolution high quality TIFF figure? Converting from a nice vector graphic format like EPS to a raster format like TIFF is, of course, the last resort. While you do produce excellent looking results from such a process, you will make the electronic version of the paper /much/ larger and the plots will usually look worse on screen at normal viewing magnifications (100% or so) even though they will print fine. But sometimes, one just has to do this There are a plethora of tools that you can use for this bit . If you open the EPS file in something like the Gimp, then you can specify the resolution at which you want to import the image. You can then save it out in TIFF format. Command line tools like imagemagick's convert can also be used to convert EPS to TIFF at a specified resolution. Sorry if this is off-top questions. Not at all off-topic, IMHO. Plotting and dealing with strange publisher requirements are very much part of the the remit of debian-science. good luck with it! Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives to gnuplot ?
Hi David, thanks for the kind words! I can hardly claim credit for making PyX as good as it is, but I will agree with you that it is a very nice tool. It does produce some very very nice results. I'll also not claim to be an expert in plotting programs, but I'm pleased that my reviews of them has provided you with assistance. Since the plotting programs (particularly the KDE/Qt based ones) have matured somewhat since my original posting, I should perhaps revisit the question when I have a spare couple of days (hah!) to try them all out again and see what I make of them now, even if I have little intention of changing away from PyX having put the effort into learning to use it. BTW, I think I probably made my learning curve steeper because I needed to do quite complicated things right from the beginning (I was in the middle of writing a paper too) and also taking a programmers approach to it by trying to abstract things and use flow control rather than just treat it as a quick and dirty script. That's probably a salutary lesson for others thinking of playing with PyX. You are right that the examples are quite good, although I did find problems with the docs as soon as I wanted to change from a dotted line to a dashed line etc or do some very serious monkeying with the legend on a graph (OK, it's my own fault for having very complex graphs, but it was also the best way of representing the data! honest...) One thing that I found with PyX (and is true of many graphing packages) is that the size (bounding box in EPS speak) of the final graph is always different even if you give the graph the same dimensions when you create it. That's you define the size of the axes in PyX and then the tick labels and axis labels extend beyond that (and it's probably the most sensible way of doing it, so this is not a criticism of PyX, merely something of which one should be aware). Normally this isn't a problem, but if you wish to stack a number of plots vertically as (a) (b) (c) etc in a figure, then you have to make sure the axes line up or they look silly. You can do this in PyX by putting them on the same canvas, or using a tool such as epsfconpose (google for it) or just using your typesetting program (latex etc). If you don't use PyX to do this, then putting a white box around the outside of the plot (outside the tick and axis labels) is the simplest way to the same dimensions on each plot so they stack nicely. You could probably also edit the EPS bounding box to do so, but it seems nicer to just have .dat + .py = .eps and .eps + .tex = .ps rather than going through an error-prone step of remembering to change bounding boxes. (Given the number of number of posts to this list about preparing graphs, both 2D and 3D, this is obviously a pretty difficult issue for GNU/Linux users still... but it also seems that things are progressing rapidly. Let the discussion and development continue!) cheers Stuart
Re: publication quality graphs
Hi again, thanks for your responses so far -- some interesting ideas I had a play with PyX some more yesterday and piped the data through the aspline utility (package: spline) to get an interpolated smooth curve. That worked quite nicely for me (using the python pipes object to stream in the data). I'm quite liking pyx as a concept, although I'm still not convinced that it's a sustainable approach in the long run. But I did realise that it's not particularly efficient to be trying to do this in python (which I will have to learn to use PyX) instead of perl (which I am quite comfortable in). Anyone know of a perl graphing module with the power of PyX? Jamie, I can't help you with octave questions, but I can help with the others: * xmgrace my typo: s/xmggrace/xmgrace/ sorry. As already noted, it's in the package grace6 (or grace, diff versions etc) as it is a rewrite of an older program called xmgr * qtiplot has no debian package available (for free at least). Source is available from http://soft.proindependent.com/qtiplot.html It has a few dependencies, you'll also need to compile qwtplot3d yourself, the rest are in Debian. * pyx pyx is a python package so the package is called python-pyx Finally, Neil Pilgrim wrote: * OOo calc Maybe this will improve in the upcoming version 2? If only. Despite many many requests for this feature, it's only just got a target milestone... OOo3.0 so don't hold your breath. http://qa.openoffice.org/issues/show_bug.cgi?id=3997 cheers Stuart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
publication quality graphs
Hi all, A question that has come up a few times on this list is how people go about producing publication quality graphs. I'm revisiting this question as I'm yet to find a method that actually works for me. Part of this is that I am used to doing things in a particular way (which might have to change!) and part of this is shortcomings in various packages that I've tried. After a day or so of frustration with any given app, I end up going back to Origin (Origin6 under WINE mostly works). Here, I'd like to describe how I normally plot data and why the various apps that I've tried don't work for me (below). Hopefully, this will incite some discussion and regular users of these apps can suggest some add-ons or simple changes to my workflow that will turn them from being a pain in the backside to being a useful utility. Or perhaps this will encourage someone (me?) to hack at these apps until they become more useful to people like me. All comments welcome! cheers Stuart * current workflow using Origin I normally have data from a number of different (but related) experiments in the one file (perhaps X1 Y1 X2 Y2 or X Y1 Y2 Y3) format that has been exported from OOo.calc or excel or perhaps from a data analysis program that I have written for the purpose. The files are usually tab-delimited and I can just Import ASCII in Origin and all is well. It sets the column names to be the headers from the text file. I can then create plots with some or all of the data and will frequently want to add new data to a plot from another worksheet trivially etc. In the end I produce an EPS graphic for use in LaTeX or a PNG graphic for MSWord/MSPowerpoint. I like the project paradigm of Origin where data, settings and graphs are all together allowing you to add new data to plots, plot things in different ways etc. I don't just make the one final publication quality graph in an Origin project; rather, I usually have several different publication graphs in the one project (and often both print and presentation versions of these graphs too) as well as other graphs made while I explore the data. I tend not to use Origin for data manipulation as it is much more cumbersome than using a proper spreadsheet program like excel or OOo calc. * OOo calc Ha. Nice thought. Produces graphs that look as bad as M$Excel but can't even handle X1 Y1 X2 Y2 data (only X Y1 Y2). Non-starter even for just having a quick look at data, even if it does meet the project paradigm. * xmggrace It can't read in any of my data files. Bit of a showstopper, really I almost always have data with columns: X Y1 Y2 Y3... or X1 Y1 X2 Y2 X3 Y3... and I *always* have text column headings labelling the data. It chokes on this sort of thing and I'm not going to manually import hundreds of individual files (or columns piped through tail +1 | cut -f etc) through that tedious import dialogue. * qtiplot In a file with X1 Y1 X2 Y2 etc where the data streams are different lengths, it chokes... all the data is left-aligned in the import (i.e. if X1 Y1 has 20 rows but X2 Y2 has 30 rows, X1 Y1 will gain an extra 10 rows of data at the expense of X2 Y2). It also doesn't permit you to define multiple X columns per data sheet or edit an existing plot to change which column is to be used for the X or Y data etc (which is useful in transferring settings from one plot to another in the absence of styles or templates). Finally, the plots don't scale to the size of the window (there is no defined page size) so if you make the window bigger, then you have to manually increase all the font sizes yourself. * labplot Shares many of the same bugs/problems as qtiplot. But you also can't add a new curve to an existing graph unless you read it in from a data file directly or it is a mathematical function (i.e. you can't use data already in a data sheet). Column headers are also discarded so you'd have to go back and relabel all the columns. (OK, on the 1 week time scale you can just remember them, but on the 1 year timescale you need them labelled, and I always assume that i'm going to have to come back to it on that timescale as it can be that long between doing the work and publishing it.) It also can't generate smooth curves (e.g. splines) between data points. * scigraphica Importing X1 Y1 X2 Y2 data into a sheet causes the data to be truncated at the number of rows in X1. Column headers are imported, but if more than one column has the same name then only the left-most column is used when you come to graph that dataset. * gnuplot I'll confess that I have a deep seated aversion to gnuplot that dates back to my undergraduate days which is probably unfair. Having said that, I do prefer to be able to manipulate the graphs in real time *and* be able to save the settings and data as a project. With gnuplot you can do one or other (either run it from a script which is pretending to be a project file or some sort, or you can do it in real time.) *gri Works great for me for quick
