Re: manpages.debian.org has been modernized!

[Michael Stapelberg]

On Thu, Jan 19, 2017 at 1:05 AM, Henrique de Moraes Holschuh
 wrote:
> 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!

Glad you like it :)

>
>> 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...

Thanks, that’s a good point. I’ll add contrib soon. Feel free to
subscribe to https://github.com/Debian/debiman/issues/34


-- 
Best regards,
Michael

Re: manpages.debian.org has been modernized!

[Michael Stapelberg]

On Wed, Jan 18, 2017 at 11:37 PM, Ian Jackson
 wrote:
> 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]

I agree. However, I prioritize “free software needs people who work on
it”, and by using GitHub, contributions are made significantly easier
for a large number of people.

In my personal experience, I can say that I would not be able to spend
_nearly_ as much of my time on FOSS if it weren’t for GitHub’s
convenient web interface.

>
> 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.

All pages on manpages.debian.org already include the git revision at
the bottom of the page, e.g.:

debiman c17f615, see github.com/Debian/debiman

Hence, you can already check out the exact running version. Is that
not sufficient?

(Caveat: the Debian assets are not currently in git. This is already
on my TODO list, though.)

>
> 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.

Will be updated soon, thanks.

>
>> 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.

I personally find the Debian bug system very uncomfortable to use. I
will begrudgingly accept reports made via the BTS, as I do for the
Debian packages I maintain. I don’t want to give up using GitHub’s
issue tracker, though, for my convenience and the convenience of our
users.

-- 
Best regards,
Michael

Re: manpages.debian.org has been modernized!

[Michael Stapelberg]

On Thu, Jan 19, 2017 at 4:41 AM, Paul Wise  wrote:
> 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.

Thanks for pointing it out, this is fixed with
https://github.com/Debian/debiman/commit/2517d8f6a070890469eb55d0533304a0da642f9e

>
>> 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

Yes.

> between architectures?

No. Isn’t that a violation of the FHS (see
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA)
and Debian policy?

>
> 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?

Cool! I wasn’t aware of this.
https://github.com/Debian/debiman/blob/2517d8f6a070890469eb55d0533304a0da642f9e/internal/redirect/redirect_test.go#L237-L257
should give you a good overview of the URL schema which is now in use.
Let me know if that answers your question or whether you need more
details.

>
>> 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.

The language is already taken from the Accept-Language header if it’s
not specified. Adding a plain text format and respecting the Accept
header is on my TODO list.

I guess it depends on your point of view what a “normal URL” really
is. Maybe I also misunderstood your point — if so, please clarify.

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

Why? In general, I’d like to stick with the conventions that are used
for displaying manpages whenever a design choice is just about
personal preference and not about enabling/preventing use-cases.

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

It should be easy to configure a user style sheet to this purpose.
Just configure font-family of the .mandoc class to your liking.

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

Could you report this issue upstream at http://mdocml.bsd.lv/ please?

>
> 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.

Now tracked at https://github.com/Debian/debiman/issues/35

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

The truncation is done via CSS. I don’t know how to make the title
attribute conditional on truncation.

>
> 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

Couldn’t find that bit on the wiki page. Can you point me to where it
says that please?

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

I thought that bit should equal the domain name. Is that incorrect? Do
you have a reference for what it should contain?

>
> 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.

I’m not sure. In practice, people are going to use the search function
of their browser anyway. I feel that a long list is easier on the eye
than a wall of text.

>
> If I press up in my browser, these URLs don't work or do th

Re: [RFC] The PIE unholy mess

[Adrian Bunk]

On Wed, Jan 18, 2017 at 04:34:24AM +0100, Guillem Jover wrote:
>...
> At about the same time this was being considered, I realized that dpkg
> could enable this "safely" by using gcc specs files. But this is in
> any case also required to be able to disable PIE when it is implicitly
> enabled by default in gcc. So we'll need specs files no matter what,
> at least for now.

-no-pie is how PIE has been disabled in the packages where it was 
required, and this was already nearly finished before dpkg started
with the specs.

>...
> 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.

The mess is that gcc and dpkg both try to set policy on PIE.
This should be done in one place.

Both gcc and dpkg would be options for being the one place.
gcc also covers the many packages that are not yet properly
passing flags from dpkg to the compiler, and this default
is working fine for 3 months now.

