Re: Request for sponsoring update of plotdrop

[Jordan Mantha]

On Thu, Jun 30, 2016 at 11:16 AM, Philipp Huebner 
wrote:

> Hi,
>
> I took the liberty of tagging debian/0.5.4-1 and uploaded the package.
>
> When pushing the tag I got some python error messages, looks like the
> mail hook isn't set up properly.
>
>
Thanks!

I did see they same errors when pushing. I had circa-2009 hooks in there
but I think everything is up-to-date now.

-- Jordan

Re: Request for sponsoring update of plotdrop

[Jordan Mantha]

On Thu, Jun 30, 2016 at 12:33 AM, Philipp Huebner <debala...@debian.org>
wrote:

> Hi
>
> Am 28.06.2016 um 18:00 schrieb Jordan Mantha:
> > Thanks  to both of you for the assistance. I think I've taken care of
> > all of James' suggestions (thanks for those, it did simplify my
> > debian/rules).
>
> There's one lintian hint left now but that's something you can fix in
> another upload later:
> I: plotdrop: desktop-entry-lacks-keywords-entry
> usr/share/applications/plotdrop.desktop
>
> Run "lintian -Ii plotdrop_0.5.4-1*.changes" for a more detailed explanation


OK. I think I will work on that upstream. Thanks for the heads up.


>
> > I couldn't figure out how to make my simple upstream Makefile accept
> > added CFLAGS/LDFLAGS from debian/rules so I've patched it to work for
> > now. As upstream I will work on making a better behaved Makefile but I
> > don't want to make a new upstream release just for that.
> >
> > I added the debian/gbp.conf file. That git repo was created before all
> > the branch names were standardized.
>
> No problem, but at least for "gbp pull" on my sid system you need to put
> in "debian-branch = debian" instead of "git-debian-branch = debian".
>

I guess that just got translated wrong between my brain and the keyboard
(to much git work in the last couple days).


> > With regard to debian/copyright, I thought I had gotten that mostly
> > fixed. What problem do you see with it? I confess it's been quite a
> > while since I did any Debian packaging so I on doubt am missing
> > something obvious.
>
> Well, I doubt that your last upstream contribution to plotdrop was in
> 2009 and for the files in debian/ I know for a fact that you worked on
> them recently ;)
> So please change "2008,2009" into "2008-2016".
>
> Furthermore d/copyright should collect the information of all files in
> the package. When I look into plotdrop.appdata.xml I see "Copyright 2014
> Ryan Lerch <rle...@redhat.com>" and what appears to be a Creative
> Commons license.
>
>
OK, fixed that.


>
> > BTW, I'm uncertain about what debian/changelog should look like for
> > working with a git repo and sponsorship. Should I keep it unreleased
> > ("gbp dch --snapshot" ?)and let the sponsoring DD do the final "gbp dch
> > --release"
>
> No, you should completely finalise the package for sponsoring.
> If I did any work on the packaging myself I should be added in d/control
> and d/copyright.
>
> As sponsor I'll do the following:
> - check the package, report if I'm unhappy with something
> - build it without any change
> - check again, report if I'm unhappy with something
> - sign it
> - upload it
>

Great, thanks for all the help.

-- Jordan

Re: Request for sponsoring update of plotdrop

[Jordan Mantha]

On Mon, Jun 27, 2016 at 12:41 AM, Philipp Huebner <debala...@debian.org>
wrote:

