Re: [RFC] The PIE unholy mess

[Guillem Jover]

On Wed, 2017-01-18 at 08:10:53 +0100, Bálint Réczey wrote:
> 2017-01-18 4:34 GMT+01:00 Guillem Jover :
> > So, I'd like to know how people feel about the requested interface
> > (i.e. not enabling PIE globally from dpkg-buildflags). If there's
> > consensus that porters and maintainers want that, I'll just change
> > dpkg-buildflags to do this, even though I think it's a very
> > suboptiomal behavior.
> 
> To detail the requested interface (requested originally in #835149 and
> then in #848129 currently) is:
> 
> * Enable PIE in GCC on a set of architectures (GCC-PIE-ARCH-es)
> * On every GCC-PIE-ARCH make dpkg-buildflags' "-pie" a noop, "+pie"
>   still adds pie flag to compiler flags
>   ("hardening=+all,-pie" would pass no PIE related flag to compiler)
> * On every non GCC-PIE-ARCH leave dpkg-buildflags work as they did
> before changing GCC's defaults
> * Don't pass -specs from dpkg in any case

Err, pretty much *no*. You have requested this several times now, and
as I've also mentioned several times, this is not going to happen,
otherwise I'd just declare PIE unsupportable and request for it to be
reverted. Not using specs files will just break lots of stuff. Making
it extremely hard for maintainers to disable PIE is just antisocial. :/

The requested interface is to make dpkg-buildflags:

 * Only emit PIE options when requested by the builder or the package
   via DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS.
 * Only emit PIE options when needed, depending on whether gcc has PIE
   enabled by default on that arch or not.

So on release arches with -all or -pie, -specs options would be
emitted to disable PIE. And on non-release arches with +all or +pie,
-specs options would be emitted to enable PIE. Otherwise nothing would
be emitted.

And to reiterate I think this is suboptimal and inconsistent and
IMO ideally (which is what would have happened if this would have
been enabled via dpkg-buildflags from the beginning), gcc should
enable this globally, and then dpkg-buildflags would only emit -specs
files to disable PIE on -all or -pie.

Regards,
Guillem

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Paul Wise writes ("Re: Auto reject if autopkgtest of reverse dependencies fail 
or cause FTBFS"):
> On Wed, Jan 18, 2017 at 1:08 AM, Russ Allbery wrote:
> > Oh, sure, I'm in favor of disabling flaky tests if we can't fix them.  My
> > experience is usually more that I'm leaving them on *because* I'm trying
> > to fix them and can't reproduce locally, or I think I've fixed it (but
> > actually haven't).
...
> I would expect most upstream test frameworks support marking tests as
> flaky, which usually means they always get run and results printed but
> their outcome never causes a build failure.

It might also be that the flakiness affects all tests.

For example, there is a race in gnupg2's gpg-agent which makes the
dgit test suite fail sometimes.  (#841143, reported in October; now at
last being worked on.)

As it happens, I have chosen (for other reasons[1]) not to run the
test suite during package build, so this is never a FTBFS.  But it
could easily have been a flaky FTBFS.

Ian.

[1] Mainly, that the test suite is computationally intensive and has
an inconveniently large dependency set; this makes it
disproportionate, particularly given that the actual package build is
almost trivial.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#851542: ITP: jenkins-job-builder-pipeline -- pipeline job generation plugin for jenkins-job-builder

[李健秋]

Package: wnpp
Followup-For: Bug #851542
Owner: "Andrew Lee (李健秋)" 

You are right. Confirmed with upstream author.

Best regards,
-Andrew

Bug#851766: ITP: python3-streamparser -- Python library to parse Apertium stream format

[Joonas Kylmälä]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Joonas_Kylm=C3=A4l=C3=A4?= 

* Package name: python3-streamparser
  Version : 4.0.2
  Upstream Author : Sushain K. Cherivirala and Kevin Brubeck Unhammer 

* URL : https://github.com/apertium/streamparser
* License : GPL-3+
  Programming Lang: Python
  Description : Python library to parse Apertium stream format

This is a Python 3 library for parsing (converting to Python data
structure) text in Apertium stream format [1].

This library is useful for people developing Apertium (Apertium is a
machine translation engine that is already in Debian) language pairs
in case if they want to do python scripts for automating their
workflow (finding unknown words from morphological analyser, etc.),
also people can build new applications for quite variety of purposes,
e.g. for research on natural language processing. I have used
personally streamparser for automatic Constraint
Grammar generation: https://github.com/Putti/autocg. To my best
knowledge there is no other similar library for Python (that is at
least this good quality, some hacks might be lying around in the
Apertium project's repository).

I haven't submitted any packages to Debian archive before and I'm
still learning packaging. I have started the packing work already,
it's here:
.
 I'm
reading the new maintainer guide and policies at the moment so it
still might take some days or weeks to get the package in a good
shape. This package, when ready, needs a sponsor. Kartik Mistry has
handled other Apertium related packages before so maybe he/she would
be willing to take on this package (I haven't asked Kartik yet).

[1] http://wiki.apertium.org/wiki/Apertium_stream_format

Best regards,
Joonas Kylmälä

Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

[Simon Richter]

Hi,

On Sun, Jan 15, 2017 at 12:51:51AM +, Simon McVittie wrote:

> If I understand correctly, the objection was to how sysvinit behaves
> (for which I have now opened #851427) - it puts the symlink at /dev/shm and
> the real mount at /run/shm.

That is the correct approach, and IIRC this is how it was implemented in
sysvinit before jessie (/dev/shm is way older than /run), so I'm wondering
what triggered the change.

   Simon

Bug#851732: schleuder: please Depend: cron-daemon instead of cron

[Sebastien Badia]

tags 851732 + fixed pending
thanks

Hi Daniel!

Thanks for the feedback!
You are right, it's updated, and avail. in the next upload of schleuder.

Regards,

Seb


signature.asc
Description: PGP signature

manpages.debian.org has been modernized!

[Michael Stapelberg]

https://manpages.debian.org has been modernized! We have just launched
a major update to our manpage repository. What used to be served via a
CGI script is now a statically generated website, and therefore
blazingly fast.

While we were at it, we have restructured the paths so that we can
serve all manpages, even those whose name conflicts with other binary
packages (e.g. crontab(5) from cron, bcron or systemd-cron). Don’t
worry: the old URLs are redirected correctly.

Furthermore, the design of the site has been updated and now includes
navigation panels that allow quick access to the manpage in other
Debian versions, other binary packages, other sections and other
languages. Speaking of languages, the site serves manpages in all
their available languages and respects your browser’s language when
redirecting or following a cross-reference.

Much like the Debian package tracker, manpages.debian.org includes
packages from Debian oldstable, oldstable-backports, stable,
stable-backports, testing and unstable. New manpages should make their
way onto manpages.debian.org within a few hours.

The generator program (“debiman”) is open source and can be found at
https://github.com/Debian/debiman. In case you would like to use it to
run a similar manpage repository (or convert your existing manpage
repository to it), we’d love to help you out; just send an email to
stapelberg AT debian DOT org.

This effort is standing on the shoulders of giants: check out
https://manpages.debian.org/about.html for a list of people we thank.

We’d love to hear your feedback and thoughts. Either contact us via an
issue on https://github.com/Debian/debiman/issues/, or send an email
to the debian-doc mailing list (see
https://lists.debian.org/debian-doc/).

-- 
Best regards,
Michael

Re: [RFC] The PIE unholy mess

[Matthias Klose]

On 18.01.2017 09:34, Guillem Jover wrote:
> On Wed, 2017-01-18 at 08:10:53 +0100, Bálint Réczey wrote:
>> 2017-01-18 4:34 GMT+01:00 Guillem Jover :
>>> So, I'd like to know how people feel about the requested interface
>>> (i.e. not enabling PIE globally from dpkg-buildflags). If there's
>>> consensus that porters and maintainers want that, I'll just change
>>> dpkg-buildflags to do this, even though I think it's a very
>>> suboptiomal behavior.
>>
>> To detail the requested interface (requested originally in #835149 and
>> then in #848129 currently) is:
>>
>> * Enable PIE in GCC on a set of architectures (GCC-PIE-ARCH-es)
>> * On every GCC-PIE-ARCH make dpkg-buildflags' "-pie" a noop, "+pie"
>>   still adds pie flag to compiler flags
>>   ("hardening=+all,-pie" would pass no PIE related flag to compiler)
>> * On every non GCC-PIE-ARCH leave dpkg-buildflags work as they did
>> before changing GCC's defaults
>> * Don't pass -specs from dpkg in any case
> 
> Err, pretty much *no*. You have requested this several times now, and
> as I've also mentioned several times, this is not going to happen,
> otherwise I'd just declare PIE unsupportable and request for it to be
> reverted. Not using specs files will just break lots of stuff. Making
> it extremely hard for maintainers to disable PIE is just antisocial. :/
> 
> The requested interface is to make dpkg-buildflags:
> 
>  * Only emit PIE options when requested by the builder or the package
>via DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS.
>  * Only emit PIE options when needed, depending on whether gcc has PIE
>enabled by default on that arch or not.
> 
> So on release arches with -all or -pie, -specs options would be
> emitted to disable PIE. And on non-release arches with +all or +pie,
> -specs options would be emitted to enable PIE. Otherwise nothing would
> be emitted.
> 
> And to reiterate I think this is suboptimal and inconsistent and
> IMO ideally (which is what would have happened if this would have
> been enabled via dpkg-buildflags from the beginning), gcc should
> enable this globally, and then dpkg-buildflags would only emit -specs
> files to disable PIE on -all or -pie.

So it looks that Balint was also surprised by the extent of the changes to
support PIE in dpkg.  And afaics at the time of the dpkg upload, they were not
discussed or documented, same for the spec file changes.  Instead you seem to
prefer to accuse others for "childish behavior" after over a month staying quiet
... not sure if that is the right thing to start the discussion.

At this point, I would prefer to revert the PIE changes for the release and
discuss these after the release with all parties involved.

Matthias

Re: [RFC] The PIE unholy mess

[Emilio Pozuelo Monfort]

On 18/01/17 18:23, Matthias Klose wrote:
> At this point, I would prefer to revert the PIE changes for the release and
> discuss these after the release with all parties involved.

It's not the time to revert that, thanks.

Emilio

Re: [RFC] The PIE unholy mess

[Bálint Réczey]

Hi Emilio,

2017-01-18 18:44 GMT+01:00 Emilio Pozuelo Monfort :
> On 18/01/17 18:23, Matthias Klose wrote:
>> At this point, I would prefer to revert the PIE changes for the release and
>> discuss these after the release with all parties involved.
>
> It's not the time to revert that, thanks.

I think Matthias meant reverting the changes to dpkg passing -spec to gcc,
and not all the PIE related changes - this would make sense and fix
several bugs IMO.

Cheers,
Balint

--
I have marked #816223 as fixed and closed it before sending this email
to debian-devel.
http://balintreczey.hu/blog/my-debian-devel-pledge

Re: manpages.debian.org has been modernized!

[Marcin Kulisz]

On 2017-01-18 18:23:16, Michael Stapelberg wrote:
> https://manpages.debian.org has been modernized! We have just launched
> a major update to our manpage repository. What used to be served via a
> CGI script is now a statically generated website, and therefore
> blazingly fast.

Thanks a lot for this.

> We’d love to hear your feedback and thoughts. Either contact us via an
> issue on https://github.com/Debian/debiman/issues/, or send an email
> to the debian-doc mailing list (see
> https://lists.debian.org/debian-doc/).

Maybe it'd be worth to package it and use BTS for tracking issues?
I'm not volunteering to do the above but I think that services running in d.o
domain should be available from Debian main.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Re: manpages.debian.org has been modernized!

[Philipp Kern]

On 2017-01-18 19:34, Marcin Kulisz wrote:
I'm not volunteering to do the above but I think that services running 
in d.o

domain should be available from Debian main.


Most services don't do that. Which is also related to the fact that they 
wouldn't run the code from stable but the machines need to run stable to 
be supportable by our awesome sysadmins. So you'd need to go and 
backport the package. The development cycle would then mean test 
$somewhere with an unstable environment, upload to unstable, wait for it 
to migrate to testing, backport it, test it on stable, notice a bug, 
rinse and repeat...


Kind regards
Philipp Kern

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Barry Warsaw]

On Jan 16, 2017, at 05:45 PM, Russ Allbery wrote:

>autopkgtest is useful for adding additional tests of the built binaries,
>but I don't believe it's intended as a replacement for build-time testing.
>Maybe I've missed something?

No, I think you're exactly right.  If an upstream provides unit tests, those
are totally appropriate to run at build time -and to fail the build if they
fail- but may not be appropriate to run in autopkgtest.  autopkgtests should
be reserved for larger suitability tests on the built and installed package.

An example might be a Python library's test suite.  It makes sense to run
these at build time because that's usually when upstream will run them
(i.e. during development of the package).  But since the test suite usually
isn't run on a built package, it shouldn't be autopkgtested.  The environment
for build tests and autopkgtests are importantly different, e.g. the former
does not/should not allow access to the internet while the latter can and
sometimes must.  A good example of an autopkgtest would be an import test for
a Python module, i.e. once the package is built and installed, does it import?
In fact, autodep8 will automatically add import tests for Python modules in a
safe way (by cd'ing to a temporary directory first).

There are occasionally good reasons why an upstream's test suite can't be run
at build-time, and in those few cases I will run them in an autopkgtest.  But
generally, I think the two are there to test different aspects or lifecycles
of the package.

Cheers,
-Barry


pgpvpsvB8j6tg.pgp
Description: OpenPGP digital signature

Bug#851806: ITP: libmseed2 -- seed (Standard for the Exchange of Earthquake Data) data records manipulation library

[Pierre Duperray]

Package: wnpp
Severity: wishlist
Owner: Pierre Duperray 

* Package name: libmseed2
  Version : 2.18
  Upstream Author : Chad Trabant 
* URL : http://ds.iris.edu/ds/nodes/dmc/software/downloads/libmseed/
* License : LGPL3
  Programming Lang: C
  Description : seed data records manipulation library

Provides a framework for manipulation of SEED (Standard for the Exchange
 of Earthquake Data) data records.

I think this package is relevant because it is a reference implementation of
the SEED format manipulation. It will be a dependency on other packages 
allowing,
for instance, realtime exchange of seismic data around the world.
I use these tools on a daily basis, no other package provide this functionality
(as far as I know).
I plan to maintain this package and create other sismological related package,
as a maintainer beginner, I definitively need a sponsor.
My work on this package basically consisted in learning packaging, autotoolizing
the upstream source distribution. I plan to submit autotoolizing patch and man 
page
typos patch upstream. I will also ask the upstream author if he his interested
in co-maintaining this package.

Re: manpages.debian.org has been modernized!

[Ian Jackson]

Philipp Kern writes ("Re: manpages.debian.org has been modernized!"):
> Most services don't do that. Which is also related to the fact that they 
> wouldn't run the code from stable but the machines need to run stable to 
> be supportable by our awesome sysadmins.

Indeed.

The approach I took with dgit is that the server code on
push.dgit.debian.org is a working tree of the dgit repo, but there is
a dgit subcommand to retrieve the source code of the version you're
talking to.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: manpages.debian.org has been modernized!

[Ian Jackson]

Michael Stapelberg writes ("manpages.debian.org has been modernized!"):
> https://manpages.debian.org has been modernized!

Awesome!  Thanks to everyone.

> https://github.com/Debian/debiman. In case you would like to use it to
> run a similar manpage repository (or convert your existing manpage
> repository to it), we’d love to help you out; just send an email to
> stapelberg AT debian DOT org.

As you might expect, I'm uncomfortable about the use of the
proprietary github service for this.  I realise that we don't
necessarily have entirely comparable alternatives, but Free Software
needs free tools.[1]

Also, I think the exact running version of Debian services should be
publicly available.  And, unless this is made so easy that the service
operators don't have to think about it, it will always fall behind.
So I think this should be done automatically.

Would you accept a patch to make debiman copy its own source code,
including git history, to its output ?  Then there could be a `source
code for this manpage generator' link on each page, or maybe in the
information page.  I have done this for a few programs I have written
and it's surprisingly easy.  When it's done, you will always be
publishing your own up to date source code.

Speaking of the information page, if you click on the info links you
get this
  https://manpages.debian.org/cgi-bin/man.cgi?query=info.html
which seems out of date.

> We’d love to hear your feedback and thoughts. Either contact us via an
> issue on https://github.com/Debian/debiman/issues/, or send an email
> to the debian-doc mailing list (see
> https://lists.debian.org/debian-doc/).

If we created a pseudopackage in the Debian bug system, would you use
it instead ?  It's one thing to use github as a generic git hosting
server but I really don't want us to be constructing our issue tracker
data in github's databases.

Regards,
Ian.

[1] https://mako.cc/writing/hill-free_tools.html
  As true now as it was in 2010.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Barry Warsaw writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> There are occasionally good reasons why an upstream's test suite can't be run
> at build-time, and in those few cases I will run them in an autopkgtest.  But
> generally, I think the two are there to test different aspects or lifecycles
> of the package.

This depends very much on the nature of the program.

If it's a self-contained library or tool, full of algorithms and with
few entanglements with dependencies, and the upstream test is mostly
algorithmic "right answer" tests, then what you say is true.

But much software that we have is not like that at all.  dgit is a
very good example here.

dgit has many dependencies and is easily broken by "unexpected
behaviours" in those dependencies.  Most tests uin the test suite
exercise a mixture of code in dgit, and the dependencies, and the
interaction between those.

There isn't really a distinction between things that are useful to
test during development, and things that are useful as autopkgtests.


Even in software that looks very algorithmic it can be useful to use
the upstream test suite as the autopkgtest.  I recently packaged Simon
Tatham's exact real calculator, `spigot'.

spigot's build system as supplied by Simon runs a moderately extensive
test suite.

spigot depends on gmp.  If there were some bug in certain gmp
functions, that gmp bug might cause a regression in spigot.  How would
I detect this ?  Well, I can publish the spigot test suite as an
autopkgtest test.  I haven't checked, but I imagine that Simon's test
suite tests most of the interesting codepaths in spigot, so it
probably also tests most of the intersting gmp calls that spigot
makes.


My view is that for most packages, if the upstream test suite _can_ be
made to run against the installed version, and isn't annoying in some
way, it should be advertised as an autopkgtest.

One may want to add other autopkgtests.  For example, I added another
test for spigot, to check that it is actually using the gmp
integration, rather than its fallback internal bignum library.  AFAICT
this is actually a check that could be done at build time, with
spigot's current fallback behaviour, but autopkgtest is a convenient
place to add Debian-specific tests, and it will spot if spigot gets
dynamic fallback.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: manpages.debian.org has been modernized!

[Henrique de Moraes Holschuh]

On Wed, 18 Jan 2017, Michael Stapelberg wrote:
> https://manpages.debian.org has been modernized! We have just launched
> a major update to our manpage repository. What used to be served via a
> CGI script is now a statically generated website, and therefore
> blazingly fast.

Oooh, nice! A big thank you for all involved!

> Much like the Debian package tracker, manpages.debian.org includes
> packages from Debian oldstable, oldstable-backports, stable,
> stable-backports, testing and unstable. New manpages should make their
> way onto manpages.debian.org within a few hours.

Maybe you could consider adding the manpages from packages in contrib as
well?  Unlike non-free, the licenses in contrib are all compatible with
the DFSG, so they must not have any license restrictions that would get
in the way...

-- 
  Henrique Holschuh

Packaging suggestion for the Universal Media Server program.

[Aldrin P. S. Castro]

I would very much like the Universal Media Server to be in the Debian 
repositories.

He is a very good dlna server. It is done in Java.

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Thu, Jan 19, 2017 at 1:23 AM, Michael Stapelberg wrote:

> https://manpages.debian.org has been modernized! We have just launched
> a major update to our manpage repository. What used to be served via a
> CGI script is now a statically generated website, and therefore
> blazingly fast.

My dman shell function is now broken:

dman () {
w3m "https://manpages.debian.org/man0/$1";
}

The manpages.d.o URLs on these pages are broken:

https://wiki.debian.org/AppArmor/Debug
https://manpages.debian.org/man/0/aa-notify

https://wiki.debian.org/lsusb
https://manpages.debian.org/man/0/lsusb

The previous site had 0 as a wildcard for any section.

> While we were at it, we have restructured the paths so that we can
> serve all manpages, even those whose name conflicts with other binary
> packages (e.g. crontab(5) from cron, bcron or systemd-cron). Don’t
> worry: the old URLs are redirected correctly.

Does this take into account that some manual pages are available only
on certain architectures? Or that some manual pages might differ
between architectures?

In #264589 I wrote a patch for packages.debian.org to link to manual
pages from a few locations. Could you advise on any changes I should
make to the links in the patch?

> Furthermore, the design of the site has been updated and now includes
> navigation panels that allow quick access to the manpage in other
> Debian versions, other binary packages, other sections and other
> languages. Speaking of languages, the site serves manpages in all
> their available languages and respects your browser’s language when
> redirecting or following a cross-reference.

I notice you force the URL to contain the package, version, language
and format, I would prefer normal URLs to not include either of those
and the defaults to be chosen via Accept-* if they are not part of the
URL. The links could then override them as needed.

Would it be possible to titlecase the section names in the table of
contents and in the HTML?

Personally I much prefer non-monospaced text when reading
documentation. IIRC the debmans code did this better.

The manual page converter seems to use line breaks rather than proper
paragraph tags.

The Debian logo appears to be missing when I view the site in Tor
Browser on high security mode, due to the use of SVG with no fallback.

Non-truncated version numbers don't need the popup like truncated ones do.

IIRC, according to the design principles  of the current Debian
website design, the 'Index' link should not be present because the
link above it points at the same place.

https://wiki.debian.org/KallesDesign

Can you change the top 'MANPAGES' link to 'Manual pages' instead? Any
other occurrences should change too (such as on the suite contents
pages).

The suite contents pages contain a lot of whitespace on desktop
browsers. Just putting every manual page on one long line to be
wrapped by the browser might be better.

If I press up in my browser, these URLs don't work or do the wrong thing:

https://manpages.debian.org/jessie/manpages/
https://manpages.debian.org/jessie/
https://manpages.debian.org/unstable/

> Much like the Debian package tracker, manpages.debian.org includes
> packages from Debian oldstable, oldstable-backports, stable,
> stable-backports, testing and unstable. New manpages should make their
> way onto manpages.debian.org within a few hours.

I'd really suggest using suite names by default instead of codenames
in the text of the versions section and in all URLs, with the
codenames also supported in URLs though.

> We’d love to hear your feedback and thoughts. Either contact us via an
> issue on https://github.com/Debian/debiman/issues/, or send an email
> to the debian-doc mailing list (see
> https://lists.debian.org/debian-doc/).

It would be really nice if man-db had support for both manpages.d.o
and manpages.u.c.

Highlighting some more of the features on the front page might be useful.

Is the rebuilding of new and updated manual pages triggered by Debian
mirror pushes?

Are incoming.debian.org/archive.debian.org to be used as sources of
manual pages too?

I hope you aren't hard-coding any architecture info or codenames in
the source code or configs :)

https://wiki.debian.org/SuitesAndReposExtension

You may want to mention this on debian-derivatives, to the
manpages.u.c maintainers and to the maintainers of other distros
manual page websites, some of them might like to use it, although Go
might put some of them off.

The wiki page needs to be rewritten now that debmans is dropped and
debiman is used on the site.

https://wiki.debian.org/manpages.debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Thu, Jan 19, 2017 at 6:37 AM, Ian Jackson wrote:

> As you might expect, I'm uncomfortable about the use of the
> proprietary github service for this.  I realise that we don't
> necessarily have entirely comparable alternatives, but Free Software
> needs free tools.[1]

Agreed for both bugs and contribution mechanisms.
Same goes for the codesearch.d.n service too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Andreas Tille]

On Mon, Jan 16, 2017 at 11:58:08AM -0500, Scott Kitterman wrote:
> 
> OK.  Would you at least discuss it with upstream?

Done

https://github.com/ekg/freebayes/issues/358

Kind regards

 Andreas.

-- 
http://fam-tille.de