Re: Non-free RFCs in stretch

[Paul Wise]

On Wed, Mar 8, 2017 at 12:16 PM, Tollef Fog Heen wrote:

> A package can only be in a single section.

That wouldn't prevent adding subsetted Packages files:

deb http://ftp.debian.org/debian/ unstable main non-free/firmware non-free/docs

Types: deb
URIs: http://ftp.debian.org/debian/
Suites: unstable
Components: main non-free/firmware non-free/docs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mining system information of bugs

[Paul Wise]

On Thu, Feb 23, 2017 at 2:16 AM, Adam Borowski wrote:

> Anything else you'd want me to get?  Core counts for >1?  UTC hours or days
> of week when bugs are filed?  Kernels that've been in the archive vs those
> that haven't?

I'd be interested in stats of Debian releases, preferred suites, apt
policies and how many bugs were filed from systems running Debian
derivatives, or other distros if any.

BTW, I added a link to this thread in the Debian statistics page:

https://wiki.debian.org/Statistics?action=diff=162=163

Are you planning on producing these graphs/stats continuously/automatically?

Got any information on how they were produced?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help requested: Packages which FTBFS randomly

[Paul Wise]

On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:

> This is a charming idea altough I have doubt it will work out: As
> usual the information has to be kept up-to-date, so unless it is
> collected and verified every now and then automatically, it will
> become unsuable pretty soon.

FYI the buildds are automatically collecting disk usage information,
see the last line of each build log.

Of course, that information isn't parsed and stored anywhere yet.

I guess collecting memory usage would be much harder, especially if
multiple packages are built in parallel.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Personal Git repositories on Alioth (was: manpages.debian.org has been modernized!)

[Paul Wise]

On Sat, Feb 18, 2017 at 9:39 AM, Ben Finney wrote:

> Does the resulting repository automatically get published on Alioth,
> managed by ‘cgit’ at a ‘anonscm.debian.org’ URL?

cgit doesn't do any management, it just publishes existing repos.

User repositories are available at URLs like these:

https://anonscm.debian.org/cgit/users/wouter/ipcfg.git/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: lircd daemon as regular user => device access problems

[Paul Wise]

On Fri, Feb 10, 2017 at 11:13 PM, Alec Leamas wrote:

> Thoughts?

Your post reminds me of the uaccess and AppStream items here:

https://lists.debian.org/debian-devel-announce/2016/11/msg8.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Mon, Jan 30, 2017 at 8:54 PM, Alec Leamas wrote:

> But, we cannot just say "our tools are as good as github".
> Because they are not.

That is a very subjective statement. I for one really really dislike
github and much prefer other workflows.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Running Debian in the Web browser (JS VM)?

[Paul Wise]

On Thu, Jan 26, 2017 at 11:25 PM, Olivier Berger wrote:

> Is anyone working on a "port" of Debian for running in the browser,

Probably WebAssembly is a better bet for a Debian port to browsers.

> over the JS VM, like what jor1k [0] does ?

There was a Debian port to OpenRISC, but it is dead due to the code
not being able to be merged into GCC upstream due to copyright issues.

PS: some more port ideas:

https://wiki.debian.org/Ideas/Ports

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: HELP - Español and English

[Paul Wise]

On Thu, Jan 26, 2017 at 11:16 PM, Jeans Manuel Morell Veliz wrote:

> Can you tell me what is happening to the Debian system?

Please contact the Debian user support channels for help:

https://www.debian.org/support

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: New user willing to help with Wayland WM packages

[Paul Wise]

On Thu, Jan 26, 2017 at 8:11 AM, Riley wrote:

> I am not a DD yet, but I am looking to offer any help I can

These pages might be interesting to you:

https://www.debian.org/intro/help
https://wiki.debian.org/how-can-i-help

> Mainly I want to focus on packaging Wayland
> tiling window managers, starting with...

Check out the intro to packaging here:

https://mentors.debian.net/intro-maintainers

When you have questions, please ask on #debian-mentors on OFTC.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Wed, 2017-01-25 at 09:09 +0100, Michael Stapelberg wrote:

> Could you please verify whether the -based fallback works for
> you? See https://people.debian.org/~stapelberg/fallback/i3.1.en.html
> for a demo.

The SVG is downloaded but there is no fallback on high security.
I wouldn't worry about it, not an issue many folks will see.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: [Pkg-rust-maintainers] Release impact of introducing a new archive section?

[Paul Wise]

On Tue, Jan 24, 2017 at 4:30 AM, Josh Triplett wrote:

> How long does it typically take for that to sync to
> https://packages.debian.org/unstable/ and (for instance)

The descriptions for that are hardcoded in lib/Packages/Sections.pm,
you might want to submit an update for the master branch of that too.

https://anonscm.debian.org/cgit/webwml/packages.git

I've updated the wiki page to mention this:

https://wiki.debian.org/NewArchiveSections?action=diff=6=4

> https://packages.debian.org/sid/rustc , as well as to the Packages file?

There doesn't appear to be any section info on that page.

The Packages file has already been updated:

$ apt-cache showsrc rustc | grep Section
Section: rust

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Mon, 2017-01-23 at 08:47 +0100, Michael Stapelberg wrote:

> Could you clarify how I can implement a fallback in a way that works
> for Tor Browser please?

The  solution here appears to work:

https://css-tricks.com/a-complete-guide-to-svg-fallbacks/#fallback-object

In this case, the page constrains the SVG image to the same number of
pixels as the equivalent PNG image and the PNG image is a smaller
number of bytes and probably renders faster so I think just use PNG.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Mon, 2017-01-23 at 08:45 +0100, Michael Stapelberg wrote:

> What would be the best way to trigger on mirror pushes?

I'm not sure about that, please ask #debian-mirrors
or failing that #debian-admin, and or the lists.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: manpages.debian.org has been modernized!

[Paul Wise]

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

> To:   Paul Wise <p...@debian.org>

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

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: 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: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Paul Wise]

On Wed, Jan 18, 2017 at 1:08 AM, Russ Allbery wrote:
> Santiago Vila writes:
>> In this context, I refer specifically to flaky tests. What I call
>> questionable is keeping a flaky test making the build to fail when the
>> test fails so much that it's clearly a wrongly designed test.
>
> 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).
>
> Some upstream test suites also make it a little difficult to disable a
> single test without carrying a patch.  (Hm, including mine)

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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted check-all-the-things 2017.01.15 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 15 Jan 2017 10:37:30 +0800
Source: check-all-the-things
Binary: check-all-the-things
Architecture: source
Version: 2017.01.15
Distribution: unstable
Urgency: high
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 check-all-the-things - check all of the things!
Changes:
 check-all-the-things (2017.01.15) unstable; urgency=high
 .
   * New release.
 - The "Check Things Securely Not Portably" release
 - Reset terminal modes after commands to avoid colour spew
 - Improve compatibility with Python 3.6
 - Update python checks to not work on other distros
   because the `python -m` command is insecure
 - Update checkers removed from Debian - allow to run if installed
 - Update lrzip-test/zstd-test - add MIME types
 - Add lz4-test - check lz4 compressed files
 - Add path-max - check for non-portable path size macros
 - TODO items for deep-text-correcter sblint decopy
Checksums-Sha1:
 b547776118a70613b16afd3d48cdee3bd0ac0dd1 1709 
check-all-the-things_2017.01.15.dsc
 f44b5f6b2cb529c5e2bc0d59dab53ff4c9cb7ddb 30648 
check-all-the-things_2017.01.15.tar.xz
Checksums-Sha256:
 92e50dc8cd9f156fc22e0f589049c4439809e2a5b3c60eeb6cbf296e72473751 1709 
check-all-the-things_2017.01.15.dsc
 6f90ffb1a80e14a87ae631b1594aa52fd68aacd1e309a5458d4356c1f0ff44e2 30648 
check-all-the-things_2017.01.15.tar.xz
Files:
 5aa0ad01860269d339b274e71d79719d 1709 devel optional 
check-all-the-things_2017.01.15.dsc
 38c44162473865848f761091f7e8950e 30648 devel optional 
check-all-the-things_2017.01.15.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlh64vsACgkQMRa6Xp/6
aaMxJxAAhdIOA8Fnbassa8hwVSOBSo86aeC5R34yZmuC+5iAzLt3oxociHVMFSFT
5BGjcYylqjM8Oosg5JeENcnyIkVJbZSEBDzmMnC7OtIkkyy1XPKBAFYbRh34R7jb
VfALrDbdXi6XbxheIGf6EUDeYNzIdTADDX5jcZnqzQj45BTBh/xD+aK0tySbs+e7
0r2jYQbG1CeQsKYmIltpOswKH0tKbyT3GpTCXvNXYc/tU41Qnw+dHTToROlY78wG
h4B3D3YVct5ru3IzbrJeZ/DomfGlIDb5l/TP6RIi5mzu2Dfcn6DiMIsXDGgJfwCg
hvFxx27UvyUokAEoSXDySiis5uYZkA4BJY3kdD33by2sPL1rAuYDcoqNBiXs7xZW
T0k0VTgX0OhBkwTZeq3vRkUIPTmH3AzFWA0P0Xx78QF+jpBbFTMzI9/mLvWbExm/
8xg4WImawA1DDIRm40XqEXOOB0HbfbMeNLCRqjURdAL6DJCbM4bEfhxrg+Ba9rYx
NHzIWRP9CvD/cxLNZe0YTA+JCcfj1BY+XtoUGyYBpv0vi2bsjGpMGUHlQY9OpduU
com8wdEV9JHoNb9mYmdVJe8lbEBOQleJleaV4eIcxfLpWYjACa2vUFtzH3z6rgxH
QbEG150reu6FVNE3FTHM+URsigqDsrRS+6gXvGBOL3PwgbX6h9U=
=gmxt
-END PGP SIGNATURE-

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Sun, Jan 8, 2017 at 8:05 PM, Johannes Schauer wrote:

> I'm not very familiar with pbuilder. Looking at the man page it seems that
> pbuilder itself exclusively accepts a source package .dsc and for building a
> source directory one needs the pdebuild wrapper?

Right.

> If that is the case, then it seems sensible for sbuild to do the same as
> pdebuild if given a source directory only. Both tools should behave the same
> way when executed in the same context, I think.

An sdebuild script sounds good to me.

> Are there any reasons against this plan? (targeting Buster)