> Hi,
>
> Am 26.06.2016 um 21:05 schrieb James Clarke:
> > Hi Jordan,
> >> On 25 Jun 2016, at 21:21, Jordan Mantha <jordan.man...@gmail.com>
> >> wrote:
> >>
> >> I'm looking for a sponsor for an upload of plotdrop. I am the
> >> upstream maintainer (and former DM) and finally got to fixing all
> >> the Sourceforge, Debian, and Launchpad bugs. Since the package is
> >> maintained in the debian-science git repo I took the liberty of
> >> pushing the new upstream and updated the packaging (last touched in
> >> 2009). It's been a few years since I did any packaging but I think
> >> it should be in pretty good shape and I used pbuilder to build and
> >> test it.
> >>
> >> You can find the git repo at:
> >> https://anonscm.debian.org/git/debian-science/packages/plotdrop.git
> >
> >>
> > I’m not a DD and thus cannot sponsor an upload, but here are my
> > thoughts from having a quick look:
> >
> > 1. Your d/rules is fairly simple; you should switch to the dh(1)
> > sequencer
> >
> > 2. You should enable as much hardening as you can[1]; if you do 1.,
> > you get some of this for free, but unless you have a good reason to
> > you should add “hardening=+all” to DEB_BUILD_MAINT_OPTIONS
> >
> > 3. Your Vcs-Git should be
> > https://anonscm.debian.org/git/debian-science/packages/plotdrop.git
> > (note the .git and lack of a trailing /), as given at the bottom of
> > the cgit summary page
> >
> > Regards, James
> >
> > [1] https://wiki.debian.org/HardeningWalkthrough
> >
>
> I'm happy to sponsor your upload, but in addition to James' suggestions
> you should also update debian/copyright.
>
> And a debian/gbp.conf specifying the git-debian-branch would be nice :)
>
>
> Regards,
> --
>  .''`.   Philipp Huebner <debala...@debian.org>
> : :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
> `. `'`
>   `-
>

Thanks  to both of you for the assistance. I think I've taken care of all
of James' suggestions (thanks for those, it did simplify my debian/rules).

I couldn't figure out how to make my simple upstream Makefile accept added
CFLAGS/LDFLAGS from debian/rules so I've patched it to work for now. As
upstream I will work on making a better behaved Makefile but I don't want
to make a new upstream release just for that.

I added the debian/gbp.conf file. That git repo was created before all the
branch names were standardized.

With regard to debian/copyright, I thought I had gotten that mostly fixed.
What problem do you see with it? I confess it's been quite a while since I
did any Debian packaging so I on doubt am missing something obvious.


BTW, I'm uncertain about what debian/changelog should look like for working
with a git repo and sponsorship. Should I keep it unreleased ("gbp dch
--snapshot" ?)and let the sponsoring DD do the final "gbp dch --release"

-- Jordan

Request for sponsoring update of plotdrop

[Jordan Mantha]

I'm looking for a sponsor for an upload of plotdrop. I am the upstream
maintainer (and former DM) and finally got to fixing all the Sourceforge,
Debian, and Launchpad bugs. Since the package is maintained in the
debian-science git repo I took the liberty of pushing the new upstream and
updated the packaging (last touched in 2009). It's been a few years since I
did any packaging but I think it should be in pretty good shape and I used
pbuilder to build and test it.

You can find the git repo at:
https://anonscm.debian.org/git/debian-science/packages/plotdrop.git

Thanks,

Jordan

Re: Announcement: New bugs pages, status of renaming

[Jordan Mantha]

On Fri, Nov 7, 2008 at 4:17 AM, Andreas Tille [EMAIL PROTECTED] wrote:
 On Fri, 7 Nov 2008, Egon Willighagen wrote:
 I'm also part of DebiChem, though unfortunately rather dorment in the
 last two years... I'll check the discussion asap again, and comment on
 it to the debichem ML.

 Ahh, that's good to know.  For my perception only Michael and Daniel
 formed the team.  Perhaps you are volunteering to maintain the tasks
 pages for the moment.  Its a simple editing of debian/control - like
 files.  Just ask me if I should add you to CDD Alioth group ...

There is also Nicholas Breen and myself who do some work in Debichem.
I'm also a sometimes contributor to Debian Science. I'm sorry if my
lack of emails indicated that I didn't care about your task pages. I
just didn't have any complaints :-)

For my part, I'm still trying to figure out what exactly all this
CDD/Blends/Tasks infrastructure stuff is all about. I love the
generated pages but I'm not sure what *I* can do to help. What exactly
does it mean to maintain these task pages?

-Jordan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian Science Policy: First draft online and open for discussion

[Jordan Mantha]

On Tue, May 27, 2008 at 3:35 PM, Manuel Prinz [EMAIL PROTECTED]
wrote:

 Hello Debian Science,

 a first draft of the Debian Science Policy is now available in the Debian
 Science repository and can be checked out with:

  git clone git://git.debian.org/git/debian-science/policy.git


Thanks for the work! It's great to have that in VCS.

Besides the points mentioned in the document, the following points have to
 be
 addressed:

 1. What license should we use for the document?
 2. Git usage: Should tags be signed?
 3. How will the document be maintained?

 For point 1, I personally propose the GPL v3 (or later). But I do not have
 strong feelings about that.


Seems reasonable to me. I doubt it matters much.



 For point 2, I personally do not see a real benefit of doing so, so I would
 suggest it but not enforce it.


This also seems reasonable.



 For point 3, Sylvestre and I have strong interest in maintaining the
 document
 and would welcome anyone with a serious interested in it to help us.
 Writing
 documents is usually not much fun and as you can see, a lot of it still
 needs
 to be written. If you are interested, please email us! For changes of this
 document Sylvestre and I think that a workflow similar to the Debian Policy
 is reasonable, since most developers are already familiar with it. We would
 act as a gatekeeper and lead discussions on critial sections, summarize
 the
 result and propose a wording that should be seconded by people involved in
 Debian Science. After that, we would include the change into the document.
 One way to organize that is to package the policy as Debian package and use
 the BTS for proposals. Your feedback on that is welcome!


I think the gatekeeper workflow is appropriate. However, packaging the
policy and using BTS seems like overkill. It would seem to me that with git,
sending patches or merging from somebody's branch would be easy enough. I
would think that discussion via the mailing list would get more discussion
than using the BTS.


 We hope that you have no trouble reading and understanding the document.
 Both
 of us are not native speakers and some parts of the document were written
 in
 the night-time. We also did not want to sound bossy, and
 every should, must and has to is negotiable. It's a draft, after
 all. ;)


There was only one spot where I had a question. In the debian/control
section it says that the Section field should be science. I can think of a
lot of cases where a package would be in sections other than science. For
instance, math, electronics, gnome, kde, libs all seem logical as
well.

Otherwise, I thought the shoulds and musts were approriate. As somebody
who rarely uses CDBS and had never used quilt I'm glad those are preffered
:-)

-Jordan

Re: Debian Science Policy: First draft online and open for discussion

[Jordan Mantha]

On Tue, May 27, 2008 at 5:49 PM, Charles Plessy [EMAIL PROTECTED] wrote:

 Le Tue, May 27, 2008 at 04:10:18PM -0700, Jordan Mantha a écrit :
 
 There was only one spot where I had a question. In the debian/control
 section it says that the Section field should be science. I can
 think of a
 lot of cases where a package would be in sections other than
 science. For
 instance, math, electronics, gnome, kde, libs all seem
 logical as
 well.

 Hi Jordan,

 Actually, there can be a Section field for the source and the binary
 packages. Maybe that can solve the problem ?


Perhaps. The reason I wondered is because plotdrop, which I just put in the
git repo, has Section: math . Would I want to change that or is it not a big
deal?

-Jordan

Re: Software for poster presentations

[Jordan Mantha]

On Sun, May 18, 2008 at 3:13 PM, Stuart Prescott 
[EMAIL PROTECTED] wrote:


 Hi All,

 As a brief respite from packaging discussions, here's a user question:

 What software would you use or recommend for preparing a poster for
 presentation at a conference? [0]

 A few things come to mind straight off -- perhaps existing users can make
 comments on these things:

 * openoffice impress or draw: I guess these would be the same as doing a
 poster in powerpoint, with the same limitations. Does it work OK?


I've had labmates go the PowerPoint way. I think the biggest issue has been
pixelated graphics. If you can get good resolution graphics then it's not
too bad.


 * inkscape: can it handle flowing and editing text nicely? I've only ever
 used
 it for drawing. I see it's debtagged as works-with-format::tex which I
 find
 intriguing but don't know what that means in practice. I know it has
 bugs/limitations in being able to compress jpeg images which could result
 in
 an obscenely large PDF export when it comes to producing the final product.


I use inkscape to great figures for posters and papers, but I've not tried
to do the whole poster that way. I think it would be a bit limited in terms
of layout.

* scribus: I've never used it but by its description it sounds like a good
 tool for the job; I've heard it's a bit quirky but that it's a good program
 for this sort of thing.


This is what I used for my last poster. It gives some pretty good results.
Layout is pretty easy and it will definitely get the job done. It is quirky
though and it took me a bit to figure out how to do things.



 * latex (directly): as for lyx, it would of course be possible, but is it
 sensible to do so? [1]


I've also done posters in the past using plain-old latex. It took me
*forever* to do it though. The results were great of course (equations look
great) but for me personally not worth the time.

-Jordan

Should plotdrop go in the git repo?

[Jordan Mantha]

Hi all,

I'm the maintainer of plotdrop [1] (a minimal Gnome frontend for gnuplot).
After all the flurry of activity around the new alioth project and git repo
I'd like to ask if you think it would be appropriate for plotdrop to be
moved there? It's not a very exciting package but I'd like to put it in a
public VCS somewhere. I am a Debian Maintainer so I can look after it (and
maybe help out on other packages if I have time).

-Jordan Mantha

[1] http://packages.qa.debian.org/p/plotdrop.html

Re: debian-science git repository

[Jordan Mantha]

On Thu, May 15, 2008 at 9:04 AM, Teemu Ikonen [EMAIL PROTECTED] wrote:

 Hi all,
 snip
 Additionally, publishing the repository in alioth (git.debian.org)
 requires some steps which are not completely obvious. Here's  a short
 guide:

 First, in alioth:
 # create a bare git repository
 cd /git/debian-science/
 mkdir project.git ; cd project.git
 git --bare init

 # activate the default post-update hook to allow http checkouts
 chmod a+x hooks/post-update

 # The non-obvious part: If your repo does not have a 'master' branch
 # (like in the example above), the HEAD ref in the repository needs
 # to be set to point to something that exists in the repo you are about
 # to push. Otherwise checkouts from the clone of this repo will fail.
 # In our case this branch should be 'debian'
 echo 'ref: refs/heads/debian'  HEAD


 Then locally:
 # tell your local git repo about the remote
 git remote add alioth ssh://
 [EMAIL PROTECTED]/git/debian-science/project.git
 # hack away
 [...]
 # push to alioth, when you want to publish your repository
 git push --all alioth
 git push --tags alioth


Thank you so much for this guide. I just pushed plotdrop to the Debian
Science git repo using your directions. I'm pretty much a git newb but I
*think* it worked as expected. I also very much appreciated your repo
structure suggestions. I'm amazed at how easy pristine-tar is to use and
it's very nice to have everything you need right there in the repo (and
under revision control).

-Jordan Mantha

Re: desktop file main category for a scientific data viewer?

[Jordan Mantha]

Carlo Segre wrote:
 
 Hi Thibaud:
 
 On Mon, 3 Mar 2008, Thibaut Paumard wrote:
 

 So, should all science software really go under Education??? Or should
 I use both Graphics;3DGraphics;Viewers *and*
 Science;Astronomy;DataVisualization?

 
 The consensus on the debian-science list is no.  Education is simply not
 the right category.  We have made several efforts to have this changed
 in the free desktop specification to no avail.  Some of us simply use an
 sensible category and let the lintian errors pile up until they come to
 their senses.


When were such efforts made and where? I've not seen any discussion
about scientific/research/technical menu additions on the fd.org xdg
mailing list since I last had a discussion in June of 2007 where it
seemed like they were quite willing to look at a patch. Note that I'm
not denying there were efforts, I just haven't seen them.

I was going to send such a patch to add a Science main category but I
didn't want to do so until there was consensus around the name. It seems
like Research is now the favorite, is that correct?

-Jordan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Desktop menu categories

[Jordan Mantha]

On 8/19/07, Charles Plessy [EMAIL PROTECTED] wrote:
 Le Sat, Aug 18, 2007 at 06:02:55PM -0700, Jordan Mantha a écrit :
 
  I wrote the freedesktop.org xdg mailing list about this issue back in
  June [1]. My proposal was to romote Science to a main category. There
  was concern about how to deal with legacy  issues. What happens if
  somebody installs a .desktop on an older distro (say etch or Fedora
  Core 6)?

 Hi all,

 I think that I do not get the point : isn't the concept of a distro to
 install programs through packages? If somebody backports a recent
 program to FC6 or Debian Etch, then it is straightforward to patch the
 .desktop file to add `Application' back.