The number of packages requiring -no-pie was so low that I do not
think any support from dpkg is required for dis/enabling PIE when
gcc enables it by default.

> Alternatively, porters could as well request PIE be enabled by default
> in gcc on their port, which could make this also globally enabled.

This is a very good suggestion.

When PIE works without problems on a port, a porter should request that 
it gets enabled by default for that port in gcc.

When PIE does not work without problems on a port, nothing should 
enable it on that port.

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: manpages.debian.org has been modernized!

[Jonathan Dowland]

Thanks, this is great!


signature.asc
Description: Digital signature

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Thu, 2017-01-19 at 09:35 +0100, Michael Stapelberg wrote:

> To:   Paul Wise 

I'm subscribed :)

> No. Isn’t that a violation of the FHS (see
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA)
> and Debian policy?

I suppose. I don't think we test for it though?

> https://github.com/Debian/debiman/blob/2517d8f6a070890469eb55d0533304a0da642f9e/internal/redirect/redirect_test.go#L237-L257
> should give you a good overview of the URL schema which is now in use.

Thanks for that.

> I guess it depends on your point of view what a “normal URL” really
> is. Maybe I also misunderstood your point — if so, please clarify.

I guess I am talking about the URL you get from the jump redirector
or the future Apache based system.

> Why? In general, I’d like to stick with the conventions that are used
> for displaying manpages whenever a design choice is just about
> personal preference and not about enabling/preventing use-cases.

A website is a different context than terminal manual page viewing.
The usual convention for headings on the web is either "Title Case" or
"Title case". Also, "UPPER CASE" is commonly thought of as shouting
on the web. Also, the web way looks less jarring in a web browser.

> It should be easy to configure a user style sheet to this purpose.
> Just configure font-family of the .mandoc class to your liking.

I think that non-monospace should be the default for the same reasons
we should not have upper-case section titles.

> Could you report this issue upstream at http://mdocml.bsd.lv/ please?

I'll leave that to someone more familiar with the project.

> The truncation is done via CSS. I don’t know how to make the title
> attribute conditional on truncation.

Interesting, me either.

> Couldn’t find that bit on the wiki page. Can you point me to where it
> says that please?

I may have misremembered. Either way it is pointless to have 2 links.

Also, it would be good if the index page didn't say 'index' in the page
title, that is jargon that isn't useful.

> I thought that bit should equal the domain name. Is that incorrect?
> Do you have a reference for what it should contain?

Not necessarily, for example lists.d.o uses 'mailing lists':

https://lists.debian.org/

'manual pages' is slightly less jargony too.

> I’m not sure. In practice, people are going to use the search function
> of their browser anyway. I feel that a long list is easier on the eye
> than a wall of text.

Hmm, perhaps. What about one line per package name?

> Where did you get this URL from? Is that used somewhere, or do you
> just think it would be nice if such a schema worked?

I stripped of the end component since URLs are usually hierarchical.

> I considered this but arrived at the conclusion that a URL becomes
> more useful the longer it references the same document. I.e., if
> someone posts a link to a manpage, I’d like to make sure that — as
> long as said manpage is included in the distributions which we include
> — that URL points to precisely that same manpage. If you wish, you’re
> free to use the redirect functionality and always refer to suite
> names.

Hmm, ok.

Using suite names means that the URLs last longer.
Codenames disappear after a bunch of years.

> Can you elaborate on what you mean?

$ man foo
No manual entry for foo
Download and view manual page for foo? (Y/n)
...

> I don’t want to overwhelm people with an overly long front page.

Fair enough.

> No. Due to the global view of manpages which is required for
> cross-referencing and navigation, a run is somewhat computationally
> costly (see https://github.com/Debian/debiman/blob/master/PERFORMANCE.md
> for wall-clock time numbers). Hence, we intend to do periodic runs,
> with a frequency of 1 or 2 hours.

IIRC that is 6 times shorter than the archive update frequency :)
IIRC mirror push frequency is the same as archive update frequency.
It is pretty pointless to run it more often than those.
Triggering it on mirror pushes would mean that the second the local
mirror is finished updating, the new manual page generation starts.

> Can you explain the motivation for using incoming/archive please?

Using incoming means that new manual pages are available sooner.
Using archive means that I can still look up old manual pages.

