Re: version format for git snapshot

[Thomas Goirand]

On 09/14/2015 07:51 AM, Thomas Koch wrote:
> Hi,
> 
> my upstream tagged 0.4 a year ago and I want to package the current master 
> commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes 
> sense...
> 
> How would you format the upstream part of the packages version number? How 
> about 0.4+24+git+a5e5f9e?
> 
> The git describe output is v0.4-24-ga5e5f9e.
> 
> Is there any established best practice?
> 
> Have a nice week,
> 
> Thomas Koch

git describe is your friend indeed! :)

What I do may be a bit over-engineered:
1.2.3+2015.06.16.git26.9634b76ba5

which of course is:
upstream.release+date.gitnumcommits.sha256

It'd be nice if we could all do the same thing. Not saying that my
version is the best (I wouldn't mind changing for another format), but
having standards is good.

Cheers,

Thomas Goirand (zigo)

Re: version format for git snapshot

[Colin Watson]

On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote:
> How would you format the upstream part of the packages version number? How 
> about 0.4+24+git+a5e5f9e?

I wouldn't put the commit identifier in the package version at all.  It
isn't sortable, so clearly doesn't belong in a version string; it can be
documented in the changelog instead.  I'd put a date in the version.

-- 
Colin Watson   [cjwat...@debian.org]

Re: version format for git snapshot

[Jonas Smedegaard]

Hi Thomas,

Quoting Thomas Koch (2015-09-14 07:51:09)
> my upstream tagged 0.4 a year ago and I want to package the current 
> master commit a5e5f9e that is 24 commits after 0.4. Please assume that 
> this makes sense...
> 
> How would you format the upstream part of the packages version number? 
> How about 0.4+24+git+a5e5f9e?
> 
> The git describe output is v0.4-24-ga5e5f9e.
> 
> Is there any established best practice?

I'd use a single "+", mention revision control system first, and include 
date¹ of latest commit in snapshot (rather than number of commits from 
release - another later snapshot may not be linear progress but from 
another shorter branch, and therefore a lower number).  And then I'd use 
only 7 digits of hash as that's common short-form in git.

Therefore, I'd use this: 0.4+git20150911~ga5e5f9

 - Jonas

¹ In the rare event of making more snapshots same day I'd add a counter 
for my clumsiness - i.e. 0.4+git20150911.1~ga5e5f9

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: [DH] Planning to remove deprecated commands and compat levels in debhelper

[Niels Thykier]

On 2015-09-13 21:02, Matthias Klose wrote:
> [...]
> 
> still using the globbing feature for command line arguments in DH_COMPAT=2 
> mode.
>  Was this re-added in higher levels again?
> 
>   Matthias
> 

Hi Matthias,

Ok, I was not aware of this feature.  To be honest, I suspect it was an
artefact of the old implementation rather than being intentional.
Digging through the documentation and the commit logs, I could not find
any mention of it.

Are you using dh_movefiles here because dh_install does not support wild
arguments?  Or would dh_install not work for you regardless?

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: version format for git snapshot

[Eduard Bloch]

Hallo,
* Thomas Koch [Mon, Sep 14 2015, 07:51:09AM]:
> Hi,
> 
> my upstream tagged 0.4 a year ago and I want to package the current master 
> commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes 
> sense...
> 
> How would you format the upstream part of the packages version number? How 
> about 0.4+24+git+a5e5f9e?
> 
> The git describe output is v0.4-24-ga5e5f9e.

Is -24 a part of upstream version?

I used to incorporate the date... 0.4-24+git+20150914+ga5e5f9e-1 (and you can
still add a modifier to the date if you need another snapshot).

> Is there any established best practice?
> 
> Have a nice week,

Yoo too...
Eduard.

version format for git snapshot

[Thomas Koch]

Hi,

my upstream tagged 0.4 a year ago and I want to package the current master 
commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes 
sense...

How would you format the upstream part of the packages version number? How 
about 0.4+24+git+a5e5f9e?

The git describe output is v0.4-24-ga5e5f9e.

Is there any established best practice?

Have a nice week,

Thomas Koch

Bug#798912: ITP: libmpris2client -- Library to control mpris2 compatible players

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: libmpris2client
  Version : 0.1.0
  Upstream Author : Matias De lellis 
* URL : https://github.com/matiasdelellis/libmpris2client
* License : GPL
  Programming Lang: C
  Description : Library to control mpris2 compatible players

Libmpris2client is a generic library for controlling any mpris2 compatible
player.

Re: interested in (co-)maintaining midori

[Andres Salomon]

On Sun, 13 Sep 2015 20:33:52 -0400
Sergio Durigan Junior  wrote:

> On Wednesday, September 09 2015, I wrote:
> 
> > On Monday, August 24 2015, I wrote:
> >
> >> On Friday, August 14 2015, Andres Salomon wrote:
> >>
>  Your work was done back in June, so if you prefer I can provide
>  patches against your branch to implement/fix the issues I have
>  been working on. It won't really matter much, I think: in the
>  end, we'll have to use the "official" repository anyway and
>  patch it.
>  
> >>>
> >>> That would be highly preferred, simply for reviewing purposes.
> >>> I'm also happy to rewrite parts of my history to, for example,
> >>> not include the -O--buildsystem stuff.  But the existing git
> >>> history is useful, and I'd rather work from that.
> >>
> >> OK, I've done it:
> >>
> >>   
> >>
> >> It's the same link, but the repository is a new one, based on the
> >> official repository.
> >
> > Just another update.
> >
> > I've re-created the repository above (the previous version contained
> > some mistakes, and I thought it made sense to restart from scratch).
> > Now, you can find the latest version of Midori (0.5.11, released a
> > few days ago) along with all the other changes that I had already
> > made.
> >
> > Still builds successfully, and I'm using this latest version without
> > problems.  IOW, everything is ready to be used in Debian, and I'm
> > pretty happy with the current state of the repository.
> 
> One (last?) update.
> 
> I have upgrade/recreated the repository one more time now.  Thadeu
> Cascardo pointed me to two lintian warnings that I had not seen before
> (they're fixed now), and I've cherry-picked Andreas's commits (those
> that import the NMU-0.2 and merge it to master), so now I think
> everything is *really* covered.  Oh, and I've searched the BTS and
> found two bugs that requested a new version to be packaged, so I'm
> closing them in the changelog.  I intend to do a full bug triage once
> the package is back to life.
> 
> Just for the record, I've kept *all* history from the previous git
> branches, so absolutely nothing is deleted nor lost.
> 
> In other words, the package is ready to be re-uploaded.
> 
> Thanks,
> 