Longer-term, I think we want debuild and possibly pdebuild to become
just `exec dpkg-buildpackage` so we should probably think about where
the code for this should live.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Newcomer to Debian: Help wanted

[Paul Wise]

On Sun, Jan 8, 2017 at 5:05 PM, Vijeth T Aradhya wrote:

> Hey guys I'd like to start contributing to Debian and be a part of the
> community. I just need some help getting started!

Great! Here are some ideas for things to work on:

https://www.debian.org/intro/help

> When I looked at the bug tracker system, it was very difficult for a
> newcomer to Debian like me, to get started to solve easy bugs.

Check out the list of bugs tagged newcomer:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=newcomer

> I have already looked at many links for getting started. It'd be great if
> you guys can lead me directly to fixing bugs in languages like C, Python or
> Haskell. I'm really sorry, but I did not get enough information on where and
> how to get started. Can you guys help me out? Thanks!

A great way to find packages to work on is the how-can-i-help tool:

https://wiki.debian.org/how-can-i-help

Also, you can use the debtags site to find packages tagged as being
implemented in C/Python/Haskell. Then click through to the bugs pages.

https://debtags.debian.org/search/?q=implemented-in%3A%3Ac+implemented-in%3A%3Apython+implemented-in%3A%3Ahaskell

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default

[Paul Wise]

On Sat, Jan 7, 2017 at 6:29 AM, Nikolaus Rath wrote:

> What now?

Clearly the answer of unattended-upgrades or not is situation
dependent and the solution should depend on who is running Debian in
what context.

Desktop users should get whatever UI is available for the particular
desktop that is installed that installs upgrades on shutdown and
suggests upgrades when available.

Cloud users should get unattended-upgrades by default.

etc

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Paul Wise]

On Fri, Jan 6, 2017 at 3:27 AM, Sean Whitton wrote:

> Could you explain "lower bus factor" a bit more, please?

Don already explained this for the BTS, but in general, many if not
most of the services Debian provides are maintained by 0.5 person (one
busy person who already has lots of other responsibilities) or 1
person teams.

If you or others have time to spare, please consider regularly
spending time on some of the services Debian provides or becoming
co-maintainer of one of them:

https://wiki.debian.org/Services

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Hiding library packages from apt searches by default? (was: Re: Worthless node-* package descriptions in ITPs)

[Paul Wise]

On Thu, Jan 5, 2017 at 9:32 PM, Christian Seiler wrote:

> Could we maybe hide library packages from apt searches by default?

This is going to have unintended consequences; for example, if we base
it on Debian Section fields, library source packages that build a
binary package containing tools, that are (incorrectly) put into the
libs section, will not be found by users.

> I think most users don't care about libraries in any language (be it
> Perl, C, JS, Python, ...), but only care about software they
> use directly. And developers that do care about libraries could pass
> a flag to APT to say "yeah, please show me all packages that match
> this". And maybe even indicated how many library packages were not
> shown in the default search results?

How would you propose to implement that? apt currently doesn't have
enough metadata about packages to say if they are end-user tools or
not, and it depends on the user which tools are acceptable. For
example; some folks can deal with the command-line but the majority of
humanity cannot, some folks dislike particular GUI toolkits, etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote:

> But I am not sure if a package structure like
>
> mypkg/upstream/*
> mypkg/debian/*
> mypkg/patches/* (?)
>
> would have any *practical* benefits over the current situation, because
> this transformation could be trivially automated in either direction.
>
> Or did you have something else in mind?

TBH, I haven't thought much about what an alternative should look like.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote:

> I'm interested in what things people still find so off-putting to the
> point of not wanting to use the new 3.0 source formats.

I've been reading this thread and keep being reminded of our
discussion on #debian-dpkg a while ago.

I think most of the complaints about Debian source package formats are
rooted in a design mistake made early on. The debian/ directory. The
debian/ dir controls the upstream source but is in a subdirectory of
the upstream source. The directory hierarchy is an inverse of the
relationship between its parts. The debian/patches/ dir is another
layering violation on top of that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Feedback on 3.0 source format problems

[Paul Wise]

On Wed, Jan 4, 2017 at 2:54 AM, Russ Allbery wrote:

> Well, if we had one more thing: a patches.debian.org service that would
> show the git-debcherry-extracted patches against upstream.  I really like
> being able to just point upstream at all the patches relevant to them that
> Debian has applied.

I doesn't yet support non-quilt source formats, but:

https://sources.debian.net/patches/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted autorevision 1.20-1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 04 Jan 2017 10:03:03 +0800
Source: autorevision
Binary: autorevision
Architecture: source
Version: 1.20-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 autorevision - extracts revision metadata from your VCS repository
Changes:
 autorevision (1.20-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 39dafab3abde7b9802adb970dd56b9fe11e177de 2047 autorevision_1.20-1.dsc
 066dbe7b981f400bb87390a7886680feee290b76 20026 autorevision_1.20.orig.tar.gz
 ee8ae2f04b99222eb9ea9c5011ee651832c02663 1535 autorevision_1.20.orig.tar.gz.asc
 3c938a948592b779435410748aaeb405bea928d9 37512 
autorevision_1.20-1.debian.tar.xz
Checksums-Sha256:
 f71ce031a45803e95cb2365bd15797b8eac38a85842b57684b5a6f3a9aad 2047 
autorevision_1.20-1.dsc
 1ed2ff8614c365384a8de435931bafce4417b538222a44d0cd27ec2d2c3f97f6 20026 
autorevision_1.20.orig.tar.gz
 5fb3ebeef87c284863f4935002ae931df402fe55d9229048f9422edeebcd92c8 1535 
autorevision_1.20.orig.tar.gz.asc
 2631e42da8ed5c17095a7e70dfd205cb35ce78f33e362564111ad46c250366de 37512 
autorevision_1.20-1.debian.tar.xz
Files:
 2b23db5e8ab5baa5b8b3f544ac08849f 2047 devel optional autorevision_1.20-1.dsc
 27f390d702f481fe943146d29239f005 20026 devel optional 
autorevision_1.20.orig.tar.gz
 32c5fb094e5fd19cb05cd9c36fd38070 1535 devel optional 
autorevision_1.20.orig.tar.gz.asc
 16b01653ae9fa33b30794bfa241999f4 37512 devel optional 
autorevision_1.20-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlhsWB8ACgkQMRa6Xp/6
aaOzBw/9F38yYdUgkonSW2hWJ01z65e4PbtLAGIN8P6r+LnRxQoAFouY8TLVc8Ai
WlGrchIdZKFfMyxnJT+rDKCuO1rOvF0v3hwoAPAMRSXpAfQb5ae7fWPuceAa5Jsl
9/y6SzaOKCuN1XwvdubhXsWkmZeBzeLCWWrU3kB2TJQoFL97ge9Wpole7k45Vfbr
OUkdiT1GQKevjE9Gly2pJnqozQKVu9BzbMmy6RxWUokJ1vnFyzMhawpudbvxB+1O
5q/YRPP9AY+C8Xo5ND0jxGSp/oq1Z8xPq2Vy5UOIbjBzKTN965VYL7f0RYgNUOPe
Igb/wkVJixgU8OQJG4QZvEAmNf0dvB2TOjWoBChla5eJXzy2n2Bipb7lyZJYGuL1
8dT5nRKYbt/Lh1AgGgjgJ6O4ovgQadJ/xfuuJddR3dI5vaGghQ6xyN3FH/5EABQm
27dFyckIpoPDHH24Z25U67qFJEBviyaM/93edFSGo2J0ftGVMrgPkQWN1JqqWiBt
sBlqSxi+11iHd3WIvT1Z7XaeR85slmq80DhQLPuF9WURtwKxudH1xaeAIZTOAcJY
2A73YojshyXlvKnQLq5TOkPpvzkQNdQEoqSqKFTciZCC4N5vcBvOQwhJegRJAieu
thAfnUeB9nhdwLwFz/yzJg1DpvPBd1jtvp+TVv73FfH1jg8u5EM=
=JOvm
-END PGP SIGNATURE-

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Paul Wise]

On Tue, Jan 3, 2017 at 5:38 PM, Abou Al Montacir wrote:

> What about requiring signed mail for closing a bug report?

We have sponsored maintainers, who theoretically could get by entirely
without an OpenPGP key. I don't know if any exist but I don't think
they should be blocked from -done. Also, many other contributors don't
have access to their OpenPGP key at all times and they shouldn't be
blocked from -done.

The solution is simply a lower bus factor in all Debian services,
including the BTS and more maintenance of the BTS spam filtering
rules.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Paul Wise]

On Tue, Jan 3, 2017 at 2:28 AM, Andrey Rahmatullin wrote:

> Probably we don't have enough people looking at the spam reports. That
> probably could be improved with better advertising, e.g. on
> https://www.debian.org/intro/help

Right now only the BTS admins can look at and act on spam reports. It
might be better to have a lists.d.o style infra for Debian members to
collaboratively remove spam.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/
http://wiki.openmoko.org/wiki/User:PaulWise

Re: wanna-build doesn't email the maintainer on build failures by default

[Paul Wise]

On Sat, Dec 31, 2016 at 9:23 PM, Mattia Rizzolo wrote:

> But you should probably remove mips64el, which is a release arch now.

Not hard-coding the list of release architectures would be best.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Paul Wise]

On Tue, Dec 27, 2016 at 7:03 AM, Ian Jackson wrote:

> When I decided that debbugs should work like this:

I think this was the right decision and still is, with this additional reason:

Folks are much busier these days and every extra unnecessary email
takes extra time and brain space that could be spent on other tasks
and thoughts.

>  * Make all submitters of new bugs be subscribed by default.

I definitely do not want this myself and I don't think it is a good
idea, for the reasons you mentioned and more importantly for the one I
mentioned. If it changes, I would want a way to disable subscription
for all bugs I submit. Probably a good idea to have a Subscribe: yes
option at submit@ time too.

> An alternative, more comprehensive approach, would be:

I think it would be enough to just add options for subscription at
submit@ time and on a per-email-address basis. Even better would be a
full bugzilla-style email preferences thing.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Paul Wise]

On Tue, Dec 27, 2016 at 12:29 AM, Samuel Thibault wrote:

> This happens again and again...  Quite a few maintainers don't seem to
> realize that mails sent to n...@bugs.debian.org are not sent to the bug
> submitter, and the bug tracking thus halts down completely when the
> maintainer asks for information only to the bot, and not to the human.

Could someone add a paragraph to DevNews so this reaches d-d-a?

https://wiki.debian.org/DeveloperNews

Perhaps we need a wiki page containing things people need regularly
reminding about?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul Wise]

On Tue, Dec 27, 2016 at 12:35 AM, Paul van der Vlis wrote:

> I use a script on a few servers to realize this, it's not perfect:
> http://vandervlis.nl/files/updateafter

It might be interesting to contribute this to unattended-upgrades.

> I use "at" to reboot very early in the morning:

/etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#817602: olpc-xo1: Removal of debhelper compat 4

[Paul Wise]

On Sun, Dec 25, 2016 at 10:38 AM, Andres Salomon wrote:

> Thanks for the patch.  Given that OLPC isn't really alive any more,
> I'm thinking the OLPC packages should probably just be removed from the
> archive for Stretch.  Popcon shows exactly 1 installation of this
> package.. https://qa.debian.org/popcon.php?package=olpc-xo1

I think you will find that OLPC is still active and recently made a release:

http://lists.laptop.org/pipermail/devel/2016-December/thread.html

They also have a Debian derivative:

https://wiki.debian.org/Derivatives/Census/OLPC

I've asked James to respond to your mail.

I expect most OLPC XO1 devices exist in offline mode and couldn't
submit to popcon even if they were configured to.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul Wise]

On Sun, Dec 25, 2016 at 8:34 AM, Paul van der Vlis wrote:

> I am doing this myself already on desktop systems so I have some
> experiences with it.

Thanks for sharing your experience.

> What I would really like is a mechanism where the user can tune after
> how many days the upgrade will occur. Maybe a default could be after 2
> days. People who like to have faster updates can change this to 0 days,
> and this people do extra testing of the updates. When big problems occur
> with an update, the installation of the update should be stopped in some
> way for the people who have set it at 2 days.

How do you propose to transmit the info about problematic updates from
early testers to folks who update later?

> It would be nice to have a way to configure a notice (by e-mail?) in
> case of an error apt or dpkg error.

/etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailOnlyOnError "true";

> I would like something as "apt-get update; apt-get dist-upgrade".
> So not only "apt-get upgrade", and for everything in sources.list, so
> not only for security updates. I would like to go from Debian 9.1 to
> 9.2, but not from Debian 9 to 10.

/etc/apt/apt.conf.d/50unattended-upgrades:
Set Unattended-Upgrade::Origins-Pattern to match which packages you
want to upgrade.

> Using a program what has been upgraded can give strange problems. I have
> seen this e.g. with e-mail clients and browsers. I would like it when
> desktop users could get a message that programs has to be restarted.
> Not sure this is important for servers too, I would think so.

apt install needrestart needrestart-session

> I don't think it's an good idea to enable automatic reboots by default.

I think we either need a Linux kernel livepatch service or automatic reboots.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted check-all-the-things 2016.12.25 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 25 Dec 2016 08:02:09 +0800
Source: check-all-the-things
Binary: check-all-the-things
Architecture: source
Version: 2016.12.25
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 check-all-the-things - check all of the things!
Changes:
 check-all-the-things (2016.12.25) unstable; urgency=medium
 .
   * New release.
 - The "Check Everywhere For Tangerines" release
 - Improve the 'no specific checks' remark
 - Update php-syntax-check - ignore no files warning
 - Update empty - never print inode/x-empty as unchecked
 - Update pylint - check text/x-python files too
 - Update python checks to work on other distros
 - Add make - check Makefiles with GNU make
 - Add pkg-config - check pkg-config .pc files
 - Add t1lint - check Type 1 font files
 - Add zstd-test - check zstd compressed files validity
 - TODO items for urlycue multivalent pdf-hul pdfavalidation
   huntbugs spotbugs find-sec-bugs binskim
Checksums-Sha1:
 30e7e4180e702933c497003a179fe7700b1d39d6 1709 
check-all-the-things_2016.12.25.dsc
 2d5219db6acea9cd3666c7e8dadfda4067f0f26d 30196 
check-all-the-things_2016.12.25.tar.xz
Checksums-Sha256:
 c20f7d8d92d219112dc1bd7e7622d12540487d52c61e79f2f01909442fd64160 1709 
check-all-the-things_2016.12.25.dsc
 c33aec9d929cf33033025e32c7492196ff3991264aef10e30589b8c6521808de 30196 
check-all-the-things_2016.12.25.tar.xz
Files:
 b81aac95e77463ee610677f0b040a853 1709 devel optional 
check-all-the-things_2016.12.25.dsc
 c913aeb77f7db6fa1f0b1fcba421ba9e 30196 devel optional 
check-all-the-things_2016.12.25.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlhfDYAACgkQMRa6Xp/6
aaPjNw/+MLUvlxyMd7MqIoZISV9j0y4/DnLhB6PVAtg9+d0C68C6rd72PXN4Jj+y
Zu/1vuzGrnznsqbyYS5nFMqQZ6Dqzg+kgZURZQMJXMkGGDC4zws01+wETSnS/KiR
9YwTtHJ62KWiQperT1J92np5xm5wnhSag/Vp0VI+RUa5c1T+XM6lImo/vN6/PGGB
LVlZS2rLGmClCpO5VsJ0WxSeviLuI2U50DOuJnHofzpeJT1aey2IdgI7ipLEYaId
EX5Fc5AhA3wi1F5WgBYtNp50VdGd8/CoGm5tieoCFBe3+2y/wpXAsSg9JK9+JdAK
oBsi6RIXF/ZZMF+T/sV7EyQAgIXEID3RgGg04HcmxcEQx42IjrHg0WKn8jMF3+F8
GOI/L0VP6XmdmZxEafsYejYVDEouvVfTaACDfG235qrFcVth/NyqcQ8v0KOR4Mq8
Y5R8ODrci0puzg57d2+aSR+D/TR7gpWlgAE2V8FO7AJu1lquFzGd3N//b0KInd/+
emA1lSCriEMuh4vvsvCy5Y+KGQ6rUvz/gNxHqSo2xuWXr9Hm4gC8nUcKoUJh+PBq
0H2yWrXtPvPrzrEnkgwswAs2PsgNEny3vBY6pvwOB8rCz+THXBCh0IVCCw1IRP15
OztCKHg7Ce5cRbvum5W4sSxhNRsz/PICudPALE2HgtSt7d491tw=
=dtb8
-END PGP SIGNATURE-

Re: Help with watch file

[Paul Wise]

On Thu, Dec 22, 2016 at 5:33 AM, Ghislain Vaillant wrote:

> I am trying to write a watch file suitable for fetching tarballs from a
> *link* published on a GitHub release page [1]. It seems this link
> points to a different location on Amazon S3 [2].

For the arrayfire-full tarballs:

version=3
https://github.com/arrayfire/arrayfire/releases \
.*/arrayfire-full-@ANY_VERSION@@ARCHIVE_EXT@