I believe the concern was not distro supplied packages, but rather new
upstream releases being installed on legacy systems. So if I was
running etch and I built some app from source, either because it
doesn't exist in Debian or I wanted a newer version than what exists
in the repos, the concern was how the menu item would be handled. I
personally think that this is enough of a corner case that it
shouldn't stand in the way of progress.

-Jordan

Re: ROOT in Debian experimental

[Jordan Mantha]

Frank Siegert wrote:
 Christian Holm Christensen wrote:
   
 ROOT 5.15.07 is now available from Debian experimental.
 
   [...]
   
 The packages are in experimental, because they are based on development
 code.  Once ROOT releases the next production version (5.16.00,
 scheduled for June 27) we will build packages of this, and upload these
 to unstable.   From there, the road to testing and eventually
 stable is straight forward.

 Ubuntu users will probably see ROOT hit their distribution shortly.
 

 That timing is a bit unfortunate for Ubuntu users, because 
 DebianImportFreeze[0] for Ubuntu's next release (Gutsy Gibbon, 7.10) is 
 scheduled for June 21[1].
 So, Ubuntu users: Don't expect these packages to appear in Ubuntu 7.10 
 automatically. Nevertheless, we should find out, whether it is possible, 
 to do a delayed sync for 7.10, once the packages are in unstable. I am 
 CC'ing the ubuntu science team, who should know about this.
 Christian: If not, is it possible to keep your debian-root repository 
 running til April 2008, when Ubuntu should also have native ROOT packages 
 synced from Debian?

   