Fantastic, thank you!  I'd say go ahead and upload it.  I won't have
time to review it; school teachers here are on strike combined w/
work deadlines mean I lack any free time right now.  I'll check out
your work once my kid's back in school again.

I look forward to grabbing the latest midori from sid.

Re: interested in (co-)maintaining midori

[Thadeu Lima de Souza Cascardo]

On September 13, 2015 9:33:52 PM GMT-03:00, Sergio Durigan Junior 
 wrote:
>On Wednesday, September 09 2015, I wrote:
>
>> On Monday, August 24 2015, I wrote:
>>
>>> On Friday, August 14 2015, Andres Salomon wrote:
>>>
> Your work was done back in June, so if you prefer I can provide
> patches against your branch to implement/fix the issues I have
>been
> working on. It won't really matter much, I think: in the end,
>we'll
> have to use the "official" repository anyway and patch it.
> 

 That would be highly preferred, simply for reviewing purposes.  I'm
 also happy to rewrite parts of my history to, for example, not
>include
 the -O--buildsystem stuff.  But the existing git history is useful,
>and
 I'd rather work from that.
>>>
>>> OK, I've done it:
>>>
>>>   
>>>
>>> It's the same link, but the repository is a new one, based on the
>>> official repository.
>>
>> Just another update.
>>
>> I've re-created the repository above (the previous version contained
>> some mistakes, and I thought it made sense to restart from scratch).
>> Now, you can find the latest version of Midori (0.5.11, released a
>few
>> days ago) along with all the other changes that I had already made.
>>
>> Still builds successfully, and I'm using this latest version without
>> problems.  IOW, everything is ready to be used in Debian, and I'm
>pretty
>> happy with the current state of the repository.
>
>One (last?) update.
>
>I have upgrade/recreated the repository one more time now.  Thadeu
>Cascardo pointed me to two lintian warnings that I had not seen before
>(they're fixed now), and I've cherry-picked Andreas's commits (those
>that import the NMU-0.2 and merge it to master), so now I think
>everything is *really* covered.  Oh, and I've searched the BTS and
>found
>two bugs that requested a new version to be packaged, so I'm closing
>them in the changelog.  I intend to do a full bug triage once the
>package is back to life.
>
>Just for the record, I've kept *all* history from the previous git
>branches, so absolutely nothing is deleted nor lost.
>
>In other words, the package is ready to be re-uploaded.
>
>Thanks,

Thanks, Sergio.

I find the repo and package in a good state for an upload. I will do it 
tomorrow night, if there are no further strong objections.

Thanks Andres for his work as well, and all the others for their past 
contributions.

Cascardo.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: interested in (co-)maintaining midori

[Sergio Durigan Junior]

On Sunday, September 13 2015, Andres Salomon wrote:

>> One (last?) update.
>> 
>> I have upgrade/recreated the repository one more time now.  Thadeu
>> Cascardo pointed me to two lintian warnings that I had not seen before
>> (they're fixed now), and I've cherry-picked Andreas's commits (those
>> that import the NMU-0.2 and merge it to master), so now I think
>> everything is *really* covered.  Oh, and I've searched the BTS and
>> found two bugs that requested a new version to be packaged, so I'm
>> closing them in the changelog.  I intend to do a full bug triage once
>> the package is back to life.
>> 
>> Just for the record, I've kept *all* history from the previous git
>> branches, so absolutely nothing is deleted nor lost.
>> 
>> In other words, the package is ready to be re-uploaded.
>> 
>> Thanks,
>> 
>
> Fantastic, thank you!  I'd say go ahead and upload it.  I won't have
> time to review it; school teachers here are on strike combined w/
> work deadlines mean I lack any free time right now.  I'll check out
> your work once my kid's back in school again.

Thank you for your previous work, too.  I would probably have missed the
NMU if it weren't your repository.

> I look forward to grabbing the latest midori from sid.

Neat.  Please let me know if you notice anything worth mentioning.

Good luck with your deadlines,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: interested in (co-)maintaining midori

[Sergio Durigan Junior]

On Wednesday, September 09 2015, I wrote:

> On Monday, August 24 2015, I wrote:
>
>> On Friday, August 14 2015, Andres Salomon wrote:
>>
 Your work was done back in June, so if you prefer I can provide
 patches against your branch to implement/fix the issues I have been
 working on. It won't really matter much, I think: in the end, we'll
 have to use the "official" repository anyway and patch it.
 