For the tag tarballs:

https://wiki.debian.org/debian/watch#GitHub

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted autorevision 1.19-1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 21 Dec 2016 08:32:37 +0800
Source: autorevision
Binary: autorevision
Architecture: source
Version: 1.19-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 autorevision - extracts revision metadata from your VCS repository
Changes:
 autorevision (1.19-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 2fb01010b09c84198427c716ebdc06a9975c7fab 2047 autorevision_1.19-1.dsc
 eb0d02f773bb5f8a594b422dfdc7a3962771e9e8 19945 autorevision_1.19.orig.tar.gz
 f0930d001d342048a6f32d06e35afc0b3e1bae5c 1535 autorevision_1.19.orig.tar.gz.asc
 ca45e03d4fb05502a6298e746f746eed530dc611 37500 
autorevision_1.19-1.debian.tar.xz
Checksums-Sha256:
 a8944d5623da0d384f939d82cc8cb1b184b9a59ddac2534c1128055c7334da5c 2047 
autorevision_1.19-1.dsc
 61fa3f3ea75d095081369f59fa01f05b9cffe52a3650a1d449cdc28386bec279 19945 
autorevision_1.19.orig.tar.gz
 d0894bc03fcbe4069a196aacc6b328143fbac1df56d755a44fbeae9a8b96de55 1535 
autorevision_1.19.orig.tar.gz.asc
 9f7f66b0d8b86dc95e1514ca2d4cf6fb05f36be1ddb0fdf35bec68a3913ccb32 37500 
autorevision_1.19-1.debian.tar.xz
Files:
 da34f1ce4ed6960fbf3d47e82ae61913 2047 devel optional autorevision_1.19-1.dsc
 7208ecfdeee133ab4740fb736d47d653 19945 devel optional 
autorevision_1.19.orig.tar.gz
 be68847eb325a2a7f572356e77faeda5 1535 devel optional 
autorevision_1.19.orig.tar.gz.asc
 205769e642d9c4e03b39d9c0fd19c1b3 37500 devel optional 
autorevision_1.19-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlhZzb0ACgkQMRa6Xp/6
aaNP9w/6A4gOV/LscqcJh5Sz8W5pR9E4ZBmCQbibwlqej+2iNNuyo25Yf2FfpxBe
r9XaIftYj3RDVsstVplLDY8N4TRpGgccd483His4qg/x4WxEX6IN7C5K+NUOoybj
ulfwB59nLUPCl3Ek1Twqq2h+GmPkVwDZg9koZpG22vw1pj7Yuom9IUIhHb751Fnh
9tn+Rp76Oys2vx2yyTlPwNLG4nZrxUuQoYWnDu06cUP/vT6IvsD2H/6+MvzgHNnQ
uYpkX7N73g4btASAoTC8GolfIOuozAAsq/SR4Ufi/EW6lJgJ/qY8dByNn8KF+53F
aUFTkd1mwjxrtVI3Ax25RgpvmHJ4+Un8AlvRXHsc/v+rbe3M2wEFUlp9jpo0Idv6
8zPzAp20dNZVdiqBERhBae4nkzIAWXB/T+wN7WoAWyqt5uGx8+/2NWig8FcQ7NCE
JyFXBez574MYCp3yG29PoHY7aM9US7bfClgO72pjD1GE8bKenjfP4Zrmx52Vlt48
fZEgodorZmJl4AZVjCvYKkdPvM5hKWGwuHxWEahvPKBeJNAZx+ZqyOsFQ2vrjJkD
wifaiDXhIl3kwPZs6026LHfhgRbQ/S/7itGOGQBPSedj8kCDzcqbMfBabEbElQjR
QrVwGsnvugtWAELf+mMVIsl7dwCeFpNpItjF31iW4xcuxI6WE08=
=Y8We
-END PGP SIGNATURE-

Re: which JavaScript dependencies really need a separate package?

[Paul Wise]

On Mon, Dec 19, 2016 at 4:30 PM, Daniel Pocock wrote:

> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, into the Debian source package?  This may not be
> the "preferred form of modification", but it is not difficult to make
> modifications to it.

As well as what other folks mentioned in the thread, this is probably
unsupportable by the security team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

[Paul Wise]

On Sun, Dec 18, 2016 at 11:22 PM, Roger Shimizu wrote:

> Is there any way to simplify?

Remove the obsolete armel binaries where they occur and then mark the
packages as NFU on armel:

https://wiki.debian.org/ftpmaster_Removals
https://wiki.debian.org/PackagesArchSpecific

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted debian-installer-launcher 27 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 18 Dec 2016 08:36:48 +0800
Source: debian-installer-launcher
Binary: debian-installer-launcher
Architecture: source
Version: 27
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 debian-installer-launcher - Debian Installer desktop launcher
Changes:
 debian-installer-launcher (27) unstable; urgency=medium
 .
   [ Paul Wise ]
   * QA upload.
   * Drop codename from the desktop file
 .
   [ scootergrisen ]
   * Translate the desktop file to Danish
Checksums-Sha1:
 ea0c4c8a8edc2471144ea2086e24f77202f4c6e1 1655 debian-installer-launcher_27.dsc
 23a85dbc67799278c117cbe858f579738006e3b6 43544 
debian-installer-launcher_27.tar.xz
Checksums-Sha256:
 3629af30e2463b4d3791a169bc78e0fe7b6c0be7353fb1d91bdc7027f20b6a48 1655 
debian-installer-launcher_27.dsc
 3ff18805c757a156423ce0a9095bf27eda5a645ec4e3c52d534e7ef66d8414cf 43544 
debian-installer-launcher_27.tar.xz
Files:
 80e2272082d324fdb5e2fe1ff76c164e 1655 utils optional 
debian-installer-launcher_27.dsc
 ebac9fd23e6494245a589e34fb7ede34 43544 utils optional 
debian-installer-launcher_27.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlhV3vsACgkQMRa6Xp/6
aaPK8w/+PsMOeg9wirkHqEfCo5uHngP3L18ir3ZTzQLAGshk0BNZy2WpaFBLbHoM
hLTvY6yeF6RBp7nAXnT7Ec+FeUGw6c1bY8wgdWkMb9yggcwTw6joSG8jhV6Yvo3N
mpyCTNSwR6oz1iV7uWNP7+Fj0sAsUjOYugsc2AvE+2RF2Kcme5w+wPUvRTMDKP1c
x+Ii4WUO18HD8lCm710zRsgxwmjr9tfGoX6JcJIRN0hEhIyV35DcuqkN0FGt6Y8D
sP5ImIf7Seln1pLPFTgvO1jyS9x5ziYcFePXTtZ9T6nCCbhXmvRR/iCxobBRCqqY
Fgi60wfl/17XymGZy1t6cnPjBbBlFC5D+04QDxw8l0H+E3mccatCbiyQdvt+PFqU
YjDFnue2IHL3KCD7rs1vdGXZ0z1/yNLv3elgI0BugbMqq/f21NC9kt+OYxEP/pR1
lofSgJMB21VSxX8Eb1yYL3lmDn7e55kbqt3qJTrqBthE775QFEWuFYC86axPrv1V
AOsCxuoaJTrvGCN6czYNMNoOXovcL3Mxr2HV6H222EZeaNcHRXGt0hbadVNuYclO
4p2fjyrD1TE4RlPJTAErdpi1vM99z99UV9CFzmiHc4ynd3OWUhoKzBEY7J+omEJm
v+iygxR6uYkWMhjwrYG/AbHpIBZHI9Kx2lILc0CFBEis9Za09M8=
=RRos
-END PGP SIGNATURE-

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

[Paul Wise]

On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:

> Yes, but that still says:

Ack.

> I think a proper procedure should involve a script that:
> 
> - is packaged in Debian;

Ack.

> - checks whether the hardware it's running on has all the hardware
>   requirements for the new architecture

apt show arch-test

> - is properly tested to work in (almost) all situations;

jenkins.d.n would be the place to put full-system cross-grading tests.
piuparts would be the place to put per-package cross-grading tests.

> - is a properly supported way to move from one ABI to another.

What do you mean by "properly supported"?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Auto-detecting -dev package dependences from pkg-config

[Paul Wise]

On Thu, Dec 15, 2016 at 8:43 PM, Guillem Jover wrote:

> There's also . I'd be happy to
> include such tool in dpkg itself. I think this is one of the current
> limitations we have in dpkg-dev compared to say rpm, which has many
> build-time dependency generators.

AppStream/DEP-11 was invented so Debian could catch up with rpm in this regard.

https://wiki.debian.org/DEP-11
https://wiki.debian.org/AppStream

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

[Paul Wise]

On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:

> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to armhf ones, without
> requiring a reinstall.

There is a script for that here:

https://wiki.debian.org/CrossGrading

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Re: Does or will Debian support NVDIMM?

[Paul Wise]

On Wed, Dec 14, 2016 at 11:57 AM, Qi Zhang wrote:

> Can I understand it as once Debian has package ndctl, NVDIMM will be fully
> supported?

It sounds like it, but probably someone who owns NVDIMM hardware will
need to test everything works.

> BTW, do you know when bug #829257 will be resolved? Which Debian release can
> I expect that will contain this package?

Bug has "RFP" in the title, which means "Request For Package", which
means that no-one is working on packaging it and that it is requested
that someone package it. If you would like to package ndctl, please
read this page for info on how to get involved:

http://mentors.debian.net/intro-maintainers

The steps approximately:

Retitle bug #829257 from, RFP to ITP and set yourself to the owner of it.

Make a package of ndctl.

Upload the package to mentors.d.n

File a request for sponsor (RFS) bug report.

Wait for someone to sponsor the package.

Wait for the package to be approved.

If you can do these steps before December 25th there is a chance it
will be in Debian stretch, otherwise it will wait for Debian buster.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Release impact of introducing a new archive section?

[Paul Wise]

On Mon, Dec 12, 2016 at 5:22 AM, Josh Triplett wrote:

> If we can get every package to handle this entirely at runtime, then
> ideally I'd suggest archive metadata downloaded by apt.  That would have
> the advantage of automatically handling new sections, including for
> third-party archives.  Packaging it doesn't have that advantage, though
> it also seems logistically simpler.

A file in the archive with support code in apt would be much better,
especially since it could include translations too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Hello: https://manpages.debian.org/man/1/uscan

[Paul Wise]

You can read about the plans for manpages here:

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

The debmans software renders manual pages to proper HTML that looked
reasonable to me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

[Paul Wise]

On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:

> Also, dedicated tiny flash partitions for the kernel and initrd.  I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devices seem to have.

Is it possible to put a bootloader like u-boot in the flash partitions
and have it load the Linux kernel and initrd from elsewhere?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Test instance of our infrastructure

[Paul Wise]

On Thu, Dec 8, 2016 at 10:24 PM, Javier Fernandez-Sanguino wrote:

> ... and there are no real requirements to
> test the current setup with new Debian releases.

You may want to subscribe to debian-services-admin, where DSA have
requested testing of services against Debian stretch:

https://lists.debian.org/msgid-search/1477278955.2136.1.ca...@debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Test instance of our infrastructure

[Paul Wise]

On Mon, Nov 28, 2016 at 8:04 PM, Ian Jackson wrote:

> Should we not have public test instances of all these things ?

If this will increase the bus factor of Debian services, that would be great.
If this will just be a time sink for the people involved, that would
be less great.
On balance, it sounds like the vagrant suggestion is the best trade-off here.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: debian-keyring not updated?

[Paul Wise]

On Sun, Dec 4, 2016 at 2:09 AM, Pirate Praveen wrote:

> Previous uploads were more frequent so I wondered if there was an issue.

Probably best to talk to keyring maint than debian-devel.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Paul Wise]

