Re: d/u/metadata for binary or source tree Re: RRID update on salsa on packages starting with A+B
On Wed, Apr 04, 2018 at 01:56:42PM +0200, Steffen Möller wrote: > > > https://blends.debian.org/blends/apa.html#datagathering > > > > (A.7.) could be a first shot on this problem. > One half done. The invitation to contribute to salsa I have no idea what you might consider *Blend* *specific* in using Salsa. Everything worked before Salsa and the fact that Git repositories now can be changed via web form has nothing to do with Blends. Am I missing something? > and the screenshots and translations is missing. That's perfectly generic Debian stuff. Well, I admit I wrote the UDD importers for screenshots and translations because I intended to use it on the tasks pages. But it is used in very different places for all Debian packages. So what exactly do you want to be documented here? (Patches welcome) > > That's not about branches. As previously said: Registry data are per > > source package currently. There is no means in the registry data table > > to map an entry to a binary package. Thus autodock *and* autogrid are > > missing registry data both. > > There was one d/u/metadata file that assigned different references IIRC to > different binaries of that source package by inventing a sub-hierarchy. Can you please re-read https://lists.debian.org/debian-med/2018/03/msg00119.html Seek for "For citations we are using the field Debian-package" > This > seems to indicate that this is not only an issue for the registry entries. > How about the following: > > * d/u/metadata always refers to the source tree as a whole That's the case. > * d/u/metadata also refers to the binary with the same name as the source > tree. That's also the case (more or less unintended but it is working like this). > * information in d/u/metadata associated with a particular set of binaries > with the same or different names shall be listed in a "binary: " attribute See my posting. > Admittedly, I see some issues with that. The notion of a reference binary > for a package with many binaries would be helpful for Debian in general. > This would prevent something like the Massxpert entry on our task list that > describes itself as a transition package. Hmmm, I do not understand what you mean. Fixing the massxpert package is only one commit away: https://salsa.debian.org/blends-team/med/commit/6451da2d816f762cf391f048676c79eee1c25431 Please, if anybody notices this, just fix the according task instead of assuming intentional displaying cruft. Its not *that* hard to do to replace an outdated package name by a correct one. > But this also means that such > notion about, say, "end-user relevant" packages vs technical helper packages > because of arch-independency or libraries etc, should be declared in > d/control. I guess you want to invent some extra layer of complexity for d/control which will never be accepted to solve a problem for Registry entries which was just solved for citations. We just need a *decision* I was asking for in the end of the mail I was linking to above. > Another concern of mine is that we typically do not tag any data for being > specific for something. We put it in different files. As such, we would need > d/u/.metadata. Having data relevant for *binary* packages in a dir named *upstream* does not sound very logical for me. > For d/u/edam we had the concept of a summary representing the packages as a > whole and then subsections for every binary. I admit I do not fully understand the edam data. I guess the only reason that we are not facing issues with these data is that they are just stored in UDD and the only (non-)use case is some query that exports the data again. I doubt that anybody has done some QA on the output. > I kind of liked it the way it > is, but maybe separating that out to different files would also be > appropriate. Could there be an option to do it either way? Again: I think that what we implemented for citations (Debian-Package field) which is documented in Wiki[1] is absolutely sufficient to solve the problem we have. I see no reason to invent something else. The only thing that we should think about is the data storage model: Do we use another column as in the bibref table or should the importer translate the data right to binary packages according to the algorithm above: If source package = binary package if nothing else is specified. Use Debian-Package as binary package name otherwise. It depends a bit from the applications that will consume that data. For the moment it is only the Blends web sentinel which is rather binary package centric. The bibref table layout is rather a hack I created afterwards after we were running in the perfectly same problem as we have now with references. May be a binary package based table layout is more sensible. > I cannot judge how much of a hassle it is to fiddle anything like that into > the UDD. What do you think? I keep on thinking that the established method is not much of a hassle
Porting to Bio-Linux and publicity work (Was: RRID update on salsa on packages starting with A+B)
Hi, On Wed, Apr 04, 2018 at 02:36:57PM +0200, Steffen Möller wrote: > > In my PoV there is not too much of a conceptional difference between porting > to Bio-Linux and having backports within Debian. We need to address both. > Just who should do all that. Backporting to Debian stable is a well established procedure. While we should keep in mind some automatic process, I'd happily work down a list of packages. :-) > Since Debian Med takes about every opportunity that it is just a regular > part of Debian, we somehow do not have any home page since there is the > Debian home page already. Well, we have the terribly outdated and unmaintained https://www.debian.org/devel/debian-med/ > As such there is also no such thing like a page > where to distribute any Debian Med-specific news. Closest is possibly > > https://blends.debian.org/med/ That's at least not outdated since basically auto-generated. ;-) > and http://debian-med.alioth.debian.org/ . Outdated and unmaintained as well and will vanish in one month with the shutdown of Alioth anyway. > Nobody truly wants to read through our Wiki page on > https://wiki.debian.org/DebianMed . Outdated and unm... (you guess it :-() > We have http://debianmed.blogspot.de/ with latest news from 2014. I admit I lost motivation when realising that I was the only one posting there and kept on what I feel my time better spent: Coding for QA, bugfixing and packaging new stuff. > > I've listened to Andreas: I intend to create a "bio-linux-desktop" > > meta-package modelled on the Debian-Med/Bio* tasks that are now being > > updated to include some 'missing' packages that were only in Bio-Linux. > > We should think about adding the version in Ubuntu and Bio-Linux to show up > among the versions in the task pages. I would not know how to implement > that, admittedly. We could either add this as an ordinary Debian Med task (which means it gets a 'med-' prefix or it is a separate package and is listed as any other regular package. Help is granted for both options whatever you decide. If you are fine with integrating into Debian Med tasks its just a matter of creating a task file according to the examples in https://salsa.debian.org/blends-team/med/tree/master/tasks If you want to add things like desktop backgrounds and other stuff this can be done as well. Just ask here if in trouble. Kind regards Andreas. -- http://fam-tille.de
Re: RRID update on salsa on packages starting with A+B
Hi Tony, On 4/3/18 1:59 PM, Tony Travis wrote: On 03/04/18 11:27, Steffen Möller wrote: [...] This is a bit of a side-track from the core of this thread. Maybe we would have Tony describing our achievements one they are manifesting in Bio-Linux. And if we have a look at https://salsa.debian.org/dashboard/milestones ? Maybe we can use those as an anchor for achievements from which news could be generated in an easier way, not necessarily by us. [...] Yes, I would be happy to do that. Yippee. I see five bits, there may be more: A) New bits for Bio-Linux that its new release features B) New bits for Bio-Linux that shall be coming at some future point C) New bits for Debian and its derivative distributions that have been established D) New bits for Debian and its derivative distributions that are currently being worked on E) New bits for Debian and its derivatives that are currently being discussed on the Sprint(s) or mailing list(s). In an ideal world we would see a lot moving from E to A and from B to E, so the effort to describe this all would be mostly done only once :) I know, it will not work, let alone because the audiences are different. In my PoV there is not too much of a conceptional difference between porting to Bio-Linux and having backports within Debian. We need to address both. Just who should do all that. Since Debian Med takes about every opportunity that it is just a regular part of Debian, we somehow do not have any home page since there is the Debian home page already. As such there is also no such thing like a page where to distribute any Debian Med-specific news. Closest is possibly https://blends.debian.org/med/ and http://debian-med.alioth.debian.org/ . Nobody truly wants to read through our Wiki page on https://wiki.debian.org/DebianMed . We have http://debianmed.blogspot.de/ with latest news from 2014. So, I have no immediate idea about how to improve on it all. I'm now only doing minimal maintenance work on Bio-Linux 8, based on Ubuntu 14.04 LTS (Trusty) while I start work on Bio-Linux 9, based on Ubuntu-MATE 18.04 LTS (Bionic). I've got the 18.04 Ubuntu-MATE beta .iso and I've started work remastering it for Bio-Linux using "customizer": https://github.com/kamilion/customizer I cannot judge. The readme reads fine. I plan to base Bio-Linux 9 on Debian-Med + Bioconda That is good. Please consider to also install the singularity and docker clients. And the cwltool. and would like to start adding Ubuntu 18.04 (Bionic) versions of Debian-Med packages to the Debian-Med PPA if nobody objects. I also want to drop ALL the 'bad' NEBC packages (i.e. the binary-only packages that Bela and Tim used initially to migrate from Debian testing (Sarge) to Ubuntu 6.06 LTS. Yip. I've listened to Andreas: I intend to create a "bio-linux-desktop" meta-package modelled on the Debian-Med/Bio* tasks that are now being updated to include some 'missing' packages that were only in Bio-Linux. We should think about adding the version in Ubuntu and Bio-Linux to show up among the versions in the task pages. I would not know how to implement that, admittedly. Best, Steffen
d/u/metadata for binary or source tree Re: RRID update on salsa on packages starting with A+B
On 4/3/18 5:09 PM, Andreas Tille wrote: On Tue, Apr 03, 2018 at 12:27:08PM +0200, Steffen Möller wrote: There is a daily cron job parsing Salsa directories. Fine. Somewhere there is (or should be :o) ) a documentation how this page is crafted. On our Wiki? Let us then have a link to that page. May be this https://blends.debian.org/blends/apa.html#datagathering (A.7.) could be a first shot on this problem. One half done. The invitation to contribute to salsa and the screenshots and translations is missing. Could branches for your cron job's autodock checkout differ? The page was updated this morning but yet not references. Or is there a second directory "autodock" when the source package name is "autodocksuite" (because of the joint autogrid tool)? That's not about branches. As previously said: Registry data are per source package currently. There is no means in the registry data table to map an entry to a binary package. Thus autodock *and* autogrid are missing registry data both. There was one d/u/metadata file that assigned different references IIRC to different binaries of that source package by inventing a sub-hierarchy. This seems to indicate that this is not only an issue for the registry entries. How about the following: * d/u/metadata always refers to the source tree as a whole * d/u/metadata also refers to the binary with the same name as the source tree. * information in d/u/metadata associated with a particular set of binaries with the same or different names shall be listed in a "binary: " attribute Admittedly, I see some issues with that. The notion of a reference binary for a package with many binaries would be helpful for Debian in general. This would prevent something like the Massxpert entry on our task list that describes itself as a transition package. But this also means that such notion about, say, "end-user relevant" packages vs technical helper packages because of arch-independency or libraries etc, should be declared in d/control. Another concern of mine is that we typically do not tag any data for being specific for something. We put it in different files. As such, we would need d/u/.metadata. For d/u/edam we had the concept of a summary representing the packages as a whole and then subsections for every binary. I kind of liked it the way it is, but maybe separating that out to different files would also be appropriate. Could there be an option to do it either way? I cannot judge how much of a hassle it is to fiddle anything like that into the UDD. What do you think? Best, Steffen