>>>
>>> That would be highly preferred, simply for reviewing purposes.  I'm
>>> also happy to rewrite parts of my history to, for example, not include
>>> the -O--buildsystem stuff.  But the existing git history is useful, and
>>> I'd rather work from that.
>>
>> OK, I've done it:
>>
>>   
>>
>> It's the same link, but the repository is a new one, based on the
>> official repository.
>
> Just another update.
>
> I've re-created the repository above (the previous version contained
> some mistakes, and I thought it made sense to restart from scratch).
> Now, you can find the latest version of Midori (0.5.11, released a few
> days ago) along with all the other changes that I had already made.
>
> Still builds successfully, and I'm using this latest version without
> problems.  IOW, everything is ready to be used in Debian, and I'm pretty
> happy with the current state of the repository.

One (last?) update.

I have upgrade/recreated the repository one more time now.  Thadeu
Cascardo pointed me to two lintian warnings that I had not seen before
(they're fixed now), and I've cherry-picked Andreas's commits (those
that import the NMU-0.2 and merge it to master), so now I think
everything is *really* covered.  Oh, and I've searched the BTS and found
two bugs that requested a new version to be packaged, so I'm closing
them in the changelog.  I intend to do a full bug triage once the
package is back to life.

Just for the record, I've kept *all* history from the previous git
branches, so absolutely nothing is deleted nor lost.

In other words, the package is ready to be re-uploaded.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

RFH: protobuf packaging team formed

[Robert Edmonds]

Hi,

I'm announcing the formation of the Debian protobuf packaging team that
will be responsible for packaging the src:protobuf package.  (And maybe
closely related packages like src:grpc, if the maintainers are
interested.)

Iustin Pop has maintained src:protobuf in the past, and I've maintained
it through the 2.5.x and 2.6.x upstream releases, but I don't have much
time to devote to it in the near future, so after receiving mail from
several developers interested in helping package the upcoming 3.x
release I'm turning it over to a team.  Anyone interested in helping to
package the upcoming upstream 3.x releases is welcome to join the Alioth
group and mailing list:

https://alioth.debian.org/projects/pkg-protobuf/

https://lists.alioth.debian.org/mailman/listinfo/pkg-protobuf-devel

The upcoming 3.x release has gotten more complicated to package, mostly
through the addition of new language bindings.  It also introduces a new
backwards-incompatible language syntax "proto3", while still supporting
the deprecated "proto2" syntax.  Upstream says the following about
proto3 vs proto2:

We recommend that new Protocol Buffers users use proto3. However, we
do not generally recommend that existing users migrate from proto2
from proto3 due to API incompatibility, and we will continue to
support proto2 for a long time.

Upstream doesn't specify exactly how long proto2 will be supported, but
if proto2 language support is removed from a future protobuf version, it
may cause problems for some of the packages listed below.

The TODO list is:

 - Ack the src:protobuf NMUs (2.6.1-1.1, -1.2, -1.3) by committing them
   to the repo.

 - Figure out what to do about the semi-embedded gmock/gtest build
   dependency.  Related upstream issues:

https://github.com/google/protobuf/issues/302

https://github.com/google/protobuf/issues/808

 - Figure out how to package the new language bindings in protobuf 3.

protobuf has a number of reverse dependencies in the archive, including:

  anfo
  bitcoin-qt
  clementine
  cubemap
  emacs-mozc-bin
  fcitx-mozc
  gazebo5
  gazebo5-plugin-base
  ibus-mozc
  libanfo0
  libgazebo5
  libignition-transport0
  libola1
  libphonenumber6
  libshogun16
  litecoin-qt
  mahimahi
  monav-preprocessor
  mosh
  mozc-server
  mozc-utils-gui
  mumble
  mumble-server
  ola
  osrm
  ostinato
  php5-pinba
  pink-pony
  pokerth
  pokerth-server
  protobuf-c-compiler
  python-imposm
  python-imposm-parser
  python-protobuf
  shogun-cmdline-static
  uim-mozc
  zbackup