> We currently do, unfortunately :). There are TODOs in the source to
> clean that up, but the site will keep working without update for the
> next 2 Debian releases (excluding stretch) even if we don’t get around
> to cleaning it up. Will amend the wiki page in a bit.

Ick, thanks for the wiki edits.

> I intended to contact the ubuntu people and other manpage repositories
> that I know of. Talking to derivatives is a good point, thanks.

Great, thanks.

> Yes, already on my TODO, thanks.

Cool.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#851851: ITP: python-pytest-flakes -- pytest plugin to check source code with pyflakes

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pytest-flakes
  Version : 1.0.1
  Upstream Author : Florian Schulze 
* URL : https://github.com/fschulze/pytest-flakes
* License : Expat
  Programming Lang: Python
  Description : pytest plugin to check source code with pyflakes

 Discover Python source files and run them through pyflakes. You may configure
 pyflakes-checking options for your project by adding an entry to your
 setup.cfg.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAliAmuERHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqMBwf+JZL/d3Fd39Nq2ffucUz+Hu4YfyA2uCFF
MnzksxfaxgL6zlZfYjf/fTkfNuKx91vKmPVubsKuzKvqibNMv/FVs3Nu9ObX57Er
DQPrqRsHuPH19YC4jYi7VRDihBg8OjsNNe3e/1LrH6k+DLSlEZ+YDFCU+BxsLCF4
QVntAYgU36vGQkVwCGaK/asK4gDNw8mhx+Ao0iqy5oDO3NrPrxUidfgqhOjFhQg+
r0zk4Y7tbrntNjSnZx18OC627XovB80wylUUg/os/Roc3lGrcTCkCVWtZh627bL/
mIdDgabQB1G0UX9BYB5jNS9XGyi9rVdt5Z0tjuLxRjFxbv/IpPTA3A==
=6VBT
-END PGP SIGNATURE-

Bug#851863: ITP: prefixfree -- manage CSS3 browser prefixes client-side

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: prefixfree
  Version : 1.0.10
  Upstream Author : Lea Verou
* URL : https://leaverou.github.io/prefixfree
* License : MIT
  Programming Lang: JavaScript
  Description : manage CSS3 browser prefixes client-side

- -prefix-free lets you use only unprefixed CSS properties everywhere. It
works behind the scenes, adding the current browser’s prefix to any CSS
code, only when it’s needed.


I intend to maintain this package inside the Debian JavaScript team,
which I will discuss with them right ahead.

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAliAt9oxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pYpSA//fMda4SfyD0j3GgNp6KfgH8rbIQLf
zZ/U26mhdyw+s4k7oWpnphT+lzJuRuuOgPFiL2A8Uz95FJF8Dq6A9B/YOlLx+Xw1
Mr3x9Shzfr1xBWXgdzwSiWwmUUZW+E8VRqBjT84AdYNmLYMI7M+CHieLPgDbkvUk
OvnySOlHJ4gEuCbF8+M/OXgJc2mIG2uf3qcKE4cYULGD1NBylfgtEB0UELbCNLFj
M+TCBvHn9UScaru5NQXOnHZOZVKwtjMqYmAamxdchbr71Kjmal/cQ4pREBo+6wzU
p0cmTR3FROPsDoriN5+cozXqF9I4Ja/ARdAndZL1B8OW3w64VjOYCgrPujTyvtee
TnIt5zXARC9DGz65ZQDdmXOX9KOcMs1AKFJ14ReiYHTDX3voCxl6eScuB1++ieDY
JvEAbAfq1+KDgZt02TpjvwVtH0Ux+GYnJORUZHQ9w06g4lLvwYPmT7VODPc6GxtJ
0RW/AultzU39J67P5PVc4m0Exp8wnIkQgQSw6c4RQioYuw0G/YZuGqgWabwzy60U
tXHBZ3mPE1JvBJMb3QO+Fl+29jZhK7ndxlSL3vwRnJE8kQEJrD2N1s8vN78fxGD+
6DJi9UUGimic8byVfsrVcIYFuJCaTMJ7EIQfSV3FVgmGikYVGqqedJGY7w+jm6YP
lA05tMPZfZI8sA8=
=jdST
-END PGP SIGNATURE-

Re: no-strong-digests-in-dsc MBF

[Holger Levsen]

