uploading libzstd...
[ explicitly CCing xnox, as I somehow doubt he follows d-med@ ] [ though I hope the other people mentioned hereafter are subscribed… ] So, to —putting it bluntly— cut the crap I'm seeing these last days around libzstd, I'm finalizing the upload. I'm also deleting the following tags from the git repositories: * debian/1.3.3+dfsg-2 * debian/1.3.4+dfsg-1 * debian/1.3.4+dfsg-2 Alexandre Mestiashvili, Dimitri John Ledkov, Andreas Tille: please remove them from your local checkout. I also would like to ask you to please refrain to push tags for things you are not 100% sure are going to be accepted (in case you push the tag before receiving the accepted email, as it seems to be the case here). Alexandre Mestiashvili: you prepared the last updates (referring to importing the new upstream releases), but it's clear you never did a copyright review. Please always check what you imported for updates in the copyright or the licensing details. Also looking at some files it seems the generic license of the whole package is "BSD-3-clause or GPL-2", and I couldn't find any reference in the whole software of the word "patent" (except in the GPL2 text) - could you please review this part? (Incidentally, I also wonder about the legal meaning of things like Copyright (c) 2016-present I doubt that means anything really. Alex Mestiashvili, Sascha Steinbiss, Kevin Murray: there are a bunch of patches without Forwarded header, that seems like have been there for a while. Please do some upstreaming work there. I removed the hurd-i386 patch, according to the upstream bug report the actual issue has been fixed now (didn't test myself though). Dimitri Jonhn Ledkov: I reverted your udeb addition. Please do as Cyril Brulebois says: write a patch, submit it as a bug X-Debbugs-CCing d-boot@ (and him) for an ACK, once you get it commit and upload. Then, the actual issue, the symbol files. Alexandre Mestiashvili: it's not acceptable to just happily remove symbols. I don't understand what happened as the git log of that file is noisy, but looking at a simple debdiff the following symbols disapperead: - ZSTD_initCCtxParams@Base 1.3.2 - ZSTD_initCCtxParams_advanced@Base 1.3.2 - ZSTD_resetCCtxParams@Base 1.3.2 Where did they went? I can't sensibly upload something that is removing symbols (i.e. breaking the ABI, but it seems to me that it also break the API?) without changing SONAME or giving a proper explanation. I'll be doing some git wrestling and cutting a 1.3.3+dfsg-2 with the commits that can go in (and then merging in master). The last point is a blocker for an update to 1.3.4. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: uploading libzstd...
On Sat, Apr 21, 2018 at 11:13:42AM +0200, Mattia Rizzolo wrote: > Alexandre Mestiashvili, Dimitri John Ledkov, Andreas Tille: please > remove them from your local checkout. I also would like to ask you to > please refrain to push tags for things you are not 100% sure are going > to be accepted (in case you push the tag before receiving the accepted > email, as it seems to be the case here). Dimitri: incidentally, while also pushing you happily uploaded 1.3.3+dfsg-2ubuntu1 to ubuntu (so an ubuntu diff on top of 1.3.3+dfsg-2), a debian version that never existed in practice. And as a matter of fact I'm uploading it now, and will have a totally different content than the one you claimed to have based your ubuntu upload on. Please also refrain from doing this. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: uploading libzstd...
Hi Mattia, thanks for diving into this! Just quickly replying as my name was mentioned... [...] > Alex Mestiashvili, Sascha Steinbiss, Kevin Murray: there are a bunch of > patches without Forwarded header, that seems like have been there for a > while. Please do some upstreaming work there. There are two patches with my name in the Author field. One can be removed (0009-Add-shebang-for-scripts.patch) as upstream seems to have made the fix already and the patch would only duplicate the shebang line now. As for the other one (0008-Address-embedded-zlib.patch), this was merely a workaround for zlibWrapper not to build its examples with the embedded gz*.c zlib copies -- something specific to the Debian policy which I usually do not consider mandatory to forward to upstream. The patch description could use some love though. I'll address these minor issues later today, thanks for the heads-up. When do you want to make the upload? Cheers Sascha
Re: uploading libzstd...
On 21 April 2018 at 10:29, Mattia Rizzolo wrote: > On Sat, Apr 21, 2018 at 11:13:42AM +0200, Mattia Rizzolo wrote: >> Alexandre Mestiashvili, Dimitri John Ledkov, Andreas Tille: please >> remove them from your local checkout. I also would like to ask you to >> please refrain to push tags for things you are not 100% sure are going >> to be accepted (in case you push the tag before receiving the accepted >> email, as it seems to be the case here). > > Dimitri: incidentally, while also pushing you happily uploaded > 1.3.3+dfsg-2ubuntu1 to ubuntu (so an ubuntu diff on top of > 1.3.3+dfsg-2), a debian version that never existed in practice. And as > a matter of fact I'm uploading it now, and will have a totally different > content than the one you claimed to have based your ubuntu upload on. > Please also refrain from doing this. Currently, Ubuntu is frozen for a release, once it is open for uploads again I will reconcile packaging in ubuntu following normal ubuntu procedures, with corrected attributions and origin of changes, as matching the most up to date package history. You need not worry about changes to the Debian packaging history, from the point of Ubuntu package history, as divergent packaging versions do happen in uUuntu wrt. merging from unstable/experimental from time to time, thus e.g. none of the Ubuntu tools would be confused by your new upload. Not sure why you'd upload 1.3.3+dfsg-2 today, instead of e.g. uploading 1.3.4+dfsg-1 instead. But I guess that's your prerogative. -- Regards, Dimitri.
Re: uploading libzstd...
On Sat, Apr 21, 2018 at 11:15:28AM +0100, Dimitri John Ledkov wrote: > matching the most up to date package history. You need not worry about > changes to the Debian packaging history, from the point of Ubuntu > package history, as divergent packaging versions do happen in uUuntu > wrt. merging from unstable/experimental from time to time, thus e.g. > none of the Ubuntu tools would be confused by your new upload. Well, I actually expect MoM to not notice a new merge should be done. (I am a MOTU as well, I have some background on the ubuntu processes) > Not sure why you'd upload 1.3.3+dfsg-2 today, instead of e.g. > uploading 1.3.4+dfsg-1 instead. But I guess that's your prerogative. Please read my first email, around the bottom. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: uploading libzstd...
On Sat, Apr 21, 2018 at 11:56:42AM +0200, Sascha Steinbiss wrote: > thanks for diving into this! Just quickly replying as my name was > mentioned... :) > I'll address these minor issues later today, thanks for the heads-up. Thank you! > When do you want to make the upload? I already did. Please stage those changes in git master for the next upload! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Qlustar 10 available - Now 100% Open Source
Hi, Q-Leap previously offered to support Debian-Med and they attended at least one Debian-Med Sprint. However, their product licensing policy was restrictive and I decided not to use it. However, that has now changed: > https://qlustar.com/news/qlustar-10-available-now-100-open-source Time for a re-think about Qlustar? Tony. -- Minke Informatics Limited, Registered in Scotland - Company No. SC419028 Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK) tel. +44(0)19755 63548http://minke-informatics.co.uk mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk
Qlustar 10 available - Now 100% Open Source
Hi, Q-Leap sponsorted the 2014 Debian-Med Sprint in Stonehaven and attended the 2015 Sprint in St. Malo:: > https://qlustar.com/news/qlustar-biostack-debianmed-sprint-2015 I'm going to try it out, Tony. -- Minke Informatics Limited, Registered in Scotland - Company No. SC419028 Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK) tel. +44(0)19755 63548http://minke-informatics.co.uk mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk
Re: uploading libzstd...
Hi Mattia, > Alexandre Mestiashvili: you prepared the last updates (referring to > importing the new upstream releases), but it's clear you never did a > copyright review. Please always check what you imported for updates in > the copyright or the licensing details. Let me please elaborate my point of view. libzstd is team-maintained, and because I didn't see any changes in the copyright/licensing for the new upstream versions I obviously didn't think on checking the copyright. Especially taking into account that the package has already been successfully uploaded multiple times. > I removed the hurd-i386 patch, according to the upstream bug report the > actual issue has been fixed now (didn't test myself though). Upstream solved only part of the issue. One of the tests takes too long or too much memory on hurd as far as I remember and the patch was addressing this problem. The Forwarded header doesn't apply anymore for the current patch but it was correct for the initial version. > Then, the actual issue, the symbol files. > Alexandre Mestiashvili: it's not acceptable to just happily remove > symbols. I don't understand what happened as the git log of that file > is noisy, but looking at a simple debdiff the following symbols > disapperead: > > - ZSTD_initCCtxParams@Base 1.3.2 > - ZSTD_initCCtxParams_advanced@Base 1.3.2 > - ZSTD_resetCCtxParams@Base 1.3.2 > > Where did they went? I can't sensibly upload something that is removing > symbols (i.e. breaking the ABI, but it seems to me that it also break > the API?) without changing SONAME or giving a proper explanation. My bad. It seems that I don't understand enough how to properly handle symbols. I just was following the manual[0]. I'd really appreciate if somebody would explain what should have been done in order to generate symbols files in this case. First symbols file was generated after building libzstd 1.3.2+dfsg1-1 installing it and running dpkg-deb and dpkg-gensymbols as described here[0]. The last file was generated the same way, I just preserved the versions of already existing symbols. No idea why the 3 symbols above have disappeared. Again I'll be really interested to hear what I did wrong. > > I'll be doing some git wrestling and cutting a 1.3.3+dfsg-2 with the > commits that can go in (and then merging in master). > The last point is a blocker for an update to 1.3.4. > Also I am a bit surprised of the mentoring tone of the message. Thank you for your work but why can't it be resolved by submitting bugs for every single issue as for example Helmut did? Is that the importance of libzstd? Thanks! Alex [0] https://wiki.debian.org/UsingSymbolsFiles
Re: uploading libzstd...
On Sat, Apr 21, 2018 at 05:45:34PM +0200, Alex Mestiashvili wrote: > Let me please elaborate my point of view. libzstd is team-maintained, > and because I didn't see any changes in the copyright/licensing for the > new upstream versions I obviously didn't think on checking the > copyright. Especially taking into account that the package has already > been successfully uploaded multiple times. You prepared (and uploaded yourself) the update to 1.3.3, that's the last occasion an upstream release was imported. I kind of expect people uploading new upstream release to review their copyright and licensing status. > > I removed the hurd-i386 patch, according to the upstream bug report the > > actual issue has been fixed now (didn't test myself though). > > Upstream solved only part of the issue. One of the tests takes too long > or too much memory on hurd as far as I remember and the patch was > addressing this problem. The Forwarded header doesn't apply anymore for > the current patch but it was correct for the initial version. hurd-i386 has been failing with that patch as well, so something else is needed anyway. As a matter of fact, comparing the previous failure with the patch applied and this one, the error is exactly the same, so… > > Then, the actual issue, the symbol files. > > Alexandre Mestiashvili: it's not acceptable to just happily remove > > symbols. I don't understand what happened as the git log of that file > > is noisy, but looking at a simple debdiff the following symbols > > disapperead: > > > > - ZSTD_initCCtxParams@Base 1.3.2 > > - ZSTD_initCCtxParams_advanced@Base 1.3.2 > > - ZSTD_resetCCtxParams@Base 1.3.2 > > > > Where did they went? I can't sensibly upload something that is removing > > symbols (i.e. breaking the ABI, but it seems to me that it also break > > the API?) without changing SONAME or giving a proper explanation. > > My bad. It seems that I don't understand enough how to properly handle > symbols. I just was following the manual[0]. > > I'd really appreciate if somebody would explain what should have been > done in order to generate symbols files in this case. It's not a problem of the .symbols generation process, but rather an upstream issue. Those 3 functions (ZSTD_initCCtxParams, ZSTD_initCCtxParams_advanced, ZSTD_resetCCtxParams) that were part of the public interface have been removed. So one of the following should happen: * the functions are reintroduced * the SONAME is changed * the SONAME stays the same but the name of the binary package is changed * the investigation on those 3 symbols is performed and is declared that those functions were not public in the first place and only leaked accidentally, furthermore no reverse dependency has been using them It's a so called ABI break, and that's the regular procedure that should happen in such cases. Although, I'm afraid I wouldn't know of any specific documentation (wiki?) page that you could look up to have some decent outline on how to handle them... Guess I learned this stuff over the years following along library transitions and other nasty situations ;-) > No idea why the 3 symbols above have disappeared. Again I'll be really > interested to hear what I did wrong. The only wrong thing you did here was to overlook those 3 removal lines: as a rule of thumb lines from a .symbols file should be removed only when the SONAME is changed. > Also I am a bit surprised of the mentoring tone of the message. Thank > you for your work but why can't it be resolved by submitting bugs for > every single issue as for example Helmut did? Is that the importance of > libzstd? mhh, bug about unreleased, git only changes? :) Or what did you mean here? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: uploading libzstd...
On 04/21/2018 06:48 PM, Mattia Rizzolo wrote: > On Sat, Apr 21, 2018 at 05:45:34PM +0200, Alex Mestiashvili wrote: >> Let me please elaborate my point of view. libzstd is team-maintained, >> and because I didn't see any changes in the copyright/licensing for the >> new upstream versions I obviously didn't think on checking the >> copyright. Especially taking into account that the package has already >> been successfully uploaded multiple times. > > You prepared (and uploaded yourself) the update to 1.3.3, that's the > last occasion an upstream release was imported. I kind of expect people > uploading new upstream release to review their copyright and licensing > status. OK. Will be more careful in the future. >>> I removed the hurd-i386 patch, according to the upstream bug report the >>> actual issue has been fixed now (didn't test myself though). >> >> Upstream solved only part of the issue. One of the tests takes too long >> or too much memory on hurd as far as I remember and the patch was >> addressing this problem. The Forwarded header doesn't apply anymore for >> the current patch but it was correct for the initial version. > > hurd-i386 has been failing with that patch as well, so something else is > needed anyway. > As a matter of fact, comparing the previous failure with the patch > applied and this one, the error is exactly the same, so… I guess it's a different issue introduced in 1.3.3. > >>> Then, the actual issue, the symbol files. >>> Alexandre Mestiashvili: it's not acceptable to just happily remove >>> symbols. I don't understand what happened as the git log of that file >>> is noisy, but looking at a simple debdiff the following symbols >>> disapperead: >>> >>> - ZSTD_initCCtxParams@Base 1.3.2 >>> - ZSTD_initCCtxParams_advanced@Base 1.3.2 >>> - ZSTD_resetCCtxParams@Base 1.3.2 >>> >>> Where did they went? I can't sensibly upload something that is removing >>> symbols (i.e. breaking the ABI, but it seems to me that it also break >>> the API?) without changing SONAME or giving a proper explanation. >> >> My bad. It seems that I don't understand enough how to properly handle >> symbols. I just was following the manual[0]. >> >> I'd really appreciate if somebody would explain what should have been >> done in order to generate symbols files in this case. > > It's not a problem of the .symbols generation process, but rather an > upstream issue. > > Those 3 functions (ZSTD_initCCtxParams, ZSTD_initCCtxParams_advanced, > ZSTD_resetCCtxParams) that were part of the public interface have been > removed. > > So one of the following should happen: > > * the functions are reintroduced > * the SONAME is changed > * the SONAME stays the same but the name of the binary package is changed > * the investigation on those 3 symbols is performed and is declared that > those functions were not public in the first place and only leaked > accidentally, furthermore no reverse dependency has been using them > > > It's a so called ABI break, and that's the regular procedure that should > happen in such cases. > Although, I'm afraid I wouldn't know of any specific documentation > (wiki?) page that you could look up to have some decent outline on how > to handle them... Guess I learned this stuff over the years following > along library transitions and other nasty situations ;-) I see now, thanks a lot for the details. > >> No idea why the 3 symbols above have disappeared. Again I'll be really >> interested to hear what I did wrong. > > The only wrong thing you did here was to overlook those 3 removal lines: > as a rule of thumb lines from a .symbols file should be removed only > when the SONAME is changed. Now I got it, also opened an issue: https://github.com/facebook/zstd/issues/ > >> Also I am a bit surprised of the mentoring tone of the message. Thank >> you for your work but why can't it be resolved by submitting bugs for >> every single issue as for example Helmut did? Is that the importance of >> libzstd? > > mhh, bug about unreleased, git only changes? :) > Or what did you mean here? Oh, I see, right, the last upload was rejected. All good now :) Thanks, Alex
Re: uploading libzstd...
On Sat, Apr 21, 2018 at 10:24:47PM +0200, Alex Mestiashvili wrote: > Now I got it, also opened an issue: > https://github.com/facebook/zstd/issues/ Thanks for it! Feel free to tag me (@mapreri - or just notify me somehow) if you'd like to see my input on something there. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
RFS: ChromImpute -- Large-scale systematic epigenome imputation
Hi, Could someone upload it? Thanks. Best, Dylan Package name: chromimpute URL: http://www.biolchem.ucla.edu/labs/ernst/ChromImpute/ License: GPL-2 Description: Large-scale systematic epigenome imputation ChromImpute takes an existing compendium of epigenomic data and uses it to predict signal tracks for mark-sample combinations not experimentally mapped or to generate a potentially more robust version of data sets that have been mapped experimentally. ChromImpute bases its predictions on features from signal tracks of other marks that have been mapped in the target sample and the target mark in other samples with these features combined using an ensemble of regression trees. This package will be maintained by the Debian Med Packaging Team at: https://salsa.debian.org/med-team/chromimpute.git/
