Bugs closed in team help

[Andreas Tille]

Hi Thorsten,

I'm not sure whether you consider Debichem team bugs as valid targets
for the advent calendar but I provided some help on a package that shows
up on our tasks list[1] and closed  #669296 and #872431.

Kind regards

   Andreas.

[1] https://blends.debian.org/med/tasks/bio#garlic

-- 
http://fam-tille.de

Re: December

[Andreas Tille]

Hi Aaron,

On Fri, Dec 01, 2017 at 10:56:57AM -0500, Aaron M. Ucko wrote:
> 
> Hi, Andreas.  Although Cn3D++ comes from the same overarching tree
> (NCBI's C++ Toolkit) as BLAST+, it is a separate project.  The packaging
> work done for BLAST+ would make for a decent starting point, though.

Since as far as I know you are the team member with the best insight
into this code and your previous excuse that the build takes so long on
your machine should be not valid any more - would you volunteer to take
over this task?
 
> Meanwhile, what ever happened with https://bugs.debian.org/682042 ? ;-)

Good question - but I think we should not mix to different issues in one
discussion.  So I droped this bug from CC. 

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: SVN to Git migration status

[Thorsten Alteholz]

Hi everybody,

On Fri, 1 Dec 2017, Andreas Tille wrote:

   * I never liked the split of one upstream source into lots of SVN
 checkouts in different source packages.  Those who are working on
 that set of packages need to do stupid repeated work for no good
 reason and I really regret that I added myself as Uploader which
 seems to be a good reason for other Uploaders to leave with this
 kind of boring work they introduced in the first place


when I did some work on these packages, only the released versions did 
have a tarball, whereas all the release candidates only existed as tags in 
the repositories.
Meanwhile I only see a source tarball for 1.5.6, but there are release 
tags for 1.5.7 and 1.6.0 ...



Well. It is not _that_ easy since in general our ftpmasters like to have
this all separated.


Erm, why?  There is a *single* download tarball.  Since when asks
ftpmaster for separating its content?


ftpmasters don't like a tarball of tarballs.

   Thorsten

Re: December

[Aaron M. Ucko]

Andreas Tille  writes:

>> I would like to mention #225651 [5] here, as this seems to be the oldest one
>> that needs some help (at least a proper closing).
>
> Pinging Aaron explicitly to refresh his statement given several years ago.

Hi, Andreas.  Although Cn3D++ comes from the same overarching tree
(NCBI's C++ Toolkit) as BLAST+, it is a separate project.  The packaging
work done for BLAST+ would make for a decent starting point, though.

Meanwhile, what ever happened with https://bugs.debian.org/682042 ? ;-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Re: CMake help needed to enable hdf5 for gatb-core (Was: [MoM] Re: gatb-core packaging)

[Andreas Tille]

Hi Olivier,

On Thu, Nov 30, 2017 at 07:18:59PM +0100, Olivier Sallou wrote:
> >> compilation fails later on on json.hpp, but this is an other issue
> you removed, for copyright I think, the json.hhp (coming from thirdparty
> dir).
> It is used to manage json in gatb. The only json.hpp I found in debian
> is not compatible.
> So I think you will need to keep the 3rd party code (the hpp file) for
> the json part, else will need lots of code rewrites to use an other lib.
> This json 3rd party has a public domain license.

Hmmm, repackaged the just released version 1.4.0 and left jsoncpp in.  The
build fails anyway and I wonder whether those

cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]

are the reason for the failure and how to sensibly fix this.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: SVN to Git migration status

[Andreas Tille]

Hi Steffen,

On Fri, Dec 01, 2017 at 02:06:52PM +0100, Steffen Möller wrote:
> > as you know we need to be prepared that when Alioth is moved to some new
> > system SVN will not be available any more.  So I was busy to migrate
> > close to all our packages from SVN to Git.
> 
> That was a tremendous effort.

Yes. :-P

> Many thanks, Andreas. I am confident
> the gitlab environment when it eventually comes will attract many
> new contributions. I am confident this was worth it.

I also think that using Git exlusively is an enhancement and that the
fact that we are now forced to do the step is a positive thing.
 
> >Close to all means we have
> > the follwing remainings:
> > 
> >  r-cran-rlumshiny (Git repository created but I'd like to upload the
> >latest version and some new dependencies are just
> >missing)
> >  mgltools
> This is on me.

:-)

> > My motivation for the latter is quite low due to the following reasons:
> > 
> >* RC-buggy (#855494 :-()
> This should have been addressed with that one upload of mine that apparently
> had been lost before when the bug was addressed by upstream about two years
> ago.

But the program does not yet start. :-(

> >* Inclear situation what is latest upstream
> >   ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855494#40 )
> Indeed.

I even removed the Id "Sargis Dallakyan " from the
Uploaders field since the address bounces.  I have no idea whether we
get continuous support from upstream (which does not seem to be the
case considering that the download page keeps on pointing to a version
which they claim outdated. :-( :-( :-(

> >* I never liked the split of one upstream source into lots of SVN
> >  checkouts in different source packages.  Those who are working on
> >  that set of packages need to do stupid repeated work for no good
> >  reason and I really regret that I added myself as Uploader which
> >  seems to be a good reason for other Uploaders to leave with this
> >  kind of boring work they introduced in the first place
> Well. It is not _that_ easy since in general our ftpmasters like to have
> this all separated.

Erm, why?  There is a *single* download tarball.  Since when asks
ftpmaster for separating its content?

> >* My motivation is generally lower to work on non-free packages
> 
> Well. Yes.

Does this mean you volunteer to do the remaining SVN -> Git migrations
and even more importantly fix bug #855494?  If this bug is not fixed in
a timely manner I'd vote for removal of the packages.  (BTW, I also
migrated some removed packages to keep the packaging history in case the
packaging effort might be continued in the future - no idea whether you
intent to do this.)

Kind regards

  Andreas.

PS: If the package should be kept we might ask upstream whether they might
consider a free license to motivate others maintaining obviously
orphaned software ...

 
> > 
> > I would really love if somebody else would volunteer to take over these
> > packages to migrate them from SVN to Git.  The fact that somebody is
> > willing to spent the time to work on the packages would be a proof that
> > there is some real interest and we should not drop them at all.  The
> > migration process is described here
> > 
> > https://debian-med.alioth.debian.org/docs/policy.html#subversion-to-git
> > 
> > You need to patch the onvert_svn_2_git and replace
> > 
> > export SVN_URL=svn://svn.debian.org/svn/debian-med/trunk/packages/
> > 
> > by
> > 
> > export 
> > SVN_URL=svn://svn.debian.org/svn/debian-med/trunk/packages/mgltools
> > 
> > since the packages are in a subdirectory.
> > 
> > What else do I intend to migrate?
> > 
> > We have several unfinished packaging stuff and I intend to check each
> > single one whether it might make sense to move it to Git.  Our tasks
> > pages are displaying this information and I'd love to keep it but a
> > general review makes probably sense.  So we should be left with a
> > basically empty SVN after the cleanup.  Every hint about software which
> > is worth moving to Git or simply can be removed from SVN would be
> > welcome.
> > 
> > BTW, since we now have removed nearly all existing packages I intend to
> > remove the remaining dirs containing the README.status files to help
> > keeping a better overview.  Every interested developer should know how
> > to find the new VCS location even without those README.status files.
> > 
> > Kind regards
> > 
> >Andreas.
> > 
> 

-- 
http://fam-tille.de

Re: SVN to Git migration status

[Steffen Möller]

On 01.12.17 11:23, Andreas Tille wrote:

Hi,

as you know we need to be prepared that when Alioth is moved to some new
system SVN will not be available any more.  So I was busy to migrate
close to all our packages from SVN to Git.



That was a tremendous effort. Many thanks, Andreas. I am confident
the gitlab environment when it eventually comes will attract many
new contributions. I am confident this was worth it.



   Close to all means we have
the follwing remainings:

 r-cran-rlumshiny (Git repository created but I'd like to upload the
   latest version and some new dependencies are just
   missing)
 mgltools

This is on me.


My motivation for the latter is quite low due to the following reasons:

   * RC-buggy (#855494 :-()
This should have been addressed with that one upload of mine that 
apparently had been lost before when the bug was addressed by upstream 
about two years ago.

   * Inclear situation what is latest upstream
  ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855494#40 )

Indeed.

   * I never liked the split of one upstream source into lots of SVN
 checkouts in different source packages.  Those who are working on
 that set of packages need to do stupid repeated work for no good
 reason and I really regret that I added myself as Uploader which
 seems to be a good reason for other Uploaders to leave with this
 kind of boring work they introduced in the first place
Well. It is not _that_ easy since in general our ftpmasters like to have 
this all separated.

   * My motivation is generally lower to work on non-free packages


Well. Yes.

Best,

Steffen



I would really love if somebody else would volunteer to take over these
packages to migrate them from SVN to Git.  The fact that somebody is
willing to spent the time to work on the packages would be a proof that
there is some real interest and we should not drop them at all.  The
migration process is described here

https://debian-med.alioth.debian.org/docs/policy.html#subversion-to-git

You need to patch the onvert_svn_2_git and replace

export SVN_URL=svn://svn.debian.org/svn/debian-med/trunk/packages/

by

export SVN_URL=svn://svn.debian.org/svn/debian-med/trunk/packages/mgltools

since the packages are in a subdirectory.

What else do I intend to migrate?

We have several unfinished packaging stuff and I intend to check each
single one whether it might make sense to move it to Git.  Our tasks
pages are displaying this information and I'd love to keep it but a
general review makes probably sense.  So we should be left with a
basically empty SVN after the cleanup.  Every hint about software which
is worth moving to Git or simply can be removed from SVN would be
welcome.

BTW, since we now have removed nearly all existing packages I intend to
remove the remaining dirs containing the README.status files to help
keeping a better overview.  Every interested developer should know how
to find the new VCS location even without those README.status files.

Kind regards

   Andreas.

SVN to Git migration status

[Andreas Tille]

Hi,

as you know we need to be prepared that when Alioth is moved to some new
system SVN will not be available any more.  So I was busy to migrate
close to all our packages from SVN to Git.  Close to all means we have
the follwing remainings:

r-cran-rlumshiny (Git repository created but I'd like to upload the
  latest version and some new dependencies are just
  missing)
mgltools

My motivation for the latter is quite low due to the following reasons:

  * RC-buggy (#855494 :-()
  * Inclear situation what is latest upstream
 ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855494#40 )
  * I never liked the split of one upstream source into lots of SVN
checkouts in different source packages.  Those who are working on
that set of packages need to do stupid repeated work for no good
reason and I really regret that I added myself as Uploader which
seems to be a good reason for other Uploaders to leave with this
kind of boring work they introduced in the first place
  * My motivation is generally lower to work on non-free packages

I would really love if somebody else would volunteer to take over these
packages to migrate them from SVN to Git.  The fact that somebody is
willing to spent the time to work on the packages would be a proof that
there is some real interest and we should not drop them at all.  The
migration process is described here

   https://debian-med.alioth.debian.org/docs/policy.html#subversion-to-git

You need to patch the onvert_svn_2_git and replace

   export SVN_URL=svn://svn.debian.org/svn/debian-med/trunk/packages/

by

   export SVN_URL=svn://svn.debian.org/svn/debian-med/trunk/packages/mgltools

since the packages are in a subdirectory.

What else do I intend to migrate?

We have several unfinished packaging stuff and I intend to check each
single one whether it might make sense to move it to Git.  Our tasks
pages are displaying this information and I'd love to keep it but a
general review makes probably sense.  So we should be left with a
basically empty SVN after the cleanup.  Every hint about software which
is worth moving to Git or simply can be removed from SVN would be
welcome.

BTW, since we now have removed nearly all existing packages I intend to
remove the remaining dirs containing the README.status files to help
keeping a better overview.  Every interested developer should know how
to find the new VCS location even without those README.status files.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: build failure on sparc64 of python-biopython

[olivier sallou]

Le ven. 1 déc. 2017 à 11:03, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> a écrit :

> Hi Olivier!
>
> On 12/01/2017 09:24 AM, olivier sallou wrote:
> > latest release of python-biopython fails during tests on sparc64 arch
> with a *Bus error* (works fine on other archs)
> > I have no idea what this could be related to. How could we debug this?
> This is most likely a result of this particular bug in the Python
> interpreter which affects sparc and sparc64 [1].
>
> Does your package happen to use the hashing function in Python
> which fails in the Python testsuite with a SIGBUS?
>
well,  I do not really know as it seems to happen in a package dependancy
call and do not know the software itself.

Olivier


>
> PS: Please don't use $a...@buildd.debian.org for such bug reports but
>  rather debian-$a...@lists.debian.org. The former is for buildd
>  issues only, the latter is for bug reports like yours as it reaches
>  every SPARC porter not just the buildd maintainers.
>
> Adrian
>
> > [1] https://bugs.gentoo.org/636400
>
> --
>   .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>`-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: build failure on sparc64 of python-biopython

[John Paul Adrian Glaubitz]

Hi Olivier!

On 12/01/2017 09:24 AM, olivier sallou wrote:

latest release of python-biopython fails during tests on sparc64 arch with a 
*Bus error* (works fine on other archs)
I have no idea what this could be related to. How could we debug this?

This is most likely a result of this particular bug in the Python
interpreter which affects sparc and sparc64 [1].

Does your package happen to use the hashing function in Python
which fails in the Python testsuite with a SIGBUS?

PS: Please don't use $a...@buildd.debian.org for such bug reports but
rather debian-$a...@lists.debian.org. The former is for buildd
issues only, the latter is for bug reports like yours as it reaches
every SPARC porter not just the buildd maintainers.

Adrian


[1] https://bugs.gentoo.org/636400


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: December

[Andreas Tille]

Hi again,

after having fixed the next bug #883047 - hey it was tagged patch and the
upload had a diff as simple as


diff --git a/debian/changelog b/debian/changelog
index d9eab55..2e9a79b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,19 @@
-canu (1.6+dfsg-2) UNRELEASED; urgency=medium
+canu (1.6+dfsg-2) unstable; urgency=medium
 
+  * Team upload
+
+  [ Steffen Moeller ]
   * debian/upstream/metadata
 - yamllint cleanliness
 - added references to registries
 
- -- Steffen Moeller   Sat, 18 Nov 2017 22:36:53 +0100
+  [ Andreas Tille ]
+  * Add mhap to Build-Depends (thanks for the patch to Steve Langasek
+)
+Closes: #883047
+  * Standards-Version: 4.1.1
+
+ -- Andreas Tille   Fri, 01 Dec 2017 09:01:30 +0100
 
 canu (1.6+dfsg-1) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index 8850c99..c791a16 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,8 @@ Build-Depends:
libmeryl-dev,
 # For File::Path
libfilesys-df-perl,
-Standards-Version: 4.1.0
+   mhap (>= 2.1)
+Standards-Version: 4.1.1
 Homepage: http://canu.readthedocs.org/en/latest/
 Vcs-Git: https://anonscm.debian.org/git/debian-med/canu.git
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/canu.git



(... so why did **you** not harvested this low hanging fruit?)

I want to add that there list of bugs[1] contains several titled:

   Please provide autopkgtest

I had injected these bugs for potential Outreachy students as task to
prove skills.  Unfortunately our candidate for the winter period was not
accepted but we could work on these bugs anyway to come closer to the
goal to have all Debian Med packages featuring autopkgtests.  I'll file
more of this kind of bugs if I see that the existing ones are grabbed.

Kind regards

   Andreas.

On Fri, Dec 01, 2017 at 08:39:56AM +0100, Andreas Tille wrote:
> Hi everybody,
> 
> its really that simple to close a bug which I'm doing here without a line
> of code closing my first bug in this mail after having checked that zstd
> has hit backports and adding "882244-d...@bugs.debian.org" to the list of
> receivers of this mail.
> 
> Not all bugs are *that* simple to solve but **everybody** is kindly
> invited to head for the simple ones right now.
> 
> On Thu, Nov 30, 2017 at 12:44:39PM +0100, Thorsten Alteholz wrote:
> > Hi everybody,
> > 
> > this time of the year has come again and in order to carry on a tradition
> > (it is the seventh time this year), I want to remind everybody of our
> > combined efforts to take care of some poor souls.
> > 
> > The days are closing in, the year is drawing to an end and we should think
> > of all those, that are not around with their own kind. Again, during the
> > last few months, lots of volunteers all around the world tracked down those
> > poor souls and put their cases in the database. We should take care of those
> > needy. This year, there are about 180 cases which are relevant to Debian
> > Med[1] (this time 21 are serious[2]). So please feel pity for them and allow
> > the transition of as many as possible poor souls to their final destination,
> > the retirement community in the Archive. Maybe some of the "won't fix" can
> > be resolved as well.
> 
> We should definitely try to fix the serious ones - even if they are mostly
> not that simple.
>  
> > Furthermore I would like to mention another page[3] with lots of information
> > about Debian Med packages. Besides the list of RC bugs you can also see
> > packages that can not be built on a Debian architecture, packages that are
> > not allowed to migrate from unstable to testing (and thus won't be included
> > in the next release) and packages with a new upstream version. I think those
> > packages need some care as well.
> 
> Definitely.
>  
> > As soon as I get the notice of a closed case I will record that in our
> > Advent calendar[4]. In contrast to normal calendars, let us fill this
> > special one with lot s of good deeds. Maybe we can hide at least one number
> > of a closed case behind every door.
> > 
> > I would like to mention #225651 [5] here, as this seems to be the oldest one
> > that needs some help (at least a proper closing).
> 
> Pinging Aaron explicitly to refresh his statement given several years ago.
>  
> > Have fun,
> > Thorsten
> 
> Thanks for the fun and all your work
> 
> Andreas. 
>  
> > [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=debian-med-packaging%40lists.alioth.debian.org=no=yes=yes=fixed=done
> > [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=debian-med-packaging%40lists.alioth.debian.org=no=done=critical=grave=serious
> > [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org
> > [4]http://debian-med.alteholz.de/advent-2017
> > [5]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225651
> > 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

build failure on sparc64 of python-biopython

[olivier sallou]

Hi,
latest release of python-biopython fails during tests on sparc64 arch with
a *Bus error* (works fine on other archs)
I have no idea what this could be related to. How could we debug this?

Thanks

Olivier