On Wed, Jan 18, 2017 at 10:14:46AM +1100, Stuart Prescott wrote:
> The hashes inside the .dsc file are not used in Debian once the package has 
> been accepted by dak. 
> 
> * The trustable way of getting the source package is with apt-get source, 
> when apt verifies the Release signature → hashes → Sources → hashes for each 
> part of the source package: dsc, orig.tar.gz, diff.gz/diff.tar.xz

so this "trustable" way of getting the source packages relies on a piece
of software, dak, running 24/365 on a machine (administrated by some
volunteers in their free time) on the internet, to not to be compromised?

I'm not sure I can really trust this very much.
 
> * The not-really-trustable way of getting the source package is with "dget 
> http://.../package.dsc";. Using the dsc directly, dget will check the 
> signature on the dsc and check the hashes.

I'd really like to see strong hashes used here.

(and btw, let's drop md5sums for buster, "maybe", _completly_, or how long
do we want to be joked about?)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Karriere Wachstum

[general]

Lieber general,

Wir suchen nach Mitarbeitern, die von zu Hause aus arbeiten wollen.
Mein Name ist Margery und ich bin der Personalleiter einer großen, 
internationalen Firma.
Den größten Teil der Arbeit können Sie von zu Hause, das 
heißt, egal wo erledigen.
Bezahlung ist 3000 €-6000 €

Falls Sie an diesem Angebot Interesse haben, besuchen 
Sie bitte unsere Seite


Mit freundlichen Grüßen!
Personalabteilung

Re: manpages.debian.org has been modernized!

[Ian Jackson]

Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
> On Wed, Jan 18, 2017 at 11:37 PM, Ian Jackson
> > 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.
> 
> All pages on manpages.debian.org already include the git revision at
> the bottom of the page, e.g.:
> 
> debiman c17f615, see github.com/Debian/debiman

mariner:~> curl -s 
'https://manpages.debian.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en'
 | grep debiman
mariner:~>

> Hence, you can already check out the exact running version. Is that
> not sufficient?

I'm afraid not (even supposing that the lack of the commitid is just a
bug).  For a debian.org service, I would like to be able to check out
the running version without interacting with a proprietary online
service.

Also, what stops (answer might be workflow, technology, whatever) an
operator who is in a hurry directly updating the running copy without
pushing to github ?

As I say, I don't want to impose more work on you because of my outre'
ethical views.  I would like to solve this problem by providing a
patch that causes debiman to copy its source and its git history to
its own output.  That way you would have to do nothing.

> > 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.
> 
> I personally find the Debian bug system very uncomfortable to use. I
> will begrudgingly accept reports made via the BTS, as I do for the
> Debian packages I maintain. I don’t want to give up using GitHub’s
> issue tracker, though, for my convenience and the convenience of our
> users.

Using github as well is up to you.  I won't try to talk you out of it.
But I think for a service in the .debian.org namespace, bugs should be
reportable without interacting with a proprietary web service.

So thank you for agreeing to work with a system you don't find
comfortable.  You'll see that I have filed a bug against b.d.o
requesting the manpages.debian.org pseudopackage.

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 ("Re: manpages.debian.org has been modernized!"):
> On Thu, Jan 19, 2017 at 4:41 AM, Paul Wise  wrote:
> > The manual page converter seems to use line breaks rather than proper
> > paragraph tags.
> 
> Could you report this issue upstream at http://mdocml.bsd.lv/ please?

AFAICT this program is not packaged for Debian.

I would like the actually-running source code for this too to be
distributed by manpages.debian.org.  Would you accept a patch to do
that ?

(Are you using a version of mdocml running out of a git tree, or
what?  Are there other unpackaged dependencies?)

Thanks,
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.

Missing dependency on Debian Stretch

[hwpplayer1]

There is a missing dependency in wine32 deb package on Debian stretch. Have you 
solved that issue ? 
Mert Gör
--
https://tutanota.com

Re: Missing dependency on Debian Stretch

[humbert . olivier . 1]

> There is a missing dependency in wine32 deb package on Debian stretch. Have 
> you solved that issue ? 

You can fill a bug against the package. Please see : 
https://www.debian.org/Bugs/
If you now which dependency is missing, write it on your report.

Thanks.

Re: manpages.debian.org has been modernized!

[Michael Stapelberg]

On Thu, Jan 19, 2017 at 4:43 PM, Ian Jackson
 wrote:
> Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
>> On Wed, Jan 18, 2017 at 11:37 PM, Ian Jackson
>> > 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.
>>
>> All pages on manpages.debian.org already include the git revision at
>> the bottom of the page, e.g.:
>>
>> debiman c17f615, see github.com/Debian/debiman
>
> mariner:~> curl -s 
> 'https://manpages.debian.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en'
>  | grep debiman
> mariner:~>

You’re querying the old software of manpages.debian.org which will be
turned down soon.

>
>> Hence, you can already check out the exact running version. Is that
>> not sufficient?
>
> I'm afraid not (even supposing that the lack of the commitid is just a
> bug).  For a debian.org service, I would like to be able to check out
> the running version without interacting with a proprietary online
> service.

Would a mirror of the git repository on alioth be sufficient? I had
planned to set that up, but didn’t get around to it yet. Any help with
that would be very welcome.

>
> Also, what stops (answer might be workflow, technology, whatever) an
> operator who is in a hurry directly updating the running copy without
> pushing to github ?

People with the appropriate UNIX permissions (being part of the
“manpages” group) can of course always circumvent any workflow or
safe-guards which are put into place.

Personally, my intention is that the workflow ends up such that the
right thing happens. As the system is new and we’re just rolling it
out now, things are still a bit in flux.

In general, I hear your concern and would like to assure you that I am
working towards the goal of anyone being able to reproduce the exact
output that manpages.debian.org serves. If I fail in that endeavour
within the next month or so, please feel free to poke me again. Until
then, I’d like to ask you to allow us some time to get things settled.

>
> As I say, I don't want to impose more work on you because of my outre'
> ethical views.  I would like to solve this problem by providing a
> patch that causes debiman to copy its source and its git history to
> its own output.  That way you would have to do nothing.

To help me understand the implications of such a patch, can you point
me to an existing implementation of such a patch in another service
please?

>
>> > 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.
>>
>> I personally find the Debian bug system very uncomfortable to use. I
>> will begrudgingly accept reports made via the BTS, as I do for the
>> Debian packages I maintain. I don’t want to give up using GitHub’s
>> issue tracker, though, for my convenience and the convenience of our
>> users.
>
> Using github as well is up to you.  I won't try to talk you out of it.
> But I think for a service in the .debian.org namespace, bugs should be
> reportable without interacting with a proprietary web service.
>
> So thank you for agreeing to work with a system you don't find
> comfortable.  You'll see that I have filed a bug against b.d.o
> requesting the manpages.debian.org pseudopackage.
>
> 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.



-- 
Best regards,
Michael

pkg src:fxlinuxprint didn't start to build for 1+ month

[Roger Shimizu]

Dear powerpcspe and sh4 buildd maintainer,

My package src:fxlinuxprint [0] didn't start to build for 1+ month.
While other package build seems fine (done) even released after
src:fxlinuxprint.
Could you kindly help to start it manually?
Thank you!

[0] https://buildd.debian.org/status/package.php?p=fxlinuxprint

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: [RFC] The PIE unholy mess

[John Paul Adrian Glaubitz]

Please CC me, I'm currently not subscribed to debian-devel

On 01/18/2017 04:34 AM, Guillem Jover wrote:
> It also breaks unrelated stuff as now gcc emits notes when it thinks
> the -specs option should not be passed.

This warning message is very annoying for me as a porter. And it recently
also started to break cmake [1] because cmake does not expect any message
on stderr if a test has been successful.

Thus, can we get rid of this warning message, please?

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851720