On Thu, Dec 1, 2016 at 5:34 AM, Christian Seiler wrote:

> Ah, and I ran my strace earlier with -e open,access, but after
> rechecking it, it does in fact check for the file's existence
> via stat(). I should remember to use -e open,access,stat when
> checking for file access with strace. [1]
...
> [1] Probably should add openat,fstatat,faccessat to the list
> as well.

I tend to use -e trace=files to avoid having to list lots of things.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: about build flavours

[Paul Wise]

On Wed, 2016-11-30 at 11:11 +0100, Arturo Borrero Gonzalez wrote:

> I don't think hyperscan currently is able to detect SSE3 support at runtime.

Sounds like a bug.

> Do you think that the warning at install-time is not enough?

Sounds like a reasonable workaround for the bug.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: about build flavours

[Paul Wise]

On Wed, Nov 30, 2016 at 6:01 PM, Sascha Steinbiss wrote:

> Yes, the libhyperscan package alerts the user at pre-install time if
> SSE3 is not supported on the target system. That's one of the reasons
> why I think there should still be a version of suricata that works
> without Hyperscan.

Sounds like they are doing it wrong. The detection should happen at
runtime not pre-install time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: about build flavours

[Paul Wise]

On Tue, Nov 29, 2016 at 8:35 PM, Arturo Borrero Gonzalez wrote:

> we are trying to create a build flavour for the suricata package [0],
> which we would like to link to hyperscan, which uses SSSE3.

I hope it detects the presence of SSE3 at runtime.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Certbot in Debian Stretch

[Paul Wise]

On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote:

> currently working with an ACME backwards compatibilty window of 6-12 months,
> but probably not longer than that.

I note that letsencrypt 0.4.1-1 (before the rename to certbot) is
available in Ubuntu xenial, which is scheduled for 5 years of support,
terminating in 2021.

https://people.canonical.com/~ubuntu-archive/madison.cgi?package=letsencrypt+certbot
https://wiki.ubuntu.com/Releases

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Paul Wise]

On Wed, Nov 23, 2016 at 5:24 PM, Simon McVittie wrote:

> (I'm not entirely sure why we consider hardening packaged code to be so
> much more important than hardening the locally-built code compiled by
> our users, which changed compiler defaults like those in Ubuntu
> would also give us.)

IIRC, the Debian gcc maintainer (also the Ubuntu gcc maintainer)
vetoed enabling hardening in the Debian gcc package. Not sure why that
was fine for Ubuntu but not Debian though.

Personally I would like to see GCC upstream enabling the hardening
flags by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted autorevision 1.18-1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 23 Nov 2016 10:23:57 +0800
Source: autorevision
Binary: autorevision
Architecture: source
Version: 1.18-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 autorevision - extracts revision metadata from your VCS repository
Changes:
 autorevision (1.18-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 c8109a4ec5fd65fcf21d84a538bd4f8b8010db66 1788 autorevision_1.18-1.dsc
 20d2358e94b7e964e983c3c137f668bd4853a695 19851 autorevision_1.18.orig.tar.gz
 2ce8a3ef41b5d0881dba52183960b0e82954cbe1 37492 
autorevision_1.18-1.debian.tar.xz
Checksums-Sha256:
 779bc7e8de9322481f1ebb35901ddc225b8356fdde197ed15691ac7d9e6c474b 1788 
autorevision_1.18-1.dsc
 1f78dd8e9671fa00d96d2d4479235950d8d8637f59bc38b1b622638cf0225e87 19851 
autorevision_1.18.orig.tar.gz
 1f4ced5ddbcdb9d7e1efde43220c6385ffb037099bf3eec1afe8461b6a3e3488 37492 
autorevision_1.18-1.debian.tar.xz
Files:
 3f42d4c963528aad0fd14ce9063baf97 1788 devel optional autorevision_1.18-1.dsc
 a26464c57521297b7b07602d84660340 19851 devel optional 
autorevision_1.18.orig.tar.gz
 ab72077593f4925bf53e4d64459f1eb8 37492 devel optional 
autorevision_1.18-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlg0/d8ACgkQMRa6Xp/6
aaPz0hAAh309eQ8y5RH4kaDkV0z/LS/5zMkmeYYgUoPxfcADAs5EFxL46iVI25K4
ffphUsNlHT/OhiYaLjN8XiBi3u8THWZh3eacvAYiN8mfYdrHy9qIn50c1dym5DTt
gjgD+QdrDxPMzvnBpyhGcGnLU/APWHtdvOeLeNh5LWVYQyE6APU4E2uXrb7worjB
VITBCY8XanXpKKCIxAsOt2OhdLRgxJLK5BjpxqGqaBhcaty4jw6nKqpcTRX3Xp8H
U0CE1b0RxujA71fEFbtm12kYNlXuJiImhftqrP4TaIulNbfrGr+Phl7DMKn/qQTt
BMskNdPvp62z+LhBuPDvAksOmhR8m/c9croesDCpNkaYHoTgKUn4NBL2vbEHPJ1u
srw7s+0/yfurIUs8GxG3T/H9QUYINfGh/rR6p0j7R3Mkyn6CYsC5yHwBqV8QeerA
Asl1WNUzEcEKufsm8f+KUEruK7VYcf2ruGs/aLBwQ+pyiXPH6/mr+u/yIjvT3kss
RRu7w+1bHiR49Y9WkEWEShjnwExZme3qrKPZSJgaLzC3Gf4ouo/Qgp712iklUEQ5
KHU60wtFxWVK4RU+7+InTBvL/l8nxeA3dKKP73MKtHCcbXD/5MIJo8U5r31q6mam
QJDSF1k0FD23WQpqIsIPug7nm7Y9QUSu20h7BIC/f2X1KKJT8FA=
=2cUO
-END PGP SIGNATURE-

Re: Let's stop using CVS for debian.org website

[Paul Wise]

On Sun, Nov 20, 2016 at 10:45 AM, Boyuan Yang wrote:

> Needless to say there are various tools that can help convert a CVS repo into
> a SVN repo or Git repo and they handle this job properly.

This idea comes up every few years but we haven't yet found someone
with the time, skills and motivation to implement it. Some historical
documents and discussions are in these links:

https://lists.debian.org/20130516005223.gv26...@rzlab.ucr.edu
https://wiki.debian.org/WebsiteVCSEvaluation
https://wiki.debian.org/WebsiteSVNTransition

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#805116: ITP: wifi-switcher

[Paul Wise]

On Sat, Nov 19, 2016 at 10:18 AM, Oleg SHALAEV wrote:

> but I can not do it because I am not a Debian Developer.
> Is it possible to submit the program to a Debian Developer,
> or I have to register as a  a Debian Developer myself?

Please read this page:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted autorevision 1.17-1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 19 Nov 2016 08:32:27 +0800
Source: autorevision
Binary: autorevision
Architecture: source
Version: 1.17-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 autorevision - extracts revision metadata from your VCS repository
Changes:
 autorevision (1.17-1) unstable; urgency=medium
 .
   * New upstream release
   * Mark as multi-arch foreign, thanks to the multiarch hinter
Checksums-Sha1:
 5e3bae00fe8da5962b22a2abdedbd7b05cfedd11 1788 autorevision_1.17-1.dsc
 6c893682b7991824c4e060657e77d7506d22582e 19770 autorevision_1.17.orig.tar.gz
 1e6dfa9c324b39989e3c2b4c8202ed9eb3696636 37464 
autorevision_1.17-1.debian.tar.xz
Checksums-Sha256:
 fd7248d2178a4746b019c19d855937242d3174949c33254359e12d883578e254 1788 
autorevision_1.17-1.dsc
 f7156eb2b58dafa72ddce6a9c41e81d9f447f41b60e2180299775e899ffc3137 19770 
autorevision_1.17.orig.tar.gz
 333a936a346c2fe58982f3055db1db690c4a6c6516e583617a0d02f0bc3d9a7b 37464 
autorevision_1.17-1.debian.tar.xz
Files:
 3450489865f6fc7f9d74d249e4ced10b 1788 devel optional autorevision_1.17-1.dsc
 96aaa97e91c7bfefe07fb26136b23109 19770 devel optional 
autorevision_1.17.orig.tar.gz
 fbef20016723e3b0fec10108cb758964 37464 devel optional 
autorevision_1.17-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlgvnakACgkQMRa6Xp/6
aaPysA/+NhzE6voytCA0GgQL4oAV8gRN2HeneQzOlXlvMlYPYveD4nPeam76ELt9
TWhLpWFjuc4vVdPoUjQE2L4QyWyvyM5iH79P18MkPIQqOi5kyJFPNfztWYTlAB/c
U2FO5Wbqzk92IefWl//i/galAtm/Pru8mb2zGN+nISzslIVpugRsieTOI9yB9ICU
/VPFh5VGcmbHEZ7Gz6sUiq0hIc/tkNjbw3nRhuDpCTh7ZcOdUiQ0UIkZa0RlUIa2
F9guJAVjCcRGWw1dBJgdfsBAhrJfRMxRlAARcHBCjBZoH7SOYKPtd3XTEAHPwuoB
Y3otZamuX31MZf46jX2uUu0ph3uhZf9EVJOjxxnhU7/BYvtpMYuiD/LxZLLPqpR2
Dj1wpww78U8gkZc/5pFOMcot4jktTyiByhFGcBAgJ6mRijKYktxOgY+9sHKEHY/Y
VnlUbEnH/Gh4PMLD3ZftSmk4UBk9Ghjkcoj1mQoS4KQyK2TgjJu7YYgwl/mf8e96
zglUDF73hSYNdKiGC4Cv3GZdjAgG90fu/JHTCKoSliJfYbCIiVGKFZsfblRyc9r4
Nb1ACqLLzENJjuKJRukrJay6YP31W08OwnfZyYc3f4T/b8/9BywLXYLLstAwYOv7
UiFTRYB+fxFlWoIWXORvnkV5Ha1TBuNO7BEhwDy4nkfzHTiq+vc=
=7xYY
-END PGP SIGNATURE-

Re: Building architecture:all packages

[Paul Wise]

On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:

> implies "src:foo" must build on *all* architectures

In general, Debian does not define the build architecture for any
package, no matter what the Architecture of the package is.

In practice, arch:all packages must build on either amd64 (arch:all
buildds run that), or an architecture developers are able to build the
package from.

In practice, arch:any packages must build on one of the Debian/ports
arches (for the arch:any buildds), or on an architecture developers
are able to cross-build the package from.

Generally, we much prefer to have builds happen on the buildds than on
developer machines though.

We currently do not have any cross-building buildds AFAIK, although
there is the rebootstrap stuff.

https://wiki.debian.org/HelmutGrohne/rebootstrap

Obviously, it would be great if we could build arch:all packages on
any arch, native build on any arch and cross-build from any arch to
any other arch, but the world isn't an ideal place and neither is
Debian.

IIRC there are mechanisms on the buildds to deal with arch:any builds
that don't work on some architectures.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Building architecture:all packages

[Paul Wise]

On Sat, Nov 12, 2016 at 6:32 AM, Christoph Biedl wrote:

> How would this affect your assessment of the situation?

The details matter, without them I don't think any assessment is useful.

> In my feeling, revealing the packages' names would give the story some kind of
> blaming. That's not my intention.

I don't think mentioning package names is blaming, but I understand
not everyone takes it that way. When mentioning the details you could
be more explicit that your intention is not to blame anyone.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Building architecture:all packages

[Paul Wise]

On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:

> Other suggestions?

Include information about which packages/issues you are talking about.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: More 5 november in the release schedule

[Paul Wise]

On Wed, 2016-11-09 at 22:55 +0200, Adrian Bunk wrote:

> Is anyone tracking what packages are installed from backports on
> Debian machines, and the CVEs in them?

backports is unsupported by the security team, so DSA & backports users
rely on service maintainers and backporters to do the right thing.

> Using backports without doing that would be irresponsible.

Agreed, but that is the best we have right now.

> Package removals from unstable are also a potential problem, example:

Agreed.

> The maintainer wanted to remove this package from *unstable*.

Thanks for pointing this out.

> FreeRADIUS is popular enough that people noticed before an RM: bug was 
> filed, and new maintainers were found immediately.

Looks like that wasn't enough since it didn't reach unstable yet.

> Other packages are not that popular.

Even the unpopular packages have users or potential users, we need to
develop better chains of communication with those users & communities.

> If any packages needed on these Debian machines have been removed from 
> unstable, they are not on your list.

Correct:

https://bugs.debian.org/838363
  
> This is the reason why a ITP/RM revolving door is creating huge 
> headaches for users.

Agreed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: unattended-upgrades by default?

[Paul Wise]

On Wed, 2016-11-09 at 23:06 +0200, Adrian Bunk wrote:

> Any "solution" for the reboot problem that assumes that there is a
> user who regularly logs into the machine misses the problem.

Any solution that is the same for every device is completely wrong.

Cloud images should probably auto-reboot ASAP since they will mostly be
unattended. User desktops, laptops, phones will often have a logged-in
user who can be asked to reboot. Home routers and servers with a low
period in user activity should be auto-rebooted during the period of
low user activity. Any servers managed by config management or within
an enterprise should never be auto-rebooted and probably should not
notify anyone other than the monitoring system, via reboot-required.

So there probably needs to be a debconf prompt for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: More 5 november in the release schedule

[Paul Wise]

On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:

> Right. We want auto-removals to be useful for the release process, so that we
> don't end up with a thousand of RC bugs in testing when we freeze, most of 
> them
> on packages that nobody cares about, not even their maintainers.
>
> However, we don't want auto-removals to drop your package behind your back. If
> that happens, that's a bad thing and you should let us know so we can fix
> things. auto-removals should notify the maintainer in advance, and only act
> after a reasonable period of time.
>
> The "packages can't re-enter testing during the freeze" is an incentive so 
> that
> maintainers don't wait to fix a package after a few months, and so that we 
> don't
> have to go and remove them manually. This way you know that something is going
> to happen if you don't act, yet you should have a reasonable amount of time to
> do something. Hopefully this helps have a short(er) freeze, which is good for
> everyone.

FYI, it looks like at least buildd stuff (IIRC that uses dose3),
rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
on jessie until the affected packages reach stretch-backports as a
result of the autoremovals stuff:

https://lists.debian.org/debian-services-admin/2016/10/msg2.html

I guess alioth will remain on wheezy too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: More 5 november in the release schedule

[Paul Wise]

On Tue, Nov 8, 2016 at 3:19 PM, Brian May wrote:

> The problem is if the maintainer is not responding to RC bug reports,
> and you don't realize a package you depend on has RC bugs. This happened
> several times to me during the last freeze.

Assuming you have your package and its dependencies and
build-dependencies installed, running how-can-i-help will show you the
relevant RC bugs and removals.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul Wise]