(This is just a list of rdeps on libprotobuf9 or libprotobuf9v5, IIRC
there are some source packages that have build-deps on protobuf that
don't appear as binary deps.)

protobuf is implemented in C++ and has frequent ABI bumps.  The
transitions tend to be fairly involved, see the bug logs for the last
two transitions for details:

https://bugs.debian.org/726165

https://bugs.debian.org/760343

There are some interesting projects that depend on Protocol Buffers,
such as Canonical's Mir and Google's gRPC.  The OpenStreetMap project
also has a binary "PBF" format that uses protobufs.  (IIRC, protobufs
are also used in some of Canonical's web services.)  If you are involved
in packaging those projects, you might want to look into helping out
with packaging src:protobuf.

Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Re: is the whole unstable still broken by gcc-5?

[Paul Wise]

On Sun, Sep 13, 2015 at 7:05 PM, Russ Allbery wrote:

> I stopped using aptitude for routine upgrades a while back.  My experience
> with aptitude is that the first solution is almost always wrong, and the
> second solution is sometimes better than the first solution that apt comes
> up with.  That means it's a bad choice for day-to-day use, since you'll
> have to constantly fight with the first suggestion.

This config option improves the aptitude resolver for some situations:

/etc/apt/apt.conf.d/99aptitude-resolver:
Aptitude::ProblemResolver { SolutionCost "removals"; }

It won't help for incomplete transitions like the GCC5 one though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: GNU IceCat?

[Afif Elghraoui]

On الأحد 13 أيلول 2015 13:06, Chris Knadle wrote:
>>> If you do find that the Iceweasel maintainers are not interested
>>> >> enough in your goals, then a better engineering solution might be an
>>> >> overlay package which overrides some of the configuration defaults.
>>> >>
>>> >> (If there is currently no good mechanism for such an overlay package,
>>> >> that is a generically useful thing which I would expect both Debian's
>>> >> Iceweasel people and indeed upstream Mozilla to welcome.)
>> > 
>> > I don't see how such a mechanism would work, but if it was possible that
>> > would be nice.
> I can imagine how it would work, but it's ugly.  It might be best to build a
> "dpkg-overlay" tool for the job.  The basic idea would be that dpkg-overlay
> would be willing to replace package files and their .md5sum after checking a
> replacement .md5sum file that comes with the overlay package.  [This idea
> comes from exploits on local Debian packages that I've heard about, BTW.]
> The catch is that there'd need to be some way of triggering a
> re-installation of the overlay if the package that the overlay is for is
> reinstalled.

What about something like config-package-dev [1-2]? It can be used to
create packages that replace/transform specific files in another package
using dpkg-divert. It seems to have the capabilities to handle the
issues discussed here, but I have not used it myself yet to know for sure.

Afif

1. https://packages.debian.org/sid/config-package-dev
2. https://debathena.mit.edu/config-packages/

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: GNU IceCat?

[Chris Knadle]

Simon Josefsson:
> Ian Jackson  writes:
> 
>> Simon Josefsson writes ("Re: GNU IceCat?"):
>>> What's a good way to do that efficiently?   People have submitted bugs
>>> against Iceweasel to do some of the things that IceCat does by default,
>>> for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654336
>>
>> Well, a good start would be to turn bugs
>>   Severity: wishlist
>> into bugs
>>   Severity: wishlist
>>   Tags: patch
>> ?
>>
>> I'm not surprised that the Iceweasel team don't have much time for
>> anything which isn't strictly essential.  A well-tested and maintained
>> and maintainable patch would make it more feasible.
> 
> Agreed -- part of what I'm trying to understand, though, is whether the
> Iceweasel team considers this a relevant direction to go into?  The
> https://wiki.debian.org/Iceweasel suggests it strives to be close to
> what Firefox is, however that was written almost 10 years ago I'm not
> sure whether it is still true.

It's likely still true, mainly because it's most often true for most Debian
packages in general.  Patching the upstream source can be problematic
because often the patches need re-modification for new upstream versions, so
carrying a lot of patches is usually a maintenance headache.

>>> The normal approach in that situation is to also package the fork of
>>> the projects to give users a choice, similar to what's done with
>>> MariaDB/MySQL.
>>
>> I don't think this is a good engineering solution for a situation
>> where what we're talking about is essentially different configuration,
>> rather than a different codebase.
> 
> I don't think that is what we are talking about -- there appears to be
> more to IceCat than configuration.
> 
> I agree that the differences between IceCat and Iceweasel are small, and
> it is quite far away of resembling the MariaDB/MySQL situation, however,
> at some point separate packaging will become relevant.  We are obviously
> not there yet.

I don't think it's clear.

One option which might help is to package it (in one form or another), put
it in an external repository, and see how well you like the results.
[I'm willing to help you either set up your own external repo, or put the
package in my external repo for you to use.]

>> If you do find that the Iceweasel maintainers are not interested
>> enough in your goals, then a better engineering solution might be an
>> overlay package which overrides some of the configuration defaults.
>>
>> (If there is currently no good mechanism for such an overlay package,
>> that is a generically useful thing which I would expect both Debian's
>> Iceweasel people and indeed upstream Mozilla to welcome.)
> 
> I don't see how such a mechanism would work, but if it was possible that
> would be nice.

I can imagine how it would work, but it's ugly.  It might be best to build a
"dpkg-overlay" tool for the job.  The basic idea would be that dpkg-overlay
would be willing to replace package files and their .md5sum after checking a
replacement .md5sum file that comes with the overlay package.  [This idea
comes from exploits on local Debian packages that I've heard about, BTW.]
The catch is that there'd need to be some way of triggering a
re-installation of the overlay if the package that the overlay is for is
reinstalled.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Re: [DH] Planning to remove deprecated commands and compat levels in debhelper

[Matthias Klose]

On 09/13/2015 08:29 PM, Niels Thykier wrote:
> On 2015-09-13 11:04, Niels Thykier wrote:
>> Hi,
>>
>> EXECUTIVE SUMMARY
>> =
>>
>> I am planning to remove the following features/commands in debhelper in
>> the near future:
>>
>>  * compat level 1,2 and 3.
>>  * dh_scrollkeeper
>>
>> All of the listed commands do nothing except a deprecation warning.
>> Please see "BACKGROUND AND NUMBERS" for more information.  You may also
>> want to have a look at "FUTURE REMOVALS".
>>
>> [...]
> 
> Jakub Wilk mentioned on IRC that my dd-list did not include some
> packages using "DH_COMPAT=X dh_foo" (with X < 5).  Thanks to codesearch
> I have narrowed these down to 11 packages and have compiled an amended
> dd-list.
> 
> There seems to be two uses of this pattern:
> 
>   * DH_COMPAT=2 dh_movefiles   (seen in gcc-5, python2.7 etc.)
> 
> My immediate assumption is that they were used to upgrade that
> particular tool to a (at that time) higher debhelper compat.  This is
> based on:
> 
>  * dh_movefiles does not have any newer features in any compat levels.
>Though it does have a error case in compat 1 that did not occur in
>compat 2 or higher.

still using the globbing feature for command line arguments in DH_COMPAT=2 mode.
 Was this re-added in higher levels again?

  Matthias

Re: [DH] Planning to remove deprecated commands and compat levels in debhelper

[Niels Thykier]

On 2015-09-13 11:04, Niels Thykier wrote:
> Hi,
> 
> EXECUTIVE SUMMARY
> =
> 
> I am planning to remove the following features/commands in debhelper in
> the near future:
> 
>  * compat level 1,2 and 3.
>  * dh_scrollkeeper
> 
> All of the listed commands do nothing except a deprecation warning.
> Please see "BACKGROUND AND NUMBERS" for more information.  You may also
> want to have a look at "FUTURE REMOVALS".
> 
> [...]

Jakub Wilk mentioned on IRC that my dd-list did not include some
packages using "DH_COMPAT=X dh_foo" (with X < 5).  Thanks to codesearch
I have narrowed these down to 11 packages and have compiled an amended
dd-list.

There seems to be two uses of this pattern:

  * DH_COMPAT=2 dh_movefiles   (seen in gcc-5, python2.7 etc.)
  * DH_COMPAT=3 dh_makeshlibs  (seen in gcc-3.3)

My immediate assumption is that they were used to upgrade that
particular tool to a (at that time) higher debhelper compat.  This is
based on:

 * dh_movefiles does not have any newer features in any compat levels.
   Though it does have a error case in compat 1 that did not occur in
   compat 2 or higher.

 * compat 3 is the first compat level where dh_makeshlibs would emit
   ldconfig maintscripts.  The only other changes in dh_makehlibs
   behaviour based on compat level does not appear to apply to the
   particular case.

In other words, the DH_COMPAT=X prefix for these can probably just be
dropped if/when the package is upgraded beyond the compat level listed
in DH_COMPAT.

Thanks,
~Niels


Aigars Mahinovs 
   re

Alex Pennace 
   pentium-builder

Andrew Pollock 
   argus-client

Anthony Towns 
   pretzel

Araki Yasuhiro 
   kcc

Ardo van Rangelrooij 
   ldp-docbook-stylesheets (U)

Atsuhito KOHDA 
   e2ps

Atsushi KAMOSHIDA 
   libjcode-perl

Ben Armstrong 
   xletters

Brian White 
   scribble

Christian Marillat 
   sawfish-merlin-ugliness

Christophe Prud'homme 
   libcorelinux

Christopher Sacca 
   cvs-syncmail

Colin Watson 
   debbugs (U)

Daniel Burrows 
   heroes-data
   heroes-sound-effects
   heroes-sound-tracks

Debbugs developers 
   debbugs

Debian GCC Maintainers 
   gcc-4.8
   gcc-4.9
   gcc-5
   gcc-snapshot
   gnat-4.9

Debian Hamradio Maintainers 
   node

Debian kernel team 
   cramfs

Debian QA Group 
   intlfonts
   qmtest

Debian XML/SGML Group 
   ldp-docbook-stylesheets

Don Armstrong 
   debbugs (U)

Drake Diedrich 
   empire-hub

Eduard Bloch 
   stax

Eric Madesclair 
   le-dico-de-rene-cougnenc

Francesco Paolo Lovergine 
   athena-jot
   cramfs (U)
   dbf2mysql
   ebook-dev-alp
   gpw
   manpages-posix
   mpi-specs
   wmf

Francois Gurin 
   wmlongrun

Frederic Peters 
   jdresolve

Guus Sliepen 
   dhis-mx-sendmail-engine

Hakan Ardo 
   xfaces

Hamish Moffatt 
   node (U)

Hilko Bengen 
   libsendmail-milter-perl

Jaime Robles 
   node (U)

Jaldhar H. Vyas 
   libacme-brainfck-perl

Jan Niehusmann 
   tmake

Javier Fernandez-Sanguino Pen~a 
   binstats
   spellcast-doc

Joachim Breitner 
   xflip

Joey Schulze 
   vpim

John Goerzen 
   dict-bouvier
   dict-gazetteer2k
   dict-moby-thesaurus
   dictclient
   forg
   pygopherd

LaMont Jones 
   icebreaker

Loic Dachary (OuoU) 
   libtext-unaccent-perl

Ludovic Brenta 
   gnat-4.9 (U)

Marc 'HE' Brockschmidt 
   gcc-3.3 (U)
   wmpinboard

Marc Leeman 
   ogmtools

Marc Singer 
   bsign

Mark Brown 
   nis

Mark Purcell 
   bing
   ipcheck
   mp3rename

Matej Vela 
   doc-linux-hr

Matthias Klose 
   gcc-4.8 (U)
   gcc-4.9 (U)
   gcc-5 (U)
   gcc-snapshot (U)
   python2.7
   python3.4
   python3.5
   shapetools

Matthias Urlichs 
   festlex-cmu
   festlex-oald
   festlex-poslex
   festvox-don
   festvox-kallpc16k
   festvox-kdlpc16k

Matthias Urlichs 
   festvox-ellpc11k
   festvox-kallpc8k
   festvox-kdlpc8k
   festvox-rablpc16k
   festvox-rablpc8k

Michael Banck 
   cthumb

Michael Piefel 
   lgrind

Michael Stone 
   atsar

Miquel van Smoorenburg 
   nis (U)

Neil Roeth 
   jade
   openjade1.3

Nicolas Bertolissio 
   acheck
   ddtc

Nicolas Bertolissio 
   acheck-rules

Nicolas Boullis 
   loadwatch
   wmtv

NOKUBI Takatsugu 
   libtext-chasen-perl

OHURA Makoto 
   apt-show-source

Ola Lundqvist 
   icmpush

Ove Kaaven 
   awesfx

Patrick Ouellette 
   node (U)

paul cannon 
   gkrellkam

Paul Seelig 
   sysprofile

Pawel Wiecek 
   asr-manpages
   funny-manpages
   ncdt
   wordplay

Paweł Więcek 
   pgpgpg

Pedro Zorzenon Neto 
   jgraph

Peter De Schrijver (p2) 
   openwince-include
   openwince-jtag

Philip Brown 
   filter

Philipp Kern 
   gcc-3.3

Radovan Garabík 
   fonty-rg
   utalk

Rene Weber 
   parchive
   scanssh

Roderick Schertler 
   debget
   ftp-upload
   hearse
   libipc-signal-perl
   libproc-syncexec-perl
   libproc-waitstat-perl
   libstring-shellquote-perl
   libtime-period-perl
   mime-construct
   xtail

Russell Coker 
   cyclades-serial-client
   logtools

Sam Hocevar (Debian packages) 
   gniall
   recite

Sergio Talens-Oliag 
   cgvg

Simon Richter 
   python-imaging-doc-handbook

Sjoer

Bug#798873: ITP: dazzdb -- database library for the dazzler assembler

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: dazzdb
  Version : 1.0
  Upstream Author : Eugene W. Myers, Jr. 
* URL : https://github.com/thegenemyers/DAZZ_DB
* License : BSD
  Programming Lang: C
  Description : database library for the dazzler assembler

 To facilitate the multiple phases of the dazzler assembler, all the read
 data are organized into what is effectively a "database" of the reads and
 their meta-information. The design goals for this database are as follows:
 (1) The database stores the source Pacbio read information in such a way that
 it can recreate the original input data, thus permitting a user to remove
 the (effectively redundant) source files. This avoids duplicating the
 same data, once in the source file and once in the database.
 (2) The database can be built up incrementally, that is new sequence data can
 be added to the database over time.
 (3) The database flexibly allows one to store any meta-data desired for reads.
 This is accomplished with the concept of *tracks* that implementors can
 add as they need them.
 (4) The data is held in a compressed form equivalent to the .dexta and .dexqv
 files of the data extraction module. Both the .fasta and .quiva
 information for each read is held in the database and can be recreated
 from it. The .quiva information can be added separately and later on if
 desired.
 (5) To facilitate job parallel, cluster operation of the phases of dazzler,
 the data base has a concept of a *current partitioning* in which all the
 reads that are over a given length and optionally unique to a well, are
 divided up into *blocks* containing roughly a given number of bases,
 except possibly the last block which may have a short count. Often
 programs con be run on blocks or pairs of blocks and each such job is
 reasonably well balanced as the blocks are all the same size. One must
 be careful about changing the partition during an assembly as doing so can
 void the structural validity of any interim block-based results.

Bug#798872: ITP: pbcommand -- common command-line interface for Pacific Biosciences analysis modules

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

Control: block 797676 by -1

* Package name: pbcommand
  Version : 0.2.8
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbcommand
* License : BSD
  Programming Lang: Python
  Description : common command-line interface for Pacific Biosciences 
analysis modules

To integrate with the pbsmrtpipe workflow engine, you must to be able to
generate a Tool Contract and to be able to run from a Resolved Tool Contract.
A Tool Contract contains the metadata of the exe, such as the file types of
inputs, outputs and options.
There are two principal use cases, first wrapping/calling python functions that
have been defined in external python packages, or scripts. Second, creating a
CLI tool that supports emitting tool contracts, running resolved tool contracts
and complete argparse-style CLI.


This package is part of the SMRT Analysis suite and is to be handled by
the Debian Med team.

Re: is the whole unstable still broken by gcc-5?

[Russ Allbery]

Andreas Tscharner  writes:
> On 12.09.2015 21:23, Russ Allbery wrote:

>> I've been able to upgrade normally during the entire gcc-5 transition.

> Lucky you!

> aptitude wanted to remove 45 packages yesterday. I spent about 5 hours to
> manually resolve dependencies by uninstalling packages, removing lib*
> packages, adding lib*v5 packages and adding the uninstalled packages again
> to get ALL dependencies resolved

> I am not sure it it's a problem of aptitude or the resolver in general,
> but I was not able to "just update".

I stopped using aptitude for routine upgrades a while back.  My experience
with aptitude is that the first solution is almost always wrong, and the
second solution is sometimes better than the first solution that apt comes
up with.  That means it's a bad choice for day-to-day use, since you'll
have to constantly fight with the first suggestion.

For future transitions, if you want a closer experience to mine, I
recommend:

1. Upgrade frequently (every day) if you can.  Don't let it sit too long
   and accumulate complexity.

2. Use apt upgrade first, then apt dist-upgrade only if things are still
   held back.  If apt dist-upgrade can't find a good solution or wants to
   remove a bunch of stuff, just ignore it and try again the next day (but
   keep running apt upgrade).  It will often stay in that state for a
   while during transitions until all the packages have been rebuilt.
   That's normal and not a problem; the only problem is that some packages
   may become temporarily uninstallable, which is not solvable by any
   package management tool.

3. Use apt-get autoremove frequently so that the resolver doesn't have to
   figure out how to upgrade packages you're not even using.

4. Use aptitude for the nice interactive interface or if you really need
   to install something and feel like paging through multiple solutions,
   but not for routine upgrades.

I've been doing this through two release cycles, and have had almost none
of the problems that other people have reported.  Now, that could well be
because I don't have a ton of desktop environment packages installed,
which tend to involve the most complex dependency chains.  (In particular,
it sounds like there's a KDE transition that's pretty complicated right
now, and is probably causing the issues of the original poster.)  But I
think some of it has to do with keeping the work of the resolver
relatively light, and using the apt resolver instead of aptitude's.

-- 
Russ Allbery (r...@debian.org)   

Re: is the whole unstable still broken by gcc-5?

[Christoph Egger]

Andrei POPESCU  writes:

> On Sb, 12 sep 15, 23:27:48, Виталий Филиппов wrote:
>> 
>> Maybe adding jessie into sources.list will help to calm resolver...
>
> I'd rather suggest stretch.

While helpfull with normal transitions this is basically pointless with
the GCC5 one as library packages are not coinstallable so it's
all-or-nothing

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Re: [debhelper-devel] [DH] Planning to remove deprecated commands and compat levels in debhelper

[Niels Thykier]

On 2015-09-13 14:12, John D. Hendrickson wrote:
> [...]
> 
> you seem to be crossing your testimony
> 
> first you say "does nothing but print warning".  then you talk about
> patterns not matching and removing dh_scrollkeeper which is used by any
> packaged doing update for NOT-gnome3, which is many.
> 

According to lintian, there is exactly one consumer of debhelper tool
called "dh_scrollkeeper".

 * pybliographer

Source: https://lintian.debian.org/tags/dh_scrollkeeper-is-deprecated.html

> by removing dh_scrollkeeper you'd be saying that having two gnome
> versions installed is not allowed.

No, I am making no such assertion.  The source code of dh_scrollkeeper
does nothing but:

 * parse and validate the input arguments
 * emit a warning
 * terminate with exit code 0

Source: https://sources.debian.net/src/debhelper/9.20150811/dh_scrollkeeper/

If tool is a necessity for having two versions of GNOME installed, then
please consider replacing dh_scrollkeeper with a symlink to /bin/true.
If nothing else, the /bin/true-implementation is faster and it would
reduce the disk usage.

Thanks,
~Niels

Re: is the whole unstable still broken by gcc-5?

[Andrei POPESCU]

On Sb, 12 sep 15, 23:27:48, Виталий Филиппов wrote:
> 
> Maybe adding jessie into sources.list will help to calm resolver...

I'd rather suggest stretch.

https://lists.debian.org/debian-devel/2009/03/msg00582.html

"Personally I couldn’t care less about installability problems on user’s 
machines running unstable: my take is that those machines should have 
testing in sources.list, period."

Is this still valid? (BCC to -release for their insight)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: is the whole unstable still broken by gcc-5?

[Samuel Thibault]

Svante Signell, le Sun 13 Sep 2015 11:33:31 +0200, a écrit :
> > That's what Sid/Unstable is used for. You'll have to live with that :)
> > This transition was IMHO a monster compared to the usual transitions
> > and it might happen again. Se at the end we probably should discuss,
> > what to improve next time.
> 
> What about transition to glibc-2.21?

glibc has been systematically using compat symbols since a looong time
(the libc5 -> libc6 transition).

Samuel

Re: is the whole unstable still broken by gcc-5?

[Svante Signell]

On Sun, 2015-09-13 at 11:21 +0200, Daniel Leidert wrote:
> Am Samstag, den 12.09.2015, 21:55 +0300 schrieb Виталий Филиппов:

> 
> That's what Sid/Unstable is used for. You'll have to live with that :)
> This transition was IMHO a monster compared to the usual transitions
> and it might happen again. Se at the end we probably should discuss,
> what to improve next time.

What about transition to glibc-2.21?

Re: is the whole unstable still broken by gcc-5?

[Daniel Leidert]

Am Samstag, den 12.09.2015, 21:55 +0300 schrieb Виталий Филиппов:
> Hi everyone!
> 
> Is the whole unstable still broken by gcc-5 transition? Or by something
> else? Why apt-get dist-upgrade still wants to remove a lot of packages? It
> lasts for several weeks, I can't upgrade normally...

There are a lot of further transitions in the pipe, because every
library package, affected by the gcc-5-transition (and a library
rename) causes another transition for its reverse dependencies.

You are maybe hit by one of these transitions.

After debconf I was still not able to do a dist-upgrade without loosing
many packages. I then started manually upgrading the system. Found,
that at last only a few packages were hold back and most of the
packages could be transitioned without lossing half of the system. Took
me an hour. But hey, that Sid ;)

> Can you please tell when everything will be fixed i.e. when all packages
> will be rebuilt with newer gcc? And can you please NOT upload such
> "breaking updates" in the future before testing everything that's broken
> in experimental?.. Because the thing I always liked in Debian was that
> "debian unstable" was always more stable than "ubuntu stable", and such
> breakages dent my confidence in the stability of Debian...

That's what Sid/Unstable is used for. You'll have to live with that :)
This transition was IMHO a monster compared to the usual transitions
and it might happen again. Se at the end we probably should discuss,
what to improve next time.