-- 
 .''`.  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: manpages.debian.org has been modernized!

[Michael Stapelberg]

On Thu, Jan 19, 2017 at 4:46 PM, Ian Jackson
 wrote:
> Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
>> On Thu, Jan 19, 2017 at 4:41 AM, Paul Wise  wrote:
>> > The manual page converter seems to use line breaks rather than proper
>> > paragraph tags.
>>
>> Could you report this issue upstream at http://mdocml.bsd.lv/ please?
>
> AFAICT this program is not packaged for Debian.

The program is packaged for Debian:
https://packages.debian.org/stretch/mandoc. I have uploaded a backport
which is currently pending in NEW.

>
> I would like the actually-running source code for this too to be
> distributed by manpages.debian.org.  Would you accept a patch to do
> that ?
>
> (Are you using a version of mdocml running out of a git tree, or
> what?  Are there other unpackaged dependencies?)

I am using a slightly patched version indeed. The patch will be sent
upstream within the next few days.

-- 
Best regards,
Michael

Re: pkg src:fxlinuxprint didn't start to build for 1+ month

[John Paul Adrian Glaubitz]

Hi Roger!

On 01/19/2017 06:27 PM, Roger Shimizu wrote:
> My package src:fxlinuxprint [0] didn't start to build for 1+ month.
> While other package build seems fine (done) even released after
> src:fxlinuxprint.
> Could you kindly help to start it manually?

Both powerpcspe and sh4 are currently having insufficient resources to
keep up with the rest.

For sh4, I *do* have the hardware thanks Paul Liu who brought me eight
NextVoD boxes from Taiwan during DebConf16. However, I cannot boot anything
more recent than Linux 2.6.32 on these boxes at the moment since ST40
(a variant of SuperH) support was removed from Linux mainline.

Re-adding ST40 support is currently an undergoing effort and I hope to
finish it within the next months. After that, I will have at least
five additional sh4 up and running.

As for powerpcspe, I normally have two reasonably fast buildds running
(two A-EON Tabor A1222 PPC e500v2 boards, dual-core clocked at 1.2 GHz
 with 4 GiB RAM and a Toshiba 120 GiB SSD). Unfortunately, one of the
boards had issues and I had to sent it to A-EON for RMA around November.

They still haven't managed to send me a fixed board or a new one, so I
will need to make some pressure. They wanted to do some analysis of
the hardware first.

Cheers,
Adrian

-- 
 .''`.  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: manpages.debian.org has been modernized!

[Ian Jackson]

Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
> On Thu, Jan 19, 2017 at 4:43 PM, Ian Jackson
>  wrote:
> > mariner:~> curl -s 
> > 'https://manpages.debian.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en'
> >  | grep debiman
> > mariner:~>
> 
> You’re querying the old software of manpages.debian.org which will be
> turned down soon.

I got that page as follows:

Type into my browser address bar
  https://manpages.debian.org/
This redirects to
  https://manpages.debian.org/cgi-bin/man.cgi
and then if I type in details I get a url like the above.

Hrm.

I just looked with HEAD(1) and I don't get the redirect.

Is it possible that there was previously a permanent redirect issued
from the toplevel URL to this cgi-bin one ?  I'm not sure how to
bypass such a thing.

> > Also, what stops (answer might be workflow, technology, whatever) an
> > operator who is in a hurry directly updating the running copy without
> > pushing to github ?
> 
> People with the appropriate UNIX permissions (being part of the
> “manpages” group) can of course always circumvent any workflow or
> safe-guards which are put into place.

Of course.  But the question is: is circumventing this ever the
easiest way to fix things ?

My experience of running online services is that in a crisis it can
sometimes be most convenient (fastest!) to use some kind of ad-hoc
deployment method, up to and including editing the running code
directly in a text editor.

Obviously there are risks to that kind of thing, but I want the
service operator to think about keeping the service running, and *not*
to have to worry about publishing source code.

> > As I say, I don't want to impose more work on you because of my outre'
> > ethical views.  I would like to solve this problem by providing a
> > patch that causes debiman to copy its source and its git history to
> > its own output.  That way you would have to do nothing.
> 
> To help me understand the implications of such a patch, can you point
> me to an existing implementation of such a patch in another service
> please?

dgit
  client