On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote:

> Forced reboot on upgrade is damage.  Let's learn from errors of others.

needrestart has a mechanism (needrestart-session) to hook into user
sessions, perhaps that could be extended to request users reboot for
security updates.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul Wise]

On Sat, Nov 5, 2016 at 1:25 PM, Michael Vogt wrote:

> Thanks for this reminder Paul! #828215 is fixed in git and will be
> part of the next upload (which should happy early next week).

Thanks! If you have time, a fix for jessie/wheezy would be appreciated too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#843185: ITP: aravis -- A vision library for genicam based cameras

[Paul Wise]

On Sat, Nov 5, 2016 at 1:13 AM, Chiara Marmo  wrote:

>   Description : a vision library for genicam based cameras

It would be great if you could add some metadata about which hardware
is supported. By doing so, you will enable users to discover your
package when they plug in a new device supported by your package.
Users can use the isenkram package to discover packages related to
their hardware. If your package contains udev rules, it probably needs
some AppStream metadata.

https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul Wise]

On Fri, Nov 4, 2016 at 2:47 AM, Steve McIntyre wrote:

>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap.

That should be fixed in d-i IMO.

> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

I think that would be acceptable once the fix for #828215 is uploaded.
Until then, enabling unattended-upgrades is a minor but guaranteed
data loss: upgraded automatically installed packages are set to
manually installed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted apt-move 4.2.27-5 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 02 Nov 2016 13:11:28 +0800
Source: apt-move
Binary: apt-move
Architecture: source
Version: 4.2.27-5
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 apt-move   - maintain Debian packages in a package pool
Changes:
 apt-move (4.2.27-5) unstable; urgency=medium
 .
   * QA upload.
   * Drop the header for Contents files. (See: #841997, #676642, LP#1638219)
Checksums-Sha1:
 a06630d2df6ea6cf58bc2b5c54e653575ea68fde 1724 apt-move_4.2.27-5.dsc
 d6c528641f5e7491994301a6f1a1c91220343006 10700 apt-move_4.2.27-5.debian.tar.xz
Checksums-Sha256:
 616393c1e8091384aef62b7ad7b176031f8dfb02a8a7aa0d8ec91289c11e886e 1724 
apt-move_4.2.27-5.dsc
 735c16a8e7f9bae6b3ee9424c06743ed528e68ee8e11184b2f4ab2f4d6c67d46 10700 
apt-move_4.2.27-5.debian.tar.xz
Files:
 331ab39ebf71434f53f603f17b73faa8 1724 admin optional apt-move_4.2.27-5.dsc
 b5aa6a72d96c958bb9569512ecf48812 10700 admin optional 
apt-move_4.2.27-5.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYGXWWAAoJEDEWul6f+mmjoYoP/jhiBr4vLUhMCiKLTWmVXntA
XemsbVaDpJKyCaLIOLweupf8Ekc9K1quwjoxqAz21SNnyG+pju8DAvCreLpE9k27
PABfTGnGM24df8Q/NndAlzPgeYpsbFjZKoe06i/guYFYbvdzYL0NTYEvDWZAcTqY
cMs5UbDcuHhdm8MrLzAxPcA5kj+5PYRCPgxEJ9XowF12g1REQKlXbJRBoopsFWRb
SoPTYRv2zoRspeIi3GSbMf1K1lUk4Agkl++rSQ6cWtcCrMNew9jXzMo827DAYl3H
1txOQQCie0626af0Ub5TbgyoIqJI57UpuZLAIkLLkNhaTTA4Nr6ZMQZSvXyYsa6q
2KQKWCCQrAjFJCrJfjrg071uqlKM4gY2x/fTgIZfN3amlRrnWVIgm0o36Un41ivv
FXx7JX9kXxu62odjoWqvxcl4EifuFuvrA0pu3ML3yPu085PEOdhahou8HrEORHLo
LSFgwz8MfuW3Qdar8OpRhfMyIc0lWH5XHLBKuwixduAcu0EW4wMBVMGkdGsUuvYz
V//LzW+NuT1vJcYPuPvpNLbl6gIgC2Ckmnx7Dugryxm7apb4OWV+UcMvLRIcPbPe
Om9Z+ndTzaC4TTrMJ4DjDJLxMn3Ol/EarDORTnanlUqWeQDNFKbvluV9SpA8z26a
mLda3WGuwZOcBrNB/xHv
=XqDK
-END PGP SIGNATURE-

Re: Lots and lots of tiny node.js packages

[Paul Wise]

On Wed, Nov 2, 2016 at 9:04 AM, Russ Allbery wrote:

> If upstream themselves aggregates, then this works well.  (See, for
> instance, TeX Live, which is basically an upstream aggregation of
> independently-released packages.)  That gets its own version number and
> its own unique existence and someone else is doing integration and release
> management upstream of us and we can reuse some of their work.
>
> But if we were going to do that, I think we would almost have to run a
> separate TeX-Live-style project as an artificial upstream for Debian
> packaging and do all the work that the TeX Live folks do to assemble that
> distribution.  And that's even *more* work than the Node packagers are
> already putting in, of somewhat dubious benefit (since it would only be to
> reduce package metadata).

Personally I think that even upstream aggregation on the scale of
XFree86 or TeX Live is annoying and I prefer the more fine-grained
packaging of Xorg, GNOME etc.

The web ecosystem is still changing rapidly, with WebAssembly coming
soon, so probably things are going to look very different for the
Debian buster development cycle.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Rebuilds with unexpected timestamps [and 1 more messages]

[Paul Wise]

On Mon, 2016-10-31 at 17:26 +0200, Adrian Bunk wrote:

> At that point the best solution would be an alternative source
> package format that is based on git.

That already exists (see the dpkg-source manual page), but IIRC isn't
allowed in the archive because the ftp-masters do not want to have to
analyse the whole history of a git repository for DFSG issues.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Rebuilds with unexpected timestamps

[Paul Wise]

On Mon, Oct 31, 2016 at 12:02 AM, Ian Jackson wrote:

> Could someone point me at some tools, or volunteer to help, or something ?

Check out the wiki page about this:

https://wiki.debian.org/qa.debian.org/ArchiveTesting

> I ask because have found a new way to break packages :-).

Whee!

> What do people think ?

You've found an interesting new class of weirdness in the archive.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#842349: ITP: node-glob-base -- Returns an object with the (non-glob) base path and the actual pattern

[Paul Wise]

On Sun, Oct 30, 2016 at 12:05 PM, Adam Borowski wrote:

> That database looks like something easy to check, and since most if not all
> Debian node.js packages use naming consistent with npm, it could be
> automated.  (Please tell me it already is.)

It is not automated. Every few months I find a bit of time to go
through the recent nodesecurity posts and file bugs or ping
maintainers but I doubt I'll be doing that again soon. Except for CVEs
from MITRE, all of the data collection for the Debian security tracker
is manual at this point (and a significant proportion is done by
carnil). In case anyone wants to help fix that, check out these
initial thoughts:

https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#842349: ITP: node-glob-base -- Returns an object with the (non-glob) base path and the actual pattern

[Paul Wise]

On Sat, Oct 29, 2016 at 12:00 AM, Russ Allbery wrote:

> such as patching Javascript for security vulnerabilities

FYI, the Debian security team does not support the NodeJS ecosystem.
We probably need more folks following Node security issues. Some of
those are listed here:

https://nodesecurity.io/advisories

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted apt-show-source 0.10+nmu5 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 24 Oct 2016 14:49:40 +0800
Source: apt-show-source
Binary: apt-show-source
Architecture: source
Version: 0.10+nmu5
Distribution: unstable
Urgency: medium
Maintainer: OHURA Makoto <oh...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 apt-show-source - Shows source-package information
Closes: 831917
Changes:
 apt-show-source (0.10+nmu5) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add patch by Santiago Vila to fix `debuild -A` (Closes: #831917)
Checksums-Sha1:
 caea1caa04da8e7e89e714a1765d701fdd843eee 1431 apt-show-source_0.10+nmu5.dsc
 bc3b52033713b7ad337b8598d0281afbfff41eb4 9504 apt-show-source_0.10+nmu5.tar.gz
Checksums-Sha256:
 2a68c68e0b9bbacf5e56fa4ce22a5293a969827d68c60386262e332d5e6d56ab 1431 
apt-show-source_0.10+nmu5.dsc
 587840e595abcc8ac519c3b5f04e66b32c6caf940bf15c17c8eee6a37a2113d0 9504 
apt-show-source_0.10+nmu5.tar.gz
Files:
 6b85cd022718313b96a4d9b3ea6cec7e 1431 admin optional 
apt-show-source_0.10+nmu5.dsc
 0a7b9881ba8bd65a26c64b0875e66b01 9504 admin optional 
apt-show-source_0.10+nmu5.tar.gz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYDbDjAAoJEDEWul6f+mmjpHMQAKsJ4pLzmminOv3P8Xc2mwff
h8UTXIbAa5VF+A+mqVqAgMHYiiVGba2dLMAaz1KePmiNIHMs9uO1lJv+tlDxPFTG
pcOTaE3wACcbR6tYqw7gpa5rGvnv8kr9Q/2AUQ/whqCgU8socJrjsBlZNj+Nriqx
xqmZ/k4NgyVhMYtuXmyuRokzcwmgXxZXq/MNN8+3Yhcm6E1ZCQS6jdGj0et5Mki6
gO5vjqY2xajvNa0qDoEPLBarl0Ehm/lYBItKFqfw/4TqxUZRNPPJ6KgB2ivjlg6N
3vqVXkKTwhnAffRGExoZ2XC4p9VxUYZnQkzUsB+SnK3eSMkYLNHtowdafiAE5LBU
Nf8AOmDYhunx2ZvM5oyNR5pjDL1oNRTYlVQjxys7UGWnfa4FqgDm6w1qlf6y4kAO
MvdH+mRGOwC5kyOx2BM4Cbn6sa4ehi1GGghLQPy/psApk87+nSV+tP1zVcb0LYyx
GFMz/341Jw7ddsolTe44AzDo2qgQnjioGg4VRbNi96q7pZM4wxCjO7+gJcCSa2OG
mjorUPIuVbzma3NhCJXMC1HOULiDUVpeMdOg3txyhpIk7u42CcQM+UHU74o31xo/
TILY1O9vgO53FIctNgWh9ffMcvKuppFosmm1CyHE53TM4BBMAMq+NsKLylHO/mjc
ZXAwqgLr1LokDYdE5igt
=xqYH
-END PGP SIGNATURE-

Re: Planned NMU of w3-recs would use much archive disk space

[Paul Wise]

On Thu, Oct 27, 2016 at 8:16 AM, Thaddeus H. Black wrote:

> I am moving [1] to NMU a big non-free package, w3-recs [2][3],
> last updated five years ago.  During the last five years,
> upstream has grown, both in volume [4] and in scope [5], for
> legitimate reasons.  The new *.orig.tar.gz or *.orig.tar.xz
> would be about 200 GiB in size, six times what it is now.

I think you mean 200 MiB? If so, that is not that big in the scheme of
things IMO.

> Advice?

Go ahead if you meant 200 MiB.

I'd suggest a package 'salvage', add yourself to the Uploaders. If the
maintainer never surfaces, you can then remove them from Maintainer.

You may want to also talk to the package sponsor and the MIA team:

https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#mia-qa

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: "Dear Customer" spam in the BTS

[Paul Wise]

On Wed, Oct 26, 2016 at 7:43 PM, Tomas Pospisek wrote:

> Has anyone tried to do such a thing yet (methodically clean the bug
> archive of spam)? Where and how could I start such an effort? How would
> I get read/write access to the BTS archive?

The BTS admins do that regularly, based on people clicking the report
spam links at the bottom of the bug reports. I guess you would need to
become a BTS admin to contribute to that effort.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted debdry 0.2.2-1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 25 Oct 2016 09:19:23 +0800
Source: debdry
Binary: debdry
Architecture: source
Version: 0.2.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 debdry - Semi-assisted automatic Debian packaging
Closes: 780254 805195
Changes:
 debdry (0.2.2-1) unstable; urgency=medium
 .
   * QA upload.
 .
   [ Antonio Terceiro ]
   * git-debdry-build: switch from `git-buildpackage` to `gbp buildpackage`
 .
   [ Paul Wise ]
   * Fix minor typo in the package description (Closes: #780254)
   * Use canonical links to anonscm.d.o repos
   * Add python3-apt to X-Debdry-Build-Depends (Closes: #805195)
   * Set Maintainer to orphaned (See: #813203)
   * Pass --git-ignore-new to gbp
Checksums-Sha1:
 6f16c74ffbd9d72a0097aca47c91d8cb540b960e 1872 debdry_0.2.2-1.dsc
 ffcdfd4d3c7511fb66903b222db35cf4cddeeb91 28248 debdry_0.2.2.orig.tar.gz
 bfc6621df4f52129f0d08edcd8c1b49fa85509ac 2796 debdry_0.2.2-1.debian.tar.xz
Checksums-Sha256:
 dd6c3e0cbbe9a44e212daa276cd3634a7c92336ca11b3c24c2c7fd56d18edaab 1872 
debdry_0.2.2-1.dsc
 c3c2343474f42e5db298bdb8d99c05113c1e8311bfaf016dd2f442571bdf2b26 28248 
debdry_0.2.2.orig.tar.gz
 4ec56dada8a2d3e9b4acaace7005faa9bac296087a8d72a86fa661ec7679a6b7 2796 
debdry_0.2.2-1.debian.tar.xz
Files:
 813fcd2cc087db4647eb4e608aa73aad 1872 devel optional debdry_0.2.2-1.dsc
 89dfb5f2fe643a4c153a539152443287 28248 devel optional debdry_0.2.2.orig.tar.gz
 8dafab015fd59a2108ac6ef776e18245 2796 devel optional 
debdry_0.2.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYDsdXAAoJEDEWul6f+mmj+F4QAImS6SBD9C5TEb53Pr7YwLzP
KsckdjhkIX4m/srvWOPPu4qwiCJzcw+oXevk+UDaCUn9Kn0MEHQ5cVtqlc6dTJov
ykfBKRxvqQgr/5nNjeceParZmx3j/dPXuK3DktxtZ7kWVyfomheXauLknT1z4EoK
c6WYu/0IXxf5vAdsnnLvF4T+SOpFU27vTkPYxZCZMVoFDIgCMFC9HrGpCowbUauh
GtvDU4T2573yudPu6gdvOmrZ7/taLCf66NG79JHsoSgVzeqoSyEmBKt0+xfAh/xS
OVrw/t2yDBdLiv5UESZhb8HZMD8K+zLqk/6hUuWnesUesiWFi6mgXKh0fiif9WPi
nGrngXGuIJqSm+Z2RpluMh1YBc4BSzCTO+g5IN5N2SV+wN21nu57WXIEBg8vGLkm
jkXPfFkBKoNbCMPNwZD0I1cuAIOq2MbdECvy+yAWw3uUj8kvhuGVAnI+vrxNZTIN
xsgnlnX1xS683vdu4kAFV3WxD9mYEjA9uf4r7uCNvyGrdigm/92Fw0MzJEL1II//
YUq4RiS2RbQ3TpR1qqWuizqkk9w2iWIOACTNl+V6gjCErSf2BUQWDVmXJJ/UkLBr
Xw827B/7siYvgI3oWBYBSvDLrRCyaJLT8f223BF3iDmPOtiUdCG7wQ2r0FrZicNZ
XATtDKoTjmx0c5GtsUWN
=WuU7
-END PGP SIGNATURE-

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Paul Wise]

On Tue, Oct 25, 2016 at 7:33 AM, Russ Allbery wrote:

> Tor is easier for us as a project, since we don't really have to do
> anything (assuming we just rely on existing exit nodes).

Debian has Tor onion service frontends to various Debian services,
including several Debian machines with archive mirrors, this is
implemented in an automated way using Puppet and onionbalance. So we
do not rely on Tor exit nodes, just relays and the onion service
system.

https://onion.debian.org/
https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/onion

> SSL is much harder for us as a project

For most debian.org services run by DSA, enabling SSL on a service is
one git commit away, thanks to Lets Encrypt.

Some things like snapshot are harder due to software or other issues.
For snapshot, varnish is the frontend and it doesn't support SSL.

All the debian.org mirrors except ftp.d.o are not actually run by DSA
and DSA occasionally need to change which domain points to which
mirror, so SSL for them is much more complicated.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: client-side signature checking of Debian archives

[Paul Wise]

On Mon, Oct 24, 2016 at 7:21 AM, Kristian Erik Hermansen wrote:

> The point is to improve privacy.

Better privacy than https can be had using Tor:

https://onion.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Paul Wise]

On Fri, Oct 21, 2016 at 2:35 PM, Ian Campbell wrote:

> I think there are also physical arm64 systems using EDK2/Tianocore as
> their firmware.

Unmodified upstream versions that you can re-flash? I got the
impression most UEFI firmware is based on EDK2/Tianocore, even on x86,
but it has proprietary modifications.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: NRSS has been deprecated [#696302]

[Paul Wise]

On Fri, Oct 21, 2016 at 1:34 PM, Adam Borowski wrote:

> we should have some way to query if anybody would object to a package's 
> removal?

We definitely need better ways to connect with package users, but it
might be hard to do that in a privacy preserving way. Perhaps
something similar to popcon, but in reverse could help there. A
web/onion service where users can download details of packages that
might need user attention, along with an opt-in client that
periodically downloads the current list and matches it against user
preferences and installed packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Paul Wise]

On Fri, Oct 21, 2016 at 4:20 AM, Tollef Fog Heen wrote:

> If there are machines with free firmware that also support secure boot,
> we can look at this.  So far, I don't believe there are any.

Tianocore (edk2 in Debian) supports virtual machines and also any
device that supports coreboot could chainload to Tianocore.

https://wiki.ubuntu.com/SecurityTeam/SecureBoot
https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: NRSS has been deprecated [#696302]

[Paul Wise]

On Fri, Oct 21, 2016 at 12:17 AM, Enrico Rossi wrote:

> I saw that the upstream devel of NRSS has deprecated it in favour of
> another software. This has been already reported in the #696302.

This is what the nrss upstream website says:

NRSS has been deprecated. Use Canto in the future. You will *not* be
automatically forwarded.

canto was in Debian but was removed:

https://bugs.debian.org/764758

Since then it was renamed to canto-ng and new versions were released:

http://codezen.org/canto-ng/

> I'm asking if shouldn't be the case to rise the level of that bug to RC?
> I don't mean the package shouldn't be in the next stable, also we are
> talking about a very small package indeed, but I think that bug is
> pertinent and should be dealt with before the next stable.

Looking at the popcon data, about 7 to 20 people use the Debian
package regularly.

There is no evidence in the BTS of any Debian users of the package,
but there is evidence of one Ubuntu user of the package a long time
ago. They even went to the trouble of providing a patch for the bug
that they found:

https://bugs.debian.org/515195
https://bugs.launchpad.net/ubuntu/+source/nrss/+bug/319994

The newsbeuter, olive and maybe rsstail packages contain possible
alternatives to nrss.

newsbeuter looks in good shape.

olive is also orphaned and the upstream website and git repo is gone.
A couple of folks were interested in adopting it but no-one responded
so they didn't do anything.

I expect most people reading RSS on the console with Debian now are
using newsbeuter/rss2email/feed2imap.

Probably olive and nrss can be removed from Debian in favour of newsbeuter.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Paul Wise]

On Wed, Oct 19, 2016 at 12:03 AM, Jakub Wilk wrote:

> it's only used as a fallback for nodejs < 4. Debian currently has 4.6.0.

Does this mean the ITP can be closed?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Paul Wise]

On Tue, Oct 18, 2016 at 7:36 PM, Ian Jackson wrote:

> I'm afraid I can't make sense of this.  You have posted it to
> debian-devel, but without any kind of sensible explanation of the
> context.

It was posted to bug #820036, which is tracking Debian support for
secure boot. Peter was advocating quite correctly that as well as
having our copy of shim (the first-stage bootloader on secure boot
systems) signed by Microsoft, we should also have a copy signed by a
Debian signing authority, so that users can theoretically choose to
distrust the Microsoft key. IIRC, unfortunately in practice that is
unlikely to be possible since various firmware blobs are only
Microsoft-signed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted apt-xapian-index 0.49 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 18 Oct 2016 11:15:35 +0800
Source: apt-xapian-index
Binary: apt-xapian-index
Architecture: source
Version: 0.49
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packa...@qa.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 apt-xapian-index - maintenance and search tools for a Xapian index of Debian 
package
Closes: 839982
Changes:
 apt-xapian-index (0.49) unstable; urgency=medium
 .
   * QA upload.
   * Wrap and sort Debian packaging data
   * Gracefully handle database format removals from Xapian (Closes: #839982)
   * Bump version to 0.49 in update-apt-xapian-index
Checksums-Sha1:
 5a49b460ddf0a22363dd268e5d1e245d2dc6eb55 1794 apt-xapian-index_0.49.dsc
 80b6e977f08905c9b05ff194ec4983e26bcf5fe1 55862 apt-xapian-index_0.49.tar.gz
Checksums-Sha256:
 07995a15a3548c10af32926ba1a13dc0a28e322193438460fbb7592f46980938 1794 
apt-xapian-index_0.49.dsc
 72c51cdd4828b88894b623aabfb246a0e9b9a43f83a8027b65a7ec23fe7bbba1 55862 
apt-xapian-index_0.49.tar.gz
Files:
 6dec4236992ed70b07412068de9acd4d 1794 admin optional apt-xapian-index_0.49.dsc
 93606a5df41626595024f696da3ffbdf 55862 admin optional 
apt-xapian-index_0.49.tar.gz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYBZSjAAoJEDEWul6f+mmja+UP/39P1wh36SHlqHM40l2c4O8Z
3unFAD7rTKKPo5WauO0o2z1lnFq5bPlg6T4xO3Lvu72f3+5y9kJ5P+ADfK3RL73p
rDd4WroqZSH+og9WaqSSsinUCmeKaESuqqU9CobgnodV4ZrR+w73U65EwbG22QTt
iX7ls8/2qK/VvIyaoqPuNl/xnOqGt+A55d8/on1ik++4ZZLmD7NXXrTv20PnWSeI
vLuk4a1BibqLXAeJmmpC1zQjoZh1uzAS2V/VbEGCKjgfw3JAv5LCWW2RuDEFEEia
fYPqw59dt1Lg5p1bahHJKaDYPhmgE9W2T8xCrZOM5y0kxNu1etVXEoLDaJUdu2ec
AfWThxG01S23J/2OscBkx6fTzwyHOZuAeOuop+9vnZ5mY+F3y7RlnkROFz63trRM
cjO4bhX31vcmybiiIal1s/iWHhp0dcJH/nhOCwC28ISmknc0j5aTTcmD1uxHTBvP
FknHX/zcl9Nayb2e4jUsNfyZsANwprEKxcfkrlK3FpATnXDXmSp0BJ1C21RXx1DQ
N2ZS4lwvQwnX5mVanp1U5ey+udN2FsRF4mYSbTY1U8uCIOP7i3Fc4l2CEliiQ40Q
OkK8ZeFmBaflRulsemvADO+1nT7tLukeBFPhqXDIs9PAi6TKwzHQuTWpgdwuLtiT
L/Kub1e3DIsWEI6/Q/NQ
=iZp4
-END PGP SIGNATURE-

Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty

[Paul Wise]

On Tue, Oct 18, 2016 at 4:21 AM, Josh Triplett wrote:

> These are distinct packages, with distinct version numbers, and packages
> will need to declare (potentially versioned) dependencies on them.

Has anyone involved in the node ecosystem tried to talk the respective
upstreams into creating a standard library that contains all these
basic functions?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: uscan download from sourceforge doesn't download what you expect!

[Paul Wise]

On Sun, Oct 16, 2016 at 2:49 AM, Dimitri John Ledkov wrote:

> Yes, this is known to me, but I did not report. The redirector /
> sourceforge make it hard to distinct identically named files in
> different subfolders unfortunately.

This was a bug in the redirector, I've added additional links
containing the full path to the files. I couldn't modify the existing
links because that would break all existing sf.net using watch files.
I added a direct link to the sourceforge-run redirector too, so these
should both work:

version=3
opts="uversionmangle=s/_/./g,dversionmangle=s/\+dfsg$//" \
http://sf.net/boost/ .*/[.\d]+/boost_([\d_]*)\.tar.bz2

version=3
opts="uversionmangle=s/_/./g,dversionmangle=s/\+dfsg$//" \
http://sf.net/boost/
https://downloads.sourceforge.net/.*/[.\d]+/boost_([\d_]*)\.tar.bz2

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: When should we https our mirrors?

[Paul Wise]

On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote:

> Doing this for the per-country mirrors means that repointing mirrors
> becomes a lot harder than it currently is, and this is something we do
> on a daily basis.  We'd need a solution for deploying the TLS cert for,
> say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for
> maintenance.

I never really liked the per-country mirrors being under debian.org,
redirectors would be a better option. I think we really need to
redesign the apt archive namespace for Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: When should we https our mirrors?

[Paul Wise]

On Sun, Oct 16, 2016 at 2:03 AM, Paul Tagliamonte wrote:

> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?

Exactly what actions do you mean by this?

Debian does not control what mirror operators do, they are free to add
https or not. Some do but most don't.

httpredir.d.o is not well maintained, but it could theoretically
support https if someone cared about it.

deb.d.o is backed by two commercial CDNs, see Tollef's mail about that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: uscan download from sourceforge doesn't download what you expect!

[Paul Wise]

On Sun, Oct 16, 2016 at 1:47 AM, Steve M. Robbins wrote:

> Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed?

These days the reflector is just a proxy for the sourceforge RSS feeds:

https://sourceforge.net/projects/boost/rss?limit=1000

So check if the issue occurs in their RSS feed before sending a bug or patch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

On Thu, Oct 13, 2016 at 6:16 AM, Ben Finney wrote:

> How will we know that those are the corresponding source for the work
> Debian installs?

The maintainer could have verified it before uploading.

> One way is to actually use that exact source, to build the package.

That is the only realistic way to know.

> Do you know of another way which provides that level of confidence that
> we in fact have the complete corresponding source for a work, and that
> this remains true as the source package changes over time?

(Reproducible) builds from source (with continuous rechecking) is the
only way to have enough confidence that a Debian user has the freedoms
promised to them by the Debian social contract.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

On Tue, Oct 11, 2016 at 8:56 PM, Ondřej Surý wrote:

> Fine, I'll bundle them as well.

Bundling the actual source instead of prebuilt files still doesn't
solve the problem of not being able to build from source because the
build tools are missing from Debian. It has always been ftp-master
policy that source must be buildable on Debian and the latest mail
from them just reiterates that and states that yes, this does apply to
everything, including JavaScript.

https://lists.debian.org/debian-devel/2016/10/msg00138.html

> Just don't make me maintain a package in
> a language more horrible than PHP (in my eyes :-P).

Some day browsers will support WebAssembly so you can write in any
language that can compile to that. I'm sure people will start writing
web front-end code in PHP once it gets an LLVM backend ;P

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

On Tue, Oct 11, 2016 at 8:30 PM, Ondřej Surý wrote:

> Anybody is free to package epoch.js into separate package and I'll
> switch to using it, just don't shove more work by using BTS severities.

epoch.js upstream publishes their build info, so it looks like the
first step would be to finish the packaging of gulp. Once that is done
there are a number of gulp plugins to be packaged.

https://github.com/epochjs/epoch/
https://github.com/epochjs/epoch/blob/master/gulpfile.js
https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

On Tue, Oct 11, 2016 at 8:30 PM, Ondřej Surý wrote:

> Definitely not serious here, as I do ship original sources from within
> the package:
>
> $ find . -name 'epoch*'
> ./modules/http/static/epoch.css
> ./modules/http/static/epoch.js
> ./debian/missing-sources/epoch.css
> ./debian/missing-sources/epoch.js

These are not the source, these are:

https://github.com/epochjs/epoch/tree/master/sass/**.scss
https://github.com/epochjs/epoch/tree/master/src/**.coffee

-- 
bye,
pabs

https://wiki.debian.org/PaulWise