Regards, Daniel

Re: is the whole unstable still broken by gcc-5?

[Andreas Tscharner]

On 12.09.2015 21:23, Russ Allbery wrote:

Виталий Филиппов  writes:


Is the whole unstable still broken by gcc-5 transition? Or by something
else? Why apt-get dist-upgrade still wants to remove a lot of packages?
It lasts for several weeks, I can't upgrade normally...


I've been able to upgrade normally during the entire gcc-5 transition.


Lucky you!

aptitude wanted to remove 45 packages yesterday. I spent about 5 hours 
to manually resolve dependencies by uninstalling packages, removing lib* 
packages, adding lib*v5 packages and adding the uninstalled packages 
again to get ALL dependencies resolved


I am not sure it it's a problem of aptitude or the resolver in general, 
but I was not able to "just update".


Best regards
Andreas
--
Andreas Tscharner  starf...@sunrise.ch
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
  -- Rich Cook

[DH] Planning to remove deprecated commands and compat levels in debhelper

[Niels Thykier]

Hi,

EXECUTIVE SUMMARY
=

I am planning to remove the following features/commands in debhelper in
the near future:

 * compat level 1,2 and 3.
 * dh_scrollkeeper

All of the listed commands do nothing except a deprecation warning.
Please see "BACKGROUND AND NUMBERS" for more information.  You may also
want to have a look at "FUTURE REMOVALS".