The most appropriate freeze here is NewPackagesFreezeUniverse, which is
August 30th. It's true that we won't automatically sync after
DebianImportFreeze but all it takes is a sync request (a bug filed) to
let the Ubuntu archive admins know to sync it. It'd be helpful if
somebody gives us a poke again when the ROOT packages hit unstable so we
can file the paperwork. :-)

 This makes ROOT the first major Linux distribution that ships ROOT as
 part of it's package list - beating even Scientific Linux.
 

 Very nice indeed!

 Cheers,
 Frank

 0: https://wiki.ubuntu.com/DebianImportFreeze
 1: https://wiki.ubuntu.com/GutsyReleaseSchedule

   
Congrats on this, I know it's been a big deal for a while now.


-Jordan Mantha


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: How much interest in a debian-science.org repository?

[Jordan Mantha]

Kevin B. McCarty wrote:
 Dear list,
 
 Currently there are a fair number of repositories of science-related
 unofficial Debian packages out there.  I've been thinking that it might
 make sense to consolidate them into a single site.  This would have
 several advantages:
 
 - Permit convenient one-stop shopping for unofficial scientific .debs
 with only one sources.list entry (well, two counting deb-src)
 
 - Better PR for the unofficial .debs.  Instead of a dozen different
 unofficial repositories, now only one would need to be publicized,
 perhaps with an obvious name like www.debian-science.org.
 
 - Possibility of more complicated dependency graphs between unofficial
 packages
 
 - Possibility (someday) to set up a buildd network that can autobuild
 all the packages for various architectures
 
 - Testbed for packages that ultimately can enter Debian proper
 
 - Convenient unofficial source for packages that can't enter Debian, for
 whatever reason, as long as the maintainers had permission to distribute
 them
 
 I was talking to Brett Viren about the possibility to host CLHEP and
 GEANT4 .debs at his site, maintaining a repository for unofficial
 physics related packages.  So the question is, would other Debian
 Scientists, in fields other than physics, also be interested in using
 this repository?