https://browse.dgit.debian.org/dgit.git/tree/dgit#n6316
(Currently broken in sid's dgit, 3.6, *sigh*, #851906)
  server side
https://browse.dgit.debian.org/dgit.git/tree/infra/dgit-ssh-dispatch#n167
  docs, search for `clone-dgit-repos-server'
https://manpages.debian.org/testing/dgit/dgit.1.en.html
  clone the server side for yourself
git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/_dgit-repos-server.git
  NB this is the source to the special git server that `dgit push'
  talks to; browse.dgit.d.o is simply git repos published using cgit.

yarrg (yes, really, I have been known to play proprietary online
games, for which this is a fully Free helper service):
  intro docs for developers
http://yarrg.chiark.net/devel
  source code

http://www.chiark.greenend.org.uk/ucgi/~yarrgweb/git?p=ypp-sc-tools.web-live.git;a=blob;f=yarrg/web/source.tar.gz;h=0e47a83e38d755720427b9c453db6bed6cf33288;hb=HEAD

http://www.chiark.greenend.org.uk/ucgi/~yarrgweb/git?p=ypp-sc-tools.web-live.git;a=blob;f=yarrg/Commods.pm;h=5d0ffe29fd46b8dd7b06802655b84d132ec9f100;hb=HEAD#l493

Thanks,
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 ("Re: manpages.debian.org has been modernized!"):
> On Thu, Jan 19, 2017 at 4:46 PM, Ian Jackson
> > AFAICT this program is not packaged for Debian.
> 
> The program is packaged for Debian:
> https://packages.debian.org/stretch/mandoc. I have uploaded a backport
> which is currently pending in NEW.

Oh it's mandoc.  OK, sorry for misreading the web page.

Are you using the backport on the manpages.d.o server, then ?

> > (Are you using a version of mdocml running out of a git tree, or
> > what?  Are there other unpackaged dependencies?)
> 
> I am using a slightly patched version indeed. The patch will be sent
> upstream within the next few days.

The source for this patched version is in only available in NEW ?
(Ie only to DDs ?)

You see, I find this kind of chasing tiresome - whether I'm the user,
or the service operator.  I expect you do too.  Of course you're
probably hoping not to need to patch mandoc again.

How did you deploy the patched mandoc ?  I want to know this so I can
know how the source code can be automatically found and published.

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!

[Peter Palfrader]

Ian Jackson schrieb am Donnerstag, dem 19. Jänner 2017:

> Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
> > On Thu, Jan 19, 2017 at 4:46 PM, Ian Jackson
> > > AFAICT this program is not packaged for Debian.
> > 
> > The program is packaged for Debian:
> > https://packages.debian.org/stretch/mandoc. I have uploaded a backport
> > which is currently pending in NEW.
> 
> Oh it's mandoc.  OK, sorry for misreading the web page.
> 
> Are you using the backport on the manpages.d.o server, then ?

You know, you could just check.. :)

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Git hosting for code that provides Debian services (was: manpages.debian.org has been modernized!)

[Ben Finney]

Ian Jackson  writes:

> For a debian.org service, I would like to be able to check out the
> running version without interacting with a proprietary online service.

I have been looking at the GitLab instance hosted at FOSS Community
India's servers, https://git.fosscommunity.in/>. It's been working
fine for a few months.

Do the FOSS Community India people want us to make larger use of that
GitLab instance for general Debian code bases?

> Using github as well is up to you. I won't try to talk you out of it.
> But I think for a service in the .debian.org namespace, bugs should be
> reportable without interacting with a proprietary web service.

I believe the GitLab running at the above URL is entirely free software.

> So thank you for agreeing to work with a system you don't find
> comfortable. You'll see that I have filed a bug against b.d.o
> requesting the manpages.debian.org pseudopackage.

I would agree that the Debian BTS is important to maintain as the
primary bug reporting system for the Debian Project, in general. Even if
other platforms offer their own separate BTS, we strongly direct people
to the Debian BTS and it is important to have that as a first-class
venue for discussing bug reports.

-- 
 \  “In the long run, the utility of all non-Free software |
  `\  approaches zero. All non-Free software is a dead end.” —Mark |
_o__)Pilgrim, 2006 |
Ben Finney

Work-needing packages report for Jan 20, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1032 (new: 6)
Total number of packages offered up for adoption: 152 (new: 2)
Total number of packages requested help for: 45 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   bmon (#851804), orphaned yesterday
 Description: portable bandwidth monitor and rate estimator
 Installations reported by Popcon: 2423
 Bug Report URL: http://bugs.debian.org/851804

   giggle (#851836), orphaned today
 Description: GTK+ frontend for the git directory tracker
 Reverse Depends: giggle-personal-details-plugin
   giggle-terminal-view-plugin
 Installations reported by Popcon: 780
 Bug Report URL: http://bugs.debian.org/851836

   git2cl (#851816), orphaned today
 Description: simple tool to convert git logs to GNU ChangeLog format
 Installations reported by Popcon: 115
 Bug Report URL: http://bugs.debian.org/851816

   libgit2-glib (#851451), orphaned 4 days ago
 Description: glib wrapper library around the libgit2 git access
   library
 Reverse Depends: gedit-plugins gir1.2-git2-glib-1.0 gitg
   gnome-builder libgit2-glib-1.0-dbg libgit2-glib-1.0-dev
 Installations reported by Popcon: 46927
 Bug Report URL: http://bugs.debian.org/851451

   soundmanager2 (#851289), orphaned 6 days ago
 Description: cross-platform audio player API
 Installations reported by Popcon: 24
 Bug Report URL: http://bugs.debian.org/851289

   virglrenderer (#851490), orphaned 4 days ago
 Description: virtual GPU for KVM virtualization
 Reverse Depends: libvirglrenderer-dev qemu-system-arm
   qemu-system-mips qemu-system-misc qemu-system-ppc qemu-system-sparc
   qemu-system-x86
 Installations reported by Popcon: 2475
 Bug Report URL: http://bugs.debian.org/851490

1026 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   dh-exec (#851746), offered yesterday
 Description: Scripts to help with executable debhelper files
 Installations reported by Popcon: 682
 Bug Report URL: http://bugs.debian.org/851746

   dphys-config (#851797), offered yesterday
 Description: Tool to distribute config files by fetching them
 Installations reported by Popcon: 67
 Bug Report URL: http://bugs.debian.org/851797

150 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4468 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 20
 Bug Report URL: http://bugs.debian.org/278442

   autopkgtest (#846328), requested 50 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 687
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 1943 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 684
 Bug Report URL: http://bugs.debian.org/642906

   cardstories (#624100), requested 2096 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7
 Bug Report URL: http://bugs.debian.org/624100

   cups (#532097), requested 2784 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 172622
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 484 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (128 more omitted)
 Installations reported by Popcon: 191031
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 188 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 62574
 Bug Report URL: ht

Re: manpages.debian.org has been modernized!

[Kushal Kumaran]

Ian Jackson  writes:

> Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
>> On Thu, Jan 19, 2017 at 4:43 PM, Ian Jackson
>>  wrote:
>> > mariner:~> curl -s 
>> > 'https://manpages.debian.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en'
>> >  | grep debiman
>> > mariner:~>
>> 
>> You’re querying the old software of manpages.debian.org which will be
>> turned down soon.
>
> I got that page as follows:
>
> Type into my browser address bar
>   https://manpages.debian.org/
> This redirects to
>   https://manpages.debian.org/cgi-bin/man.cgi
> and then if I type in details I get a url like the above.
>
> Hrm.
>
> I just looked with HEAD(1) and I don't get the redirect.
>
> Is it possible that there was previously a permanent redirect issued
> from the toplevel URL to this cgi-bin one ?  I'm not sure how to
> bypass such a thing.
>

What web browser are you using?  A few ways to clear out old
301-redirects in Firefox are discussed here:
https://superuser.com/questions/467999/clear-301-redirect-cache-in-firefox

-- 
regards,
kushal

Bug#851940: ITP: certspotter -- Certificate Transparency Log Monitor

[Faidon Liambotis]

Package: wnpp
Severity: wishlist
Owner: Faidon Liambotis 

* Package name: certspotter
  Version : 0.2
  Upstream Author : Opsmate, Inc.
* URL : https://github.com/SSLMate/certspotter
* License : MPL-2.0
  Programming Lang: Go
  Description : Certificate Transparency Log Monitor

 Cert Spotter is a Certificate Transparency log monitor from SSLMate that
 alerts you when a SSL/TLS certificate is issued for one of your domains.
 Cert Spotter is easier than other open source CT monitors, since it does
 not require a database. It's also more robust, since it uses a special
 certificate parser that ensures it won't miss certificates.
 .
 Cert Spotter is also available as a hosted service by SSLMate that
 requires zero setup and provides an easy web dashboard to centrally
 manage your certificates. Visit 
 to sign up.
 .
 You can use Cert Spotter to detect:
  * Certificates issued to attackers who have compromised a certificate
authority and want to impersonate your site.
  * Certificates issued to attackers who are using your infrastructure
to serve malware.
  * Certificates issued in violation of your corporate policy
or outside of your centralized certificate procurement process.
  * Certificates issued to your infrastructure providers without your
consent.

I intend to maintain this under pkg-go.  Andrew Ayer (Cc'ed) is the
upstream author and also a DM (Andrew, if you want to maintain this
instead, happy to take a step back).