THE PLAN


My plan is to:

 * Mass-file bugs for compat level 1,2 and 3 plus the used tools before
   Monday the 28th.
   - severity: important

 * Remove compat 1+2 in the first debhelper upload after November 1st
   - related unfixed bugs would be bumped to RC.

 * Remove compat 3 AND dh_scrollkeeper in the first debhelper upload
   after January 1st  (2016)
   - related unfixed bugs would be bumped to RC.

If the last consumer of a given feature is updated the deadline, I may
remove the feature before the listed deadline.


MIGRATING TO COMPAT 5 OR LATER
==

I appreciate that the migration from compat 4 to 5 has been somewhat
difficult for some, since compat 5 rejects wildcards without matches and
people have been relying on the compat 4 behaviour.

The current recommendation is:

  * Migrate to compat 9 AND
  * use the filters from dh-exec to exclude files only built on certain
architectures

Debhelper 9 and dh-exec/0.14 are already available in oldstable, which
should cover the majority of all backporting needs.


BACKGROUND AND NUMBERS
==

Having looked at the Lintian statistics[1], I think we are at the point,
where we are almost ready to remove some of the deprecated compat levels
in debhelper.  A break down of the numbers shows that:

 * 437 packages use compat 4 (deprecated in Mar 2009 - 7.2.3)
 *  73 packages use compat 3 (deprecated in Nov 2005 - 5.0.0)
 *  11 packages use compat 2 (not sure when it was deprecated)
 *  48 packages use compat 1 (not sure when it was deprecated)

Given the numbers, I am considering to remove the 3 latter compat levels
in the near future.  I have attached a dd-list of affected maintainers
and their packages (please see compat-123-dd-list).

I also looked at some of the deprecated dh commands like

 * dh_desktopNOOP with 28 consumers
 * dh_scrollkeeper   NOOP with  1 consumer
 * dh_suidregister   NOOP with  2 consumers
 * dh_undocumented   NOOP with 10 consumers

It so happens that the sole consumer of dh_scrollkeeper is using a
compat level /less/ than 4, so I am taking the liberty of removing that
as well with compat 3.


FUTURE REMOVALS
===

I fully intend to remove compat 4 and the rest of these tools (time
permitting, in Stretch).  Affected packages and maintainers are
available from:

 * compat4-dd-list  (consumers of compat 4)
 * dh_tools-dd-list (consumers of the deprecated NOOP dh_* tools)

Please consider migrating sooner rather than later.

Thanks,
~Niels


[1]
https://lintian.debian.org/tags/package-uses-deprecated-debhelper-compat-version.html

Aigars Mahinovs 
   re

Alex Pennace 
   pentium-builder

Andrew Pollock 
   argus-client

Anthony Towns 
   pretzel

Araki Yasuhiro 
   kcc

Ardo van Rangelrooij 
   ldp-docbook-stylesheets (U)