My initial reaction is, heck yeah! One of the things that sort of drives
me nuts about scientific Linux software (although it isn't limited to
science) is that you have to travel all over the web looking for things.
That's one of the main attractions to Debian/Ubuntu for me. There are
these large repositories of software that make finding and comparing
software so much easier. Plus, having the dependencies in the same place
is definitely helpful.

I would hope that it would also foster collaborative maintenance of the
packages too. Having a single source for source packages as well as the
binaries would be great. Maybe even some svn repos for maintaining the
packaging. On that thought, would Alioth be of any help for this?

-Jordan Mantha


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: How much interest in a debian-science.org repository?

[Jordan Mantha]

Michael Hanke wrote:
 On Wed, Jul 19, 2006 at 12:07:40PM -0400, Kevin B. McCarty wrote:
 Dear list,

 Currently there are a fair number of repositories of science-related
 unofficial Debian packages out there.  I've been thinking that it might
 make sense to consolidate them into a single site.  This would have
 several advantages:
 - snip -
 
 I think this is a great idea and Debian-science community could gain a
 lot with this central repository. But IMHO its success might depend
 on the details:
 
 
 
 1. What Debian versions will be supported (or what Debian derivatives)?
 
 I maintain some unofficial packages related to experimental psychology
 and MRI data analysis. From user feedback and the download stats I know 
 that people seem use my packages with sarge, etch and Ubuntu breezy and 
 dapper more or less equally often. Moreover, a single lab often uses a
 mixture of the above. Therefore I try to provide binary packages for all
 those distributions. 
 
 Perhaps this is just a special case, but it might be similar with other
 packages.
 
 I know that some people simply do not care about Ubuntu, but there is
 obviously a demand and most of the time porting a package to an Ubuntu
 release is just recompiling it.
 
 What I want to say is, that I would prefer a repository that provides
 packages for every distribution and platform that people (maintainers)
 are willing to support.

Well, in terms of Ubuntu, I think we (Ubuntu Science team) could perhaps
help out. Right now, in Debian proper, I'd say about 1 in 10 packages
from Debian need to get tweaked (mostly dependencies) to work on Ubuntu.
Otherwise the Debian source packages are just rebuilt. If this idea
takes off I'd imagine we could get some Ubuntu build machines. I'm not
sure if it would work (or even be wanted) to put them all in the same
repo though.

 2. What are the requirements a package has to meet to be included in the
 repository (e.g. license)?
 
 If a package is perfect in any sense it could obviously go directly 
 into the Debian archive. Therefore the repository will contain
 imperfect packages and the question is what kind of imperfection is 
 tolerated (lintian error, minor/major licensing issues, ...)?

I'm guessing the imperfection would be mostly that the packages are
experimental in nature or have licensing problems. On the other hand, it
could be that the package authors simply never tried to put them in
Debian, I don't know.

 3. Who will be able to upload packages?
 
 If only DDs are able to upload packages the number of contributors is
 (unecessarily?) limited. But if the Debian-science repository aims to provide 
 the same quality and security as the main archive, there is no way around it.
 
 If the repository is intended to be more open than the Debian archive,
 and I think it should be, then I see two possibilities:
 
 1. Everybody gets upload rights. This is simple, but might be the source
of serious trouble.
 
 2. Perhaps a procedure similar to Alioth would be a reasonable way to deal
with upload rights: Potential contributers explain what they want to
provide and get upload rights if they provide a solid explanation.
From that point on they have the right to upload new packages, but
not to upload new versions of packages already in the archive where
they are not (co-)maintainers. DDs might be an exception of the rule.
This should not limit the number of contributors and introduces a 
minimal protection against bad guys.
 
The main disadvantage is that somebody has to implement this.

Maybe looking at other projects such as mentors.debian.net or even
Ubuntu's REVU system might help.

-Jordan Mantha


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#361418: Debian menu and the Apps/Science section

[Jordan Mantha]

* Daniel Leidert [EMAIL PROTECTED] [2006-05-15 01:25:57]:
  The latter is like:
  how to do integration or differentiation, waht are Newton's rules in
  gravity
  the first is like:
  when I apply several of the basic rules to these measurements under
  given constraints
  then one can proof the existance of a sub-particle for a few nano
  seconds in nuclear physics.
 
 Yes. But these are clear examples. I have a repository full of chemistry
 related packages. One e.g. supports a bunch of quantum chemistry
 packages. But it is designed to help users of these packages. The
 application itself doesn't teach anything, but it helps teaching quantum
 chemistry packages. So I just need a clear definition, when to put an
 application into Education and when to put an application into Science.

I'd like to jump in a little bit here. I think this question (should an
app go in Education or Science? or really any category for that matter)
really might be best answered by the software authors themselves. I
think they have a pretty good idea of what the primary purpose of their
app is and what users use it for. This is why I'd like to see a push to
provide .desktop (freedesktop.org compliant [1] and [2]) files to
upstreams who can tweak the Categories if need be.

On the Ubuntu side we made a big push to get .desktop files put in
science apps for Dapper (to be released June 1) since we don't use the
Debian menu system. We added about 45 .desktop files out of the ~450
packages we (MOTU Science team [3]) track. The next task is to get them
upstream at least to Debian (via bug reports) and hopefully to the
software authors. One reason I've pushed for this is that I'd like to
see a Science menu in Gnome. Right now, science apps go in either
Education, Other, or Graphics (for plotting apps) in the Gnome menu and
more often than not they don't show up at all because they have no
.desktop file.

-Jordan Mantha

[1] http://standards.freedesktop.org/desktop-entry-spec/latest/
[2] http://standards.freedesktop.org/menu-spec/latest/
[3] https://wiki.ubuntu.com/MOTU/Teams/Science

-- 
That's all very well in practice, but will it ever work in theory? -- G. Hill
A tidy laboratory means a lazy chemist. -- Jöns Jacob Berzelius


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ubuntu-science

[Jordan Mantha]

Daniel Leidert wrote:

Am Freitag, den 06.01.2006, 23:22 -0800 schrieb Jordan Mantha:

[..]
   Ok, so the reason I sent this rather long email is that I think it 
would be a benefit to both the Debian and Ubuntu communities if we keep 
each other informed at least and work together where possible.


But then why also splitting the mailing lists? We split more and more
things only because there is Debian and there is Ubuntu and so we split
the whole possible resources.
Well, to be honest I don't see this as a split, but and addition. The 
purpose of MOTUScience is to coordinate and discuss packaging activities 
(merges, bugs, etc.) within Ubuntu.




I am 
encouraging the MOTUScience team members to at least email this list 
when a new science package has been added to Ubuntu so that we don't get 
a lot of duplication of work.


You see the duplicate of work? Debian user or maintainers of science
package have to remember to send mails to the Ubuntu lists and the
Ubuntu guys have to do the same and send mails to the Debian lists.

Isn't there a possibility to stay on one list and tag threads if
necessary, rather than splitting the lists and the manpower?

The reason why I say this is, that I got several mails asking for Ubuntu
packages of my science and non-science Debian packages. Now splitting
all the places, where the work is done or where the discussions take
place doesn't make my life easier.


I don't see duplication of work here (at least that is what I am trying 
to avoid). I really don't think that Debian would have to do much. The 
burden of communication is really on us (Ubuntu). We already obtain the 
Debian packages when we sync to sid. We already try to link to bug 
reports in BTS when we have bugs filed in Malone. What we need is for 
Debian to hear about what we are doing. I really don't think that Debian 
should really need to do anything additional. The only thing I can see 
now is that it is helpful for everybody that when we add new packages to 
Ubuntu that they eventually get into Debian too and that can be somewhat 
of a challenge if you aren't used to Debian.


For me this is not a split of manpower since, at least for me 
personally, I didn't stop contributing to Debian to contribute to 
Ubuntu. I never used Debian so you are infact gaining manpower. In fact, 
I am trying to patch a split that already exists. If people working on 
Ubuntu never talked to Debian then we could have some serious 
duplication of work. I am trying to open lines of communication so that 
doesn't happen.


If you include your packages in Debian they will be included in Ubuntu. 
You don't have to worry about Ubuntu if you don't want to. I am not 
trying to split debian-science, I am just trying to compliment it. Right 
now ubuntu-science is just for us to use for internal communication.




of course, just my 2 cents
Regards, Daniel




Thanks for your thoughts,
Jordan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ubuntu-science

[Jordan Mantha]

Dirk Eddelbuettel wrote:

On 7 January 2006 at 18:16, Daniel Leidert wrote:
| Am Freitag, den 06.01.2006, 23:22 -0800 schrieb Jordan Mantha:
|  I am 
|  encouraging the MOTUScience team members to at least email this list 
|  when a new science package has been added to Ubuntu so that we don't get 
|  a lot of duplication of work.
| 
| You see the duplicate of work? Debian user or maintainers of science

| package have to remember to send mails to the Ubuntu lists and the
| Ubuntu guys have to do the same and send mails to the Debian lists.

I am with you. I am still confused about this whole thing:

-- On the one hand Ubuntu/Kubuntu is a well put together distro and I run
   Kubuntu on a few machines and like it. I happily recommend it, and its
   polish and coherence make it really quite pleasant. I only use it on 'use
   only' non-development machines.

-- On the other hand as a maintainer (of currently 72 packages), I am
   _appalled_ and _shocked_ by the lack of feedback from Ubuntu to Debian --
   at least as far as I can see. There was a thread on debian-planet a while
   that mentioned Ubuntu bug archive. Sure enough, there were patches to
   (though in my case only a few) packages of mine. Nobody ever bothered
   to let me know, yet at the same time Ubuntu is happy to take advantage of
   the work I've been doing here for now over a decade of diligently
   maintaining my set of packages. 


I can understnad where you are coming from here. That is really what I 
am trying to work on here. There are a lot of Ubuntu users who are not 
Debian users and there are a lot of Ubuntu contributors who are not 
Debian users. When Malone and launchpad.net are fully functional then I 
think it will be a lot easier. Right now on Malone we can attach a 
tracker to the Debian BTS so that we can keep track of a Debian bug that 
is also reported in Ubuntu. What I am trying to work on is the 
communication back to Debian. We want to be able to give back to you but 
I think to some extent it is hard when you are an Ubuntu user and not a 
Debian user. I personally am working on learning how to use Debian's BTS 
and file ITPs and find sponsors but it is not something that I 
automatically know just because I package for Ubuntu.




-- Lastly as the one behind Quantian, the to my knowledge single largest
   collection of scientific / numerical / quantitative apps in one
   ready-to-run place, I'd love to pull the two resources in and get, say,
   the more polished desktop experience and menu organisation of (K)Ubuntu
   back into Debian / Knoppix / Quantian, and would also love to pull some of
   the additional packages in.  But I am
 * still puzzled about the binary interchangeability, or lack thereof,
   between Ubuntu and Debian
 * confused as to why one would want to insert a package into Ubuntu
   but not Debian (other than the needing a DD sponsor reason).


To be honest, I package for Ubuntu because it is the distro I use. I 
don't run Debian (although maybe I should) so I would feel awkward about 
packaging something for a distro that I don't even run. Now, maybe that 
is my fault but I am encouraging Ubuntu packagers to go ahead and file 
ITPs or RFPs and find sponsors.




I really don't want to be confrontational, or start another useless flame
war. But given Debian and debian-science, how can we achieve the best
outcomes with the least amount of duplication and waste?


I agree. That is why I started this discussion. For me it comes down to 
this, we have Debian users who will want to package/patch for Debian and 
Ubuntu users who will want to package/patch for Ubuntu and what we need 
is for the Ubuntu packages/patches to get make it into Debian because 
that is good for everybody. I wanted debian-science to be aware of what 
we are doing over in Ubuntu so that we can communicate/coordinate as 
needed to avoid duplication of work and make sure that we are giving 
Debian/Ubuntu users the best distros we can.




Thoughts or comments?

Dirk




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]