Re: Please do not mass-degrade Recommends to Suggests in med-bio
* Andreas Tille: " Re: Please do not mass-degrade Recommends to Suggests in med-bio" (Thu, 16 Jul 2020 22:06:18 +0200): JFTR: I had a short look at https://salsa.debian.org/blends-team/med/-/commits/master The only commit by Steffen since your (first) revert is https://salsa.debian.org/blends-team/med/-/commit/692d565fd0df6bfcd631edbfb12b6abb16507fd9 which doesn't introduce anything similar to mass-demoting. It seems you, Andreas, have merged branch patch-1 into master, that was not accordingly updated from master(?) and thus reverted the same change twice. So from my point of view nothing to blame on Steffen. Thanks for all your work on Debian Med, guys! Mathias > On Thu, Jul 16, 2020 at 04:19:39PM +0200, Steffen Möller wrote: > > I am not aware of any such activity of mine. > > I've linked the according commits. It might have happened by mistake - > but it happened (assuming that your Salsa push token is not stolen by > somebody else). > > Kind regards > > Andreas. > > > I added some binaries to > > bio that were only listed in covid-19, removed a duplication, may have > > resorted some bits to have them alphabetical, but rest assured that I am > > not in favor of wasting time twice, especially so if it is my own. At > > least not intentionally - may have now since you possibly have > > missinterpreted something, but no, I did not mass-demote anything. > > > > On 16.07.20 14:57, Andreas Tille wrote: > > > Hi Steffen, > > > > > > I realised that you again mass-degraded Recommends to Suggests in > > > med-bio[1] right after I reverted[2] your change. May be I was not > > > clear enough last time. So I repeat: Please do massive changes in a > > > separate branch (I created branch 'demote-recommends' for this purpose > > > for you) and discuss those massive changes here. Thank you. > > > > > > I've reverted your change again[3] and would love if we simply keep some > > > task that is mainly offering "everything" until we have some better > > > solution. I totally agree that its not a good solution but at least it > > > solves some problems and should not be broken until we have something > > > better. > > > > > > Kind regards > > > > > >Andreas. > > > > > > [1] > > > https://salsa.debian.org/blends-team/med/-/commit/82fef035750880267dd6de6734c3dc4971a17dde > > > [2] > > > https://salsa.debian.org/blends-team/med/-/commit/b53ad025ca39f6e3093630b1e065cf391b024a04 > > > [3] > > > https://salsa.debian.org/blends-team/med/-/commit/d1b8e269d50fa39ea231919aee15f0c8f495f5ad > > > > > > > > -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Seeking replacement for some Java icons in package mauve-aligner
Re-posting, initial reply didn't go the list(s): * Andreas Tille: Seeking replacement for some Java icons in package mauve-aligner (Wed, 15 Jul 2015 14:49:04 +0200): Hi, the package mauve-aligner containes some images[1] that are copyrighted Copyright 2000 by Sun Microsystems, Inc. All Rights Reserved. DarkHand16.gif so ftpmaster has rejected the upload[2]. Upstream says about these icons: Several of these icons were supplied by Sun as 'stock icons' to be used in Java interfaces, and although I'm pretty sure they were intended for redistribution I do not have a copy of the license. At least some of the other icons were definitely scraped from online sources without careful thought about licenses. A few were created by me. If you have suggestions for a good place to find freely licensed user interface icons it would be very helpful indeed! I would be happy to put in replacements with favourable licensing. While I'm seriously wondering about the fact whether 16x16 and 24x24 icons are copyrightable I'd be happy about any hints for replacent suggestions by free icons for the files Back16.gif Down16.gif Forward16.gif Home16.gif Up16.gif Zoom16.gif ZoomIn16.gif ZoomIn24.gif ZoomOut16.gif ZoomOut24.gif Any help would be really welcome. Since it seems to be possible to use png icons I would recommend to use those from e.g. gnome-desktop-theme or tango-icon-theme. Cheers, Mathias [1] https://anonscm.debian.org/cgit/debian-med/mauve-aligner.git/tree/src/images [2] https://lists.alioth.debian.org/pipermail/debian-med-packaging/2015-June/032563.html -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpVqD_P49c2Q.pgp Description: Digitale Signatur von OpenPGP
GNUHealth packages (was: Any volunteer to update GNUHealth packages)
* Andreas Tille: Re: [tryton-debian] Any volunteer to update GNUHealth packages (Tue, 17 Mar 2015 09:11:49 +0100): Hi Andreas, On Sat, Mar 14, 2015 at 11:31:18PM +0100, Mathias Behrle wrote: this information to the Debian Med tasks pages. I assumed that I could find the binary debs in http://debian.tryton.org/debian/pool/main/g/ but there is no such dir. Seems I have misunderstood the structure of the repository. s/g/t/ Namespace of GNU Health modules is tryton-modules-health* Ahh, OK. I added a link to Unofficial package to the tasks page. See the full entry (including the according Remark) here: http://blends.debian.org/med/tasks/his#tryton-modules-health The metadata (description etc.) of the package is obtained from Tryton Git repository. I evtl. got some time to update the docs and GNU Health specific instructions are now available at http://tryton.alioth.debian.org/gnuhealth.html I think it would be good to put a link on the tasks page. The pattern for the source list entry should read deb http://debian.tryton.org/debian/ debian-dist-tryton-series main For those interested in evaluating a dockerized demo setup based on Debian packages is available, which is documented at [0][1]. I would add also this since I think docker could be a nice test suite for gnuhealth. I don't understand exactly what you mean, This was perhaps a bit to short wording for my intend to add a hint to the tasks page about an existing docker instance. Got it now. Thanks, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpwvgGm1OANb.pgp Description: Digitale Signatur von OpenPGP
Re: Any volunteer to update GNUHealth packages
* Andreas Tille: Re: Any volunteer to update GNUHealth packages (Sat, 14 Mar 2015 23:10:23 +0100): Hi Andreas, On Fri, Mar 13, 2015 at 01:02:30AM +0100, Mathias Behrle wrote: just to keep you in the loop, that gnuhealth packages are now available at debian.tryton.org. Thanks for the good news and your effort into this. I'd like to add this information to the Debian Med tasks pages. I assumed that I could find the binary debs in http://debian.tryton.org/debian/pool/main/g/ but there is no such dir. Seems I have misunderstood the structure of the repository. s/g/t/ Namespace of GNU Health modules is tryton-modules-health* For those interested in evaluating a dockerized demo setup based on Debian packages is available, which is documented at [0][1]. I would add also this since I think docker could be a nice test suite for gnuhealth. I don't understand exactly what you mean, because after installation following [0] you should have a full fledged gnuhealth demo available. So yes, this is also another test, that the gnuhealth packages are in good functional shape. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpZ4HSswP_xt.pgp Description: Digitale Signatur von OpenPGP
Re: Any volunteer to update GNUHealth packages
* Andreas Tille: Re: Any volunteer to update GNUHealth packages (Thu, 12 Feb 2015 16:29:26 +0100): Hi Andreas, hi Emilien, hi debian-med people, [...] In short: If you think you found a proper way to create GNUHealth packages on debian.tryton.org it would probably a nice comfort for some GNUHealth users who intend to run Debian (or one of its derivatives). just to keep you in the loop, that gnuhealth packages are now available at debian.tryton.org. For those interested in evaluating a dockerized demo setup based on Debian packages is available, which is documented at [0][1]. Cheers, Mathias [0] https://github.com/mbehrle/docker-gnuhealth-demo [1] https://en.wikibooks.org/w/index.php?title=GNU_Health/Different_ways_to_test_GNU_Healthstable=0#Option_4:_Run_GNU_Health_from_Docker_.28Lightweigt_Containers.29 -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpKewqTCpt2y.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-debian] Any volunteer to update GNUHealth packages
* Andreas Tille: Re: [tryton-debian] Any volunteer to update GNUHealth packages (Thu, 12 Feb 2015 16:29:26 +0100): Hi Andreas, sorry for not answering this issue earlier. thanks for your answer anyway. On Mon, Feb 09, 2015 at 11:37:09AM +0100, Mathias Behrle wrote: * Andreas Tille: Any volunteer to update GNUHealth packages (Mon, 9 Feb 2015 08:40:47 +0100): GNUHealth 2.8.1 was released which is using tryton 3.4.0. We lost the official GNUHealth package recently due to incompatibilities with tryton. Any volunteer to prepare a package for exoerimental is more than welcome. Could you please point out, what's your motivation to call for this work again in this way Just for clarification: I did not intended to specify any way how the GNUHealth packages are created. My intention was that some work that was done previously should not be thrown away. Any enhancement that might serve our users properly is welcome. - against the pronounced will of the gnuhealth maintainers (I talked once again to the gnuhealth maintainers at this years Tryton Unconference in Leipzig, which are not in favor of having Debian packages but prefer a distribution agnostic way of installation) Generally speaking I'm careful about the pronounced will of a certain representative of a project that is given orally on a conference. I personally met another member of the project at 2011 at Med@Tel who was very keen on packages. It might depend from the time (my information is not as current as yours) and the representative (may be the person I have met is not a technican coming from the Tryton programmers). Thanks for posting those interesting links from debian-med, I joined the list later and didn't have any knowledge ot them. Summarizing the aspects around the gnuhealth packaging it becomes evident to me, that there were some lacks in communication(s), that added one to the other resulting in a more or less unusable package (as is the current state in svn). Just to be clear (I think to know you that you like clear words) and without the intention to accuse anyone I would see the main lacks in - gnuhealth people talking to different debian people without saying, that they are in contact with respectively the other - debian-med people not getting in contact with debian tryton maintainers early to coordinate the packaging (perhaps not seeing at the time, that gnuhealth modules are just another set of Tryton modules) - the packager not getting into contact with the framework upstream (i.e. Tryton) related to questions for the setup of the application in what concerns the framework. Those facts added to the result of the communication being later much more complicated, often frustrating and quite some work having been done to no avail (the latter not about the whole gnuhealth package, because some aspects can hopefully be reused in the new concept). I will try to learn from those facts to be clairaudient and curious enough to ask the participants about what contacts and which work were already done. - according to [0][1] the moderate interest in the subject I'm not sure that these links are telling something about the moderate interest but I agree that for specific software like software in medicine the interest measured in popcon users is low. I personally do see some sense in delivering packages anyway and I have good reasons for this but I would like to discuss this in a more generic thread like this GNUHealth related one. - still with the problematic concept of doing *one* package As I said above: I do not insist on this concept. I strongly believe in the Do-O-cracy principle of Debian where the doer decides how things will be done. - still with the unsolved problem to have gnuhealth modules compatible with the rest of the Tryton suite inside Debian with a justifiable amount of effort to do for the maintainer as well as for the release and security team I am volunteering to do the gnuhealth packages under the following prerequistes: - you give me a number of people interested in Debian gnuhealth packages apart from you and Emilien ;) (please take this from the humorous side...) I would need to check whether the recipients of the mail to the Debian Med list back in 2011[3] remains and might qualify as number of people interested - gnuhealth packages made by me will be in the well-proven generic way of the current Tryton modules I have no technical background of Tryton and thus I will simply trust the people who are dealing with this. - gnuhealth packaging (VCS) will be like for all Tryton modules on alioth +1 - gnuhealth packages will be made available outside of Debian on debian.tryton.org (the only way to make them currently available in a clean and seasoned way to the users with having the relative gnuhealth suite always being dedicated to the correct Tryton series and thus
Re: [Health-dev] OT: gnuhealth distro packaging (was: Should distribution packaging solve the installation/configuration issues our users are having?)
* Emilien Klein: Re: [Health-dev] OT: gnuhealth distro packaging (was: Should distribution packaging solve the installation/configuration issues our users are having?) (Thu, 12 Feb 2015 13:36:04 +0100): 2015-02-12 12:44 GMT+01:00 Mathias Behrle mbeh...@m9s.biz: * Axel Braun: Re: [Health-dev] Should distribution packaging solve the installation/configuration issues our users are having? (Wed, 11 Feb 2015 10:41:43 +0100): OpenBuildService is OpenSource and free to use. It builds Debian and Ubuntu as well (also on the reference server, build.opensuse.org), and by this can use as a common repository. Axel just asked me per PM, if and why I wouldn't use OBS for Debian gnuhealth packages and I am also answering here to share with the list. My points in primarily not using OBS in descending order: - For the build of Debian packages I am using the Debian toolchain, whenever it is not possible to use the Debian infrastructure itself. This gives me the background of a well established and proven build system with extended sanity tests. - I don't know OBS, therefore following remarks may be FUD: - The one or two times I wanted to try it was very unresponsive, I saved my time in not trying further. - I doubt, that the infrastructure as built on debian.tryton.org is possible to do on OBS. - I doubt, that OBS does the sanity testings (lintian, piuparts), which are part of the quality process on debian.org. - Finally I just trust more in Debian native tools than a third party build service. I completely agree with Mathias' points. OpenSuse's Open Build Service *can* create Debian packages that will install and provide whatever code/functionality you want, but none of the QA/conventions that have made Debian so robust and stable over the last 20+ years are enforced. Just to give an example, there are automated bug reports that are created when the package is automatically rebuilt on all the platforms that Debian supports (and those are roughly said the largest number that any Linux distro supports), which will let you know if your package, or any of its dependencies, have any problems. When OBS was introduced at FOSDEM (was it in 2012?), I attended the original introduction talk, and asked if the packages built would enforce/use Debian's QA. Answer was just No. Plus, the whole point of making a *Debian* package is to be able to install it with a simple `apt-get install`, on Debian or *any* of its numerous distributions. (and yes Mathias, this is also why I'm not super excited about building the package inside debian.tryton.org, which is rougly a software-specific PPA (in the Ubuntu world) which still requires you to play with your /etc/apt/sources.list. You don't need to be super excited, I am neither. Just provide me the infrastructure and personal ressources on debian.org to be able to serve our users - a project like Tryton releasing quite more often stable series as well as bugfix releases - a project like Tryton providing bug fix releases up to two years for its releases and I will be the first one to use them. BTW even if we will have on Debian some sort of PPA-like repositories this will still need to play with sources lists. I don't see that point. Adding back in the debian-med list to have all interested parties up to date. Will do so as well with my answer on the other email chain. Thanks for using and adding in future rather tryton-deb...@lists.alioth.debian.org for all Tryton related discussions in Debian. Cheers, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://www.m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpHmMYDAcd1e.pgp Description: Digitale Signatur von OpenPGP
Re: Any volunteer to update GNUHealth packages
* Andreas Tille: Any volunteer to update GNUHealth packages (Mon, 9 Feb 2015 08:40:47 +0100): Hi Andreas, GNUHealth 2.8.1 was released which is using tryton 3.4.0. We lost the official GNUHealth package recently due to incompatibilities with tryton. Any volunteer to prepare a package for exoerimental is more than welcome. Could you please point out, what's your motivation to call for this work again in this way - against the pronounced will of the gnuhealth maintainers (I talked once again to the gnuhealth maintainers at this years Tryton Unconference in Leipzig, which are not in favor of having Debian packages but prefer a distribution agnostic way of installation) - according to [0][1] the moderate interest in the subject - still with the problematic concept of doing *one* package - still with the unsolved problem to have gnuhealth modules compatible with the rest of the Tryton suite inside Debian with a justifiable amount of effort to do for the maintainer as well as for the release and security team I am volunteering to do the gnuhealth packages under the following prerequistes: - you give me a number of people interested in Debian gnuhealth packages apart from you and Emilien ;) (please take this from the humorous side...) - gnuhealth packages made by me will be in the well-proven generic way of the current Tryton modules - gnuhealth packaging (VCS) will be like for all Tryton modules on alioth - gnuhealth packages will be made available outside of Debian on debian.tryton.org (the only way to make them currently available in a clean and seasoned way to the users with having the relative gnuhealth suite always being dedicated to the correct Tryton series and thus being maintainable without headaches all the time) It would be very helpful to get those answers instead of just pushing back always the same idea, that has proven to not being adequate or even not to work. Best, Mathias [0] http://lists.gnu.org/archive/html/health-dev/2014-09/msg00053.html [1] http://lists.gnu.org/archive/html/health-dev/2014-09/msg00057.html -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpndFeZC33J1.pgp Description: Digitale Signatur von OpenPGP
Re: Any volunteer to update GNUHealth packages
* Emilien Klein: Re: Any volunteer to update GNUHealth packages (Mon, 9 Feb 2015 09:17:08 +0100): Hi, I don't want to repeat all the facts, that were already discussed, so just commenting on the wrong points, as Emilien asked me to do so. A final discussion point was with the Debian Tryton maintainer (Matthias, feel free to comment, as I believe you are on the d-med mailing list): Tryton is developed and packaged with separate tarball/.deb for each module. GNU Health is provided as one single tarball. Matthias was of the opinion that the gnuhealth software should be provided as separate .deb, to allow separate installation. His motivation was security, to not install packages that are not needed. The gnuhealth modules are very well obtainable as separate packages as they are released separately on PyPi. Aside from this being somewhat more cumbersome, it could still be reached by having one source package output multiple binary package, possibly also with one generic gnuhealth package that would depend on the essential/wanted binary packages. Thoughts? Please just search for my input on exactly this subject in the BTS resp. mailing lists. Before/if I start working on that package again, I want to make sure we reach a consensus (this time ;) ) Indeed a requirement, if this task shall succeed. It is really really required to be aware of the basics of Tryton (and subsequently the gnuhealth modules) to get a generic and widely usable layout. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgp_ELlLWFaOX.pgp Description: Digitale Signatur von OpenPGP
Re: Force removal of gnuhealth* packages in sid
* Emilien Klein: Re: Force removal of gnuhealth* packages in sid? (Was: Re: GNU Health autoremove from testing) (Thu, 18 Sep 2014 22:52:31 +0200): 2014-09-18 22:35 GMT+02:00 Andreas Tille andr...@an3as.eu: Hi Emilien, On Thu, Sep 18, 2014 at 10:14:58PM +0200, Emilien Klein wrote: On Sun, Jun 29, 2014 at 09:09:30AM +0200, Emilien Klein wrote: Who should I contact to get those removed from there as well? You can file a ROM bug report against ftp.debian.org (choose 'other' in the very first menu item pof reportbug). FYI I filed the ROM bug to remove gnuhealth from unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762136 Does this mean you have given up packaging GNUhealth at all? Yes, that was the gist of my posts in June. I am currently writing up a clearer post meant to debian-med, tryton and upstream mailing lists. The code is still available in the svn repo, should anyone want to pick it up again (but read my message first, unless the release schedule gets looked at there's not much point as it results in unbuildable package most of the time) +Emilien Thanks, Emilien, for clearing up further the matter. Sharing my personal point of view: With the current release cycles of Debian, Tryton and GnuHealth being not compatible we will run continously into the situation, where either the gnuhealth modules will force the Tryton suite to ship an outdated version with the next stable release of Debian or afford a considerable amount of work to split out versioned packages for gnuhealth. That said, the much easier way to go is to integrate the gnuhealth modules in the relevant sections of debian.tryton.org (carrying back- and forward ports for all supported Tryton series to Debian stable and testing). This will make them available including the bug fix releases for Tryton as well as gnuhealth, which is way preferable than to stick with just only security releases in Debian main. Of course the unhappy downside of this scenario is, that gnuhealth won't be in Debian main. Nevertheless I am tending to take that pill, because from a user point of view this is the much better experience and from the maintainer point of view means considerable less work. To sum up, from my side I will promote to take the procedure above and be happy to include gnuhealth into debian.tryton.org, probably not taking an evtl. RFA, rather comment on it with the argumentation outlined above. Thanks for your work, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: [Health-dev] Roadmap gnuhealth
install gnuhealth` and run the client `gnuhealth`) remains valuable, definitely for people trying the software out. That's the first step in making the software known, a new user can try it out rather simply. Of course when you're satisfied and want to run it in PRD, you'll have to think better on your deployment and backup strategy. But there's no harm in e.g. having the package take an extra automatic backup of your database ;) +1 I meant inclusion in the Tryton Debian archive. Similar to what you've just indicated [4]. What exactly is the Tryton Debian archive. Just have a look at [1][2][3], I hope this answers your question. Mathias wrote about something outside main which I actually would call a restriction I would not like since you will miss all the QA stuff which makes a package for science and business applications really valuable. Debian is nit just a bunch if simple to install software but a distribution of *tested* software that fits *together* properly. It is currently just not possible to maintain this package sets within Debian. Perhaps it will be, when we have something similar to PPAs. On one hand you claim API stability (which is provided by means of debian.tryton.org), on the other hand you claim Debian infrastructure. Both are not possible. I think, for the time being it is the best trade-off to have the current stable release in Debian unstable/testing and to provide up-to-date packages for former releases by debian.tryton.org. I hope you don't get a negative feeling on my part from this message. I am still as enthusiastic about Debian [Med] and GNU Health, but I've come to realize that packaging in the official Debian repository currently has challenges, and that I feel my contributions can be more impactful on other aspects ;) Finally you are a volunteer and you are free to decide how you will spent your time. I do evaluate your past work really high and I'm sure your future contribution will be as well (whether inside Debian or outside). Kind regards and thanks for your explanation Andreas. [1] http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm [1] http://tryton.alioth.debian.org/ [1] http://tryton.alioth.debian.org/mirror.html#why-debian-tryton-org [3] http://debian.tryton.org/debian/dists/ -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Roadmap gnuhealth (was: Force removal of gnuhealth* packages in sid?)
* Emilien Klein: Force removal of gnuhealth* packages in sid? (Was: Re: GNU Health autoremove from testing) (Sun, 29 Jun 2014 09:09:30 +0200): Hi Emilien, 2014-06-10 14:46 GMT+02:00 Emilien Klein emilien+deb...@klein.st: The packages gnuhealth-server and gnuhealth-client will have to be removed from sid (and from testing once the new package migrates to testing). The removal of the binary packages is automatically done once the package with the changed binary package names will be uploaded. I guess we can just wait for the autoremoval period to lapse, and the package will be removed automatically. Since there will be no upload of the newest version of the source package (newer Tryton version preventing building of GNU Health 2.4.X), the change in binary names will not be observed by the release system. I suppose I have to take manual action to remove that package from sid as well (the gnuhealth* packages were autoremoved from testing already) Who should I contact to get those removed from there as well? I am a bit confused by several messages. What are your current plans with the gnuhealth package? I assumed until now, that you planned to integrate the upcoming upstream release and then reupload to NEW. From: Emilien Klein emil...@klein.st To: 707632-d...@bugs.debian.org Subject: Closing bug report Date: Sun, 29 Jun 2014 08:59:29 +0200 As GNU Health was removed from the archive, this bug report is fixed. Closing bug report. Mathias, I am confident that in case you are picking up the package [0] you will make sure to address your concerns ;) Thanks for your help and comments on this package. +Emilien [0] http://lists.gnu.org/archive/html/health/2014-06/msg8.html What do you mean by 'picking up'? To avoid further confusion: the gnuhealth package will enter debian.tryton.org, when it fits into the concept (as previously said, chances now are much better as the package just provides the modules). One other point of this concept is a clean upgrade path to Debian main packages. So I won't do any changes to an existing package not maintained by me nor provide a conflicting one. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: [tryton-debian] [Health-dev] gnuhealth packaging
* Emilien Klein: Re: [tryton-debian] [Health-dev] gnuhealth packaging (was: Exception when building the package in a cleanroom Debian environment) (Wed, 26 Mar 2014 22:08:46 +0100): Hi all, 2014-03-26 16:30 GMT+01:00 Mathias Behrle mbeh...@m9s.biz: * Luis Falcon: Re: [tryton-debian] [Health-dev] [tryton] Re: Exception when building the package in a cleanroom Debian environment (Wed, 26 Mar 2014 10:33:35 -0300): Hi Luis, hi all, On Tue, 25 Mar 2014 19:10:00 +0100 Mathias Behrle mbeh...@m9s.biz wrote: * Luis Falcon: [tryton] Re: [Health-dev] Exception when building the package in a cleanroom Debian environment (Mon, 24 Mar 2014 19:02:30 -0300): Hi Emilien, hi all, [snip] I can not provide actually a fix withotu digging further into the gnuhealth package, but just some hints: 1) tryton-server [1] is passing piuparts and basically this seems also to apply for gnuhealth-server [2]. The error seems to be caused by the gnuhealth package scripts or the tools it uses. Thanks for the info. I am looking now at the the database-scripts/install/psql script of the Debian package. It's not a good idea to init all the modules. In fact, I wouldn't create any database . The DB creation, modules selection depends on the needs of each user or Health Institution. In fact some of them - like health_ICD10-PCS and health_ICPM should be mutually exclusive. I guessed something like that without deeper knowledge of gnuhealth, thanks for confirming. Quite a while ago I had a look at the gnuhealth package and shared my opinion in proposing a different package layout [1][2]. The gnuhealth package is maintained by the Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org and I think they will be glad to receive feedback. We appreciate the feedback Matthias, we discussed this topic in the past. See below for a bit more details. If you want to have a demo GNU Health instance with a set of modules, functionality, then we can provide you a postgres dump for that version. That's what Axel is working on with the LiveCD demo for OpenSUSE. While a postgres dump could be a solution to create a basic setup, I even would prefer to use a proteus script, like the one used to create the demo database on demo.tryton.org. This would make independent from the postgres version, being more flexible, being better maintainable, etc., since it just uses an existent and working Tryton server setup. The goal is not to provide a demo system (that will be done with a new binary package gnuhealth-demo, which will create it's demo database using the script provided by upstream for that purpose). The database is created to allow the user to directly log in, after having installed the package. There is nothing dependent on e.g. the Postgres version in executing For me the targeted audience and intended use of the gnuhealth package is not really clear. JFTR I want to desist from repeating my statements done on [1][2] in this thread and would like to point the interested reader there (I don't know what is the preferred way of discussion of subjects handled in bug reports? If it should be preferred to have this information duplicated here please just tell me). If the Debian package installs the server and modules; configuration files; gnuhealth OS and DB user and environment variables would be more than enough. Just as curiosity, can you check the DB encoding of the created DB (psql -l will show it). Again, we should not create the DB as part of the installation process though. I don't see see the point in not creating an initial database (with respect to the goal of an one-in-all package). I agree on not installing the whole module set by default into the database. As previously said I would split the gnuhealth package into more manageable packages. Indeed. The benefits of having the Debian package create the database at installation are multiple: - one less manual action that every user would have had to perform anyway once - allows to include making backups as part of upgrades - allow applying the upgrade patches submitted by upstream automatically For more details, read the [short] section Overview of package installation/upgrade/removal processes from the Best practices for database applications document [0]. My goal is not to initialize all the modules. It is to: - install all GNU Health modules on the hard drive - create the database so that the user can just launch the client and type it's admin username/password - just have the user select which modules they want to use. The user should be able to jump directly to step 4 Logging into the application [1] of the GNU Health installation steps, possibly without having to perform step 5 Installing the default modules, but still the ability to do step 6 Installing Extra Modules if they want to. I'd
Re: [tryton] Re: [Health-dev] Exception when building the package in a cleanroom Debian environment
* Luis Falcon: [tryton] Re: [Health-dev] Exception when building the package in a cleanroom Debian environment (Mon, 24 Mar 2014 19:02:30 -0300): Hi Emilien, hi all, On Mon, 24 Mar 2014 21:35:40 +0100 Emilien Klein emilien+gnuhealth@klein.st wrote: Hi GNU Health team, The Debian package has to pass a number of automated tests to validate a minimal level of quality. One of these tools is called piuparts. When running piuparts on the latest version of the Debian package, an exception was thrown. I would need some help figuring out how to fix this. See the output of the entire build process here, the Traceback is at the end: https://piuparts.debian.org/sid/fail/gnuhealth-server_2.4.1-2.log Extract: [Fri Mar 14 03:40:49 2014] INFO:modules:ir:loading lang.xml [Fri Mar 14 03:40:49 2014] [7mERROR [0m:convert:Error while parsing xml file: In tag record: model ir.lang with id lang_ca. Traceback (most recent call last): [...] File /usr/lib/python2.7/dist-packages/trytond/backend/postgresql/database.py, line 309, in execute return self.cursor.execute(sql, params) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in position 5: ordinal not in range(128) Seems like there is some character with accents in the Canadian language model, which can't be encoded using ASCII. The file ir/lang.xml is part of the core of Tryton server. I'm copying the Tryton community. The language that is making reference with this tag is Català (from Catalonia) . Tryton deals fine with non-ascii characters in xml files without the need for encoding it (like Catalagrave;) on the xml file. You should get this traceback at Tryton server tests, before the actual check GNU Health modules are loaded. It seems like it has to do with something on the test environment, since both Tryton core and GNU Health modules load just fine. Thanks a lot for reporting and for your great job on packaging GNU Health and Tryton in Debian. Best, Any idea how to fix this? Thanks, +Emilien I can not provide actually a fix withotu digging further into the gnuhealth package, but just some hints: 1) tryton-server [1] is passing piuparts and basically this seems also to apply for gnuhealth-server [2]. The error seems to be caused by the gnuhealth package scripts or the tools it uses. 2) Looking at the logs [3] the error occurs in the run of db-config-common: populating database via scriptfile... [Fri Mar 14 03:40:32 2014] INFO:server:using /etc/gnuhealth/gnuhealth-server.conf as configuration file So I would suggest to search in that direction, looking for something changing the environment to cause this error. [1] https://piuparts.debian.org/testing2sid/source/t/tryton-server.html [2] https://piuparts.debian.org/sid/state-failed-testing.html#gnuhealth-server [3] https://piuparts.debian.org/sid/state-failed-testing.html#gnuhealth-server -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Upload GNU Health 2.0 to experimental
* Emilien Klein: Re: Upload GNU Health 2.0 to experimental (Sun, 15 Sep 2013 23:32:14 +0200): So what happens here is: gnuhealth-server depends on tryton-server tryton-server recommends on postgres When installing the gnuhealth-server and all its dependencies, the packages get configured in this order: tryton-server gnuhealth-server postgres Since gnuhealth-server is using dbconfig-common to configure the database, it needs postgres configured and running. On my development box, that was the case (since dpkg -i doesn't pull in the dependencies, I had always installed those manually beforehand). But when installing on a system that doesn't have postgres installed, the incorrect order results in gnuhealth not being configured properly. I had wrongly assume that tryton-server would depend on postgres. But since that package requires manual configuration from it's user, they're actually fine with only suggesting it (when installing with apt-get/aptitude, by default the dependencies are pulled in), so for most users of the tryton-server package, suggesting has virtually the same end effect as depending: As you say above: postgresql is in Recommends, not in Suggests. tryton-server is multi-database capable with a strong preference for postgresql. So Recommends is the correct place for postgresl /nad will be pulled in default installations). postgres will be configured on the system before the user hand-edits the configuration files. I did not have yet a look at the current package, but I see some potential conflicts here. I think you should never interfere with the package configuration on the system, be it from the package installation, be it by the sysadmin. As a solution I would propose to create a completely separate postgresql cluster for gnuhealth, for which you are free to configure everything like you want (thus avoiding problems with systems running postgresql before and besides gnuhealth). HTH, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
* Andreas Tille: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP] (Wed, 29 May 2013 12:02:38 +0200): Hi Andreas, If you want me to ask for registering a pkg-tryton project (or whatever name you want to suggest - feel free to do so) I'd volunteer to do so and grant you admin permissions. However, the announcement[2] is 10 years old and there was no DM status at this time - I can't believe that you should not be able to register a project that makes perfectly sense. Why not simply go to https://alioth.debian.org/register/ and fill in the form. WOrst that can be happen is that your request will be rejected but I have severe doubt that this will happen. I simply went there and got a big fat red Projektregistrierung ist beschränkt auf Alioth, nur Administratoren können neue Projekte anlegen. So, no, I didn't get rejected, it was just not possible to create any request. Uhmm, that comes unexpected to me. Just tell me if I should register such a project (once you might agree to the policy). Please be so kind to register pkg-tryton. It will be enough for me to evaluate, if I will find all I am needing. My username on alioth is mathiasb-guest. I admit people might have a different sense of humor - but this World Domination thingy is just a running gag. I think there is no doubt that it only can be a joke. The document is meant and linked as *policy*. I think (and support), there is very little humour in Debian, when it comes to policies as DFSG etc...;). Humour is just not appropriate in policy documents. I admit that a policy document should refrain from humor and some better wording should be found. Whenever I will have a little spare time, I will make another proposal. As long as this remains unchanged, it is indeed a showstopper for me. From my perspective technically the wording would be worth a bug report severity minor - I would not regard minor bugs as showstoppers. (Just to explain my point of view, not trying to change your mind.) Filed under [1]. BTW: The fusionforge package itself doesn't seem to have at all a public VCS...;) Cheers, Mathias [1] http://alioth.debian.org/tracker/index.php?func=detailaid=314285group_id=1atid=21 -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
for the other modules (not gnuhealth related modules) for the sake of all Tryton users. I can try my best if the frequence you throw out new packages will not increase over my capacity. Currently it is not. The recent output (19 modules) is due to stalled development in the last 2 years. Now that I have a working environment I am up-to-date again. Usually there are ca. 1-3 new modules per release, which makes 2-6 packages a year. Thanks a lot for considering, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
the size of the team you should definitely migrate to the usual Debian infrastructure for development on Alioth. I can't see a reason that might make Tryton that special that the infrastructur that exists should not be sufficient. Using different ways for development increases your chances to remain alone. Debian infrastructure for sure is lacking features to be able to build all sorts of needed Tryton packages. I pointed this already out in an earlier mail and can do it once again. Tryton uses a release cycle of 6 months, providing bug fix releases for 2 years. No way to get this currently into Debian. Furthermore I just gave a try to Alioth. After registering an account (as -guest, while I am DM, hmm;)) I am told at the wiki [3]: Anyone can ask for a new project on Alioth but it will only be approved if it respects the project approval policy. While the link to ask for a new project [3][1] just isn't really helpful, Anyone according to [2] seems to be rather a synoym for DD. So I will have still to ask a DD to sponsor the project etc., creating even more overhead. My time for Debian is limited and the time I am currently using to just follow administrative procedures takes a lot of it. I prefer to do real work on my packages than to create overhead. Reading the policy I read We may also approve other projects on a case by case basis, for example: [...] - Any other project where you can convince the Alioth's administrators that it will help Debian achieve World Domination. Be it a joke or not, I cannot apply to such policy. Thanks for uploading tryton-modules-stock-lot in the meantime. I would be happy, if you also could do for the other modules (not gnuhealth related modules) for the sake of all Tryton users. Best regards, Mathias [1] http://alioth.debian.org/register/ [2] http://lists.debian.org/debian-devel-announce/2003/03/msg00024.html [3] http://wiki.debian.org/Alioth -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Bug#706957: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
* Andreas Tille: Bug#706957: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP] (Tue, 21 May 2013 18:02:38 +0200): Hi Andreas, thanks for the ping and for working on the tryton modules. Thanks for answering and now responding additionally to previous PM. In general I'm working in teams were the VCS is hosted on alioth.org and where I have commit permissions. Completely agreed for team maintenance, all Debian Tryton Maintainers stuff is organized like that. My previous sponsor (Daniel Baumann) retired, so the team currently is as small as a team can be...;) If you are willing to step in I will be happy to put you in Uploaders as well as receiving an ssh key for commit access. It is not that I usually would tend to commit a lot. But sometimes it is just simpler to commit a small fix than explaining the sponsee what I want to be changed. Since we are obviously using a little bit different workflow I would prefer to talk first until we know, which fixes should be applied. Because I prefer working with VCS rather than mentors I gave your Git repository a try: $ git stash Saved working directory and index state WIP on debian: d30bd8f Moving doc/index.rst to appropriate subdirectory doc. HEAD is now at d30bd8f Moving doc/index.rst to appropriate subdirectory doc. $ git-buildpackage dh clean --with python2 dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot' dh_auto_clean running clean 'build/lib.linux-x86_64-2.6' does not exist -- can't clean it 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.6' does not exist -- can't clean it running clean 'build/lib.linux-x86_64-2.7' does not exist -- can't clean it 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.7' does not exist -- can't clean it rm -rf *.egg-info make[1]: Leaving directory `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot' dh_clean gbp:error: You have uncommitted changes in your source tree: gbp:error: # On branch debian # Changes not staged for commit: # (use git add/rm file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # deleted:trytond_stock_lot.egg-info/PKG-INFO # deleted:trytond_stock_lot.egg-info/SOURCES.txt # deleted:trytond_stock_lot.egg-info/dependency_links.txt # deleted:trytond_stock_lot.egg-info/entry_points.txt # deleted:trytond_stock_lot.egg-info/not-zip-safe # deleted:trytond_stock_lot.egg-info/requires.txt # deleted:trytond_stock_lot.egg-info/top_level.txt # no changes added to commit (use git add and/or git commit -a) gbp:error: Use --git-ignore-new to ignore. The reason is that you intentionally are deleting trytond_stock_lot.egg-info which is part of upstream tarball. People (like me) who are keen on creating packages that are building twice in a row would prefer to rather move the package out of the way, lets say to trytond_stock_lot.hen-info and restore it afterwards. Deleting *.egg-info is just for the purpose to be able to build the package twice. Please read below. However, I was running git-buildpackage --git-ignore-new which worked. So I would not have used the issue above as a showstopper specifically when targeting at experimental. I am following the workflow of git-stuff [1], which until now for me gives clean and stable results. The Tryton packages so far use pure debhelper and I am building just with with debuild/dpkg-buildpackage (no use of git-build-package). But there is finally one issue which let me refrain from a final upload because the file debian/docs is different in Git and on mentors. So I do not have an idea what you really want to be uploaded. Please bring both into sync and I'll sponsor what I will find in Git once you have confirmed that this is OK. I think you are building from HEAD, not from the release tag. Thus I suppose the doc patch [2] in VCS is making the difference. Doing git checkout debian/2.8.0-1 debuild should just do the job. Thanks so far, Mathias [1] http://packages.debian.org/search?keywords=git-stuffsearchon=namessuite=allsection=all [2] http://debian.tryton.org/gitweb?p=packages/tryton-modules-stock-lot.git;a=commit;h=d30bd8f1e4e0901c089c358346fe1b8cd682eb49 -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
[Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
* Mathias Behrle: Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP] (Mon, 6 May 2013 14:35:04 +0200): CCing specific audience debian-med@lists.debian.org and debian-pyt...@lists.debian.org Dear mentors, could you please reconsider the RFS for this (and other) Tryton module(s)? Two weeks have passed without a response. The list of new packaged Tryton modules can be seen at [1] (ITPs) resp. [2] (RFSs). VCS for packaging can be found at [7]. They all add important new functionality to the Tryton framework. Especially this one (tryton-modules-stock-lot) is needed as dependency for the package gnuhealth [3] currently waiting in experimental. gnuhealth contains another set of Tryton modules providing the functionality of GNU Health, a free Health and Hospital Information System. All packages are packaged in the same way and they are free of lintian pedantic warnings (the one indicated being outdated [5]). So checking one is checking almost all of them, thus reducing the work load which could seem apparently high for 19 packages. Basically the complete suite of Tryton packages [6] is currently bug free, and I am doing my best to keep this state. I was already signalled to get DM Upload permissions for those new modules as I have already for the other packages. So sponsoring would be a one-shot and not a permanent task. I would appreciate a lot, if a sponsor could step up soon, because I would have preferred to upload the whole Tryton suite (which is still waiting from the freeze in experimental) together with the new modules at once to unstable. Thanks a lot for considering, Mathias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=wnpp [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=sponsorship-requests [3] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnuhealth/trunk/ [4] http://health.gnu.org/index.html [5] http://lists.debian.org/debian-lint-maint/2012/07/msg7.html [6] http://packages.debian.org/search?keywords=tryton [7] http://debian.tryton.org/gitweb/ Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package tryton-modules-stock-lot * Package name: tryton-modules-stock-lot Version : 2.8.0-1 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/2.8/ * License : GPL-3+ Section : python It builds those binary packages: tryton-modules-stock-lot - Tryton Application Platform (Stock Lot Module) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tryton-modules-stock-lot Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tryton-modules-stock-lot/tryton-modules-stock-lot_2.8.0-1.dsc More information about Tryton can be obtained from http://www.tryton.org Debian packaging for Tryton is hosted at http://debian.tryton.org Regards, Mathias Behrle -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