Atsuhito KOHDA 
   e2ps

Atsushi KAMOSHIDA 
   libjcode-perl

Ben Armstrong 
   xletters

Brian White 
   scribble

Christian Marillat 
   sawfish-merlin-ugliness

Christophe Prud'homme 
   libcorelinux

Christopher Sacca 
   cvs-syncmail

Colin Watson 
   debbugs (U)

Daniel Burrows 
   heroes-data
   heroes-sound-effects
   heroes-sound-tracks

Debbugs developers 
   debbugs

Debian Hamradio Maintainers 
   node

Debian kernel team 
   cramfs

Debian QA Group 
   intlfonts

Debian XML/SGML Group 
   ldp-docbook-stylesheets

Don Armstrong 
   debbugs (U)

Drake Diedrich 
   empire-hub

Eduard Bloch 
   stax

Eric Madesclair 
   le-dico-de-rene-cougnenc

Francesco Paolo Lovergine 
   athena-jot
   cramfs (U)
   dbf2mysql
   ebook-dev-alp
   gpw
   manpages-posix
   mpi-specs
   wmf

Francois Gurin 
   wmlongrun

Frederic Peters 
   jdresolve

Guus Sliepen 
   dhis-mx-sendmail-engine

Hakan Ardo 
   xfaces

Hamish Moffatt 
   node (U)

Hilko Bengen 
   libsendmail-milter-perl

Jaime Robles 
   node (U)

Jaldhar H. Vyas 
   libacme-brainfck-perl

Jan Niehusmann 
   tmake

Javier Fernandez-Sanguino Pen~a 
   binstats
   spellcast-doc

Joachim Breitner 
   xflip

Joey Schulze 
   vpim

John Goerzen 
   dict-bouvier
   dict-gazetteer2k
   dict-moby-thesaurus
   dictclient
   forg
   pygopherd

LaMont Jones 
   icebreaker

Loic Dachary (OuoU) 
   libtext-unaccent-perl

Marc 'HE' Brockschmidt 
   gcc-3.3 (U)
   wmpinboard

Marc Leeman 
   ogmtools

Marc Singer 
   bsign

Mark Brown 
   nis

Mark Purcell 
   bing
   ipcheck
   mp3rename

Matej Vela 
   doc-linux-hr

Matthias Urlichs 
   festlex-cmu
   festlex-oald
   festlex-poslex
   festvox-don
   festvox-kallpc16k
   festvox-kdlpc16k

Matthias Urlichs 
   festvox-ellpc11k
   festvox-kallpc8k
   festvox-kdlpc8k
   festvox-rablpc16k
   festvo