Bug#842659: ITP: ruby-truncato -- truncate HTML strings keeping the markup valid

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

from rubygems.org/gems/truncato



signature.asc
Description: OpenPGP digital signature

Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Ian Campbell]

Hi,

I maintain qcontrol[0] which builds on armel and armhf only (it's a
tool specific to certain NAS machines). It links a version against
liblua statically for use in a udeb (the resulting binary is dynamic,
it is only liblua5.1 which is linked statically).

It seems that on armhf my latest upload has failed to build for reasons
which look to be related to the PIE by default transition[1]:

cc -Wl,-z,relro -g qcontrol.o system.o qnap-pic.o ts209.o ts219.o ts409.o 
ts41x.o evdev.o a125.o synology.o /usr/lib/$(dpkg-architecture 
-qDEB_HOST_MULTIARCH)/liblua5.1.a -lpthread -lm -ldl -o qcontrol-static
/usr/bin/ld: /usr/lib/arm-linux-gnueabihf/liblua5.1.a(lapi.o): relocation 
R_ARM_THM_MOVW_ABS_NC against `luaO_nilobject_' can not be used when making a 
shared object; recompile with -fPIC

I've checked the wiki and the recent '"PIE by default" transition is
underway -- wiki needs updating' thread on d-devel but I'm none the
wiser on what my next course of action should be.

Should I be filing a bug against liblua asking for specific changes?
asking for a binNMU? Making some change to qcontrol's build (maybe
-fno-pic or -fno-pie, I've played with this a little with no luck so
far, I'll keep poking at it though)?

I don't see any preexisting bugs against liblua5.1 around the need for
changes or rebuild.

Thanks for any advice,

Ian.

[0] https://tracker.debian.org/pkg/qcontrol
[1] 
https://buildd.debian.org/status/fetch.php?pkg=qcontrol&arch=armhf&ver=0.5.5-1&stamp=1477849051
[2] https://wiki.debian.org/Hardening/PIEByDefaultTransition

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Jérémy Lal]

export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
?

2016-10-31 10:21 GMT+01:00 Ian Campbell :

> Hi,
>
> I maintain qcontrol[0] which builds on armel and armhf only (it's a
> tool specific to certain NAS machines). It links a version against
> liblua statically for use in a udeb (the resulting binary is dynamic,
> it is only liblua5.1 which is linked statically).
>
> It seems that on armhf my latest upload has failed to build for reasons
> which look to be related to the PIE by default transition[1]:
>
> cc -Wl,-z,relro -g qcontrol.o system.o qnap-pic.o ts209.o ts219.o
> ts409.o ts41x.o evdev.o a125.o synology.o /usr/lib/$(dpkg-architecture
> -qDEB_HOST_MULTIARCH)/liblua5.1.a -lpthread -lm -ldl -o qcontrol-static
> /usr/bin/ld: /usr/lib/arm-linux-gnueabihf/liblua5.1.a(lapi.o):
> relocation R_ARM_THM_MOVW_ABS_NC against `luaO_nilobject_' can not be used
> when making a shared object; recompile with -fPIC
>
> I've checked the wiki and the recent '"PIE by default" transition is
> underway -- wiki needs updating' thread on d-devel but I'm none the
> wiser on what my next course of action should be.
>
> Should I be filing a bug against liblua asking for specific changes?
> asking for a binNMU? Making some change to qcontrol's build (maybe
> -fno-pic or -fno-pie, I've played with this a little with no luck so
> far, I'll keep poking at it though)?
>
> I don't see any preexisting bugs against liblua5.1 around the need for
> changes or rebuild.
>
> Thanks for any advice,
>
> Ian.
>
> [0] https://tracker.debian.org/pkg/qcontrol
> [1] https://buildd.debian.org/status/fetch.php?pkg=qcontrol&;
> arch=armhf&ver=0.5.5-1&stamp=1477849051
> [2] https://wiki.debian.org/Hardening/PIEByDefaultTransition
>
>

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Ian Campbell]

On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> ?

Thanks, but that doesn't appear to help, I think the issue is to do
with the changed default in gcc rather than the hardening settings
injected into the build by dpkg-buildpackage/dpkg-buildflags (or
whatever it is which does it).

If possible I'd also prefer a solution which fixed qcontrol-static
without opting out for the normal dynamic/non-udeb binary.

Ian.

Bug#842670: ITP: incremental -- A library for versioning your Python projects.

[Free Ekanayaka]

Package: wnpp
Severity: wishlist
Owner: Free Ekanayaka 

* Package name: incremental
  Version : 16.10.1
  Upstream Author : Amber Brown 
* URL : https://github.com/hawkowl/incremental
* License : MIT
  Programming Lang: Python
  Description : A library for versioning your Python projects.

Incremental is a small library that versions Python projects.

It is a new dependency of Python Twisted (package source 'twisted'), so
I'm going to package it in order to upload version 16.5.0 of twisted
itself.

Bug#842671: ITP: calamares -- universal system installer framework

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: calamares
  Version : 2.4.3
  Upstream Author : Teo Mrnjavac 
* URL : https://calamares.io
* License : GPL-3+
  Programming Lang: C++, Python
  Description : universal system installer framework

Calamares is a distribution-independent installer framework.

It provides a graphical installer that can be used with nearly
any distribution. This package is suitable for live media on
Debian-based systems, and won't be of any particular use on
and already installed system.

You will likely want to provide your own config files to match
your distribution, reading the Calamares documentation will guide
you through that process.

Bug#842672: ITP: node-global-modules -- The directory used by npm for globally installed npm modules

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-global-modules
  Version : 0.2.3
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/global-modules
* License : Expat
  Programming Lang: JavaScript
  Description : The directory used by npm for globally installed npm
modules

Bug#842685: ITP: node-cache-base -- Basic object cache with `get`, `set`, `del`, and `has` methods for node.js/javascript projects

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-cache-base
  Version : 0.8.4
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/cache-base
* License : Expat
  Programming Lang: JavaScript
  Description : Basic object cache with `get`, `set`, `del`, and
`has` methods for node.js/javascript projects.

Bug#842686: ITP: libmonospaceif -- Interface translating libfizmo output to text

[Christoph Ender]

Package: wnpp
Severity: wishlist
Owner: Christoph Ender 

* Package name: libmonospaceif
  Version : 0.7.13
  Upstream Author : Christoph Ender 
* URL : https://fizmo.spellbreaker.org
* License : BSD
  Programming Lang: C
  Description : Interface translating libfizmo output to text

This interface will translate all Z-Machine output, including window
operations and text output, into simple place-cursor-at-x-y-and-print-text
events, which in turn can be used for simple ncurses-like output on
terminal-like displays. This is used by the fizmo-ncursesw frontend.

This library will be used as dependency for various fizmo-related frontends.

Bug#842689: ITP: libdrilbo -- Imaging support library for the fizmo Z-Machine interpreter

[Christoph Ender]

Package: wnpp
Severity: wishlist
Owner: Christoph Ender 

* Package name: libdrilbo
  Version : 0.2.9
  Upstream Author : Christoph Ender 
* URL : https://fizmo.spellbreaker.org
* License : BSD
  Programming Lang: C
  Description : Imaging support library for the fizmo Z-Machine interpreter

This library provides mg1, jpeg, png and X11-support for fizmo. It is
used by fizmo-related frontends or interfaces to support Z-Machine
related image processing.

Bug#842691: ITP: libsndifsdl2 -- SDL2-based sound support for the fizmo interpreter

[Christoph Ender]

Package: wnpp
Severity: wishlist
Owner: Christoph Ender 

* Package name: libsndifsdl2
  Version : 0.7.12
  Upstream Author : Christoph Ender 
* URL : https://fizmo.spellbreaker.org
* License : BSD
  Programming Lang: C
  Description : SDL2-based sound support for the fizmo interpreter

This library provides sound functionality related to the fizmo interpreter
using the SDL2 library. It supports Infocom's .snd files as well as AIFF
from blorb files.

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Bálint Réczey]

Hi Ian,

2016-10-31 10:38 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> ?
>
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening settings
> injected into the build by dpkg-buildpackage/dpkg-buildflags (or
> whatever it is which does it).

Yes, this is the case.

>
> If possible I'd also prefer a solution which fixed qcontrol-static
> without opting out for the normal dynamic/non-udeb binary.

I ran the build tests on amd64, this is why I have not caught this error.
A rebuild of lua5.1 should fix the problem.

Dpkg changes are on their way, too in the next days. I would ask
for a binNMU after dpkg is updated.

Cheers,
Balint

Bug#842692: ITP: fizmo-ncursesw -- Ncurses-based Z-machine interpreter for Infocom/Inform games

[Christoph Ender]

Package: wnpp
Severity: wishlist
Owner: Christoph Ender 

* Package name: fizmo-ncursesw
  Version : 0.7.12
  Upstream Author : Christoph Ender 
* URL : https://fizmo.spellbreaker.org
* License : BSD
  Programming Lang: C
  Description : Ncurses-based Z-machine interpreter for Infocom/Inform games

Fizmo is used to play old Infocom text adventures (except version 6) and
modern interactive fiction as created by the Inform compiler. The
fizmo-ncursesw implementation is a ncurses-(text-)based variant of this
Z-Machine interpreter.

So far "fizmo-ncursesw" was build out of the generic "fizmo" distribution
package, which is going to be split up in separate module/frontend 
packages. This new package is built from the new form of distribution.

Bug#842694: ITP: gnome-shell-extension-proxy-switcher -- gnome-shell-extension-proxy-switcher

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-proxy-switcher
  Version : 1.2
  Upstream Author : Tom Flannaghan 
* URL : https://github.com/tomflannaghan/proxy-switcher
* License : GPL-2+
  Programming Lang: JavaScript
  Description : gnome-shell-extension-proxy-switcher

Adds an option to the GNOME Shell system menu that allows a user
to quickly switch between no proxy, manual proxy and automatic
proxy settings.

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Henrique de Moraes Holschuh]

On Mon, 31 Oct 2016, Ian Campbell wrote:
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> > ?
> 
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening settings

Which is actually a bug: hardening=-pie (now) needs to actually inject
flags to disable PIE, instead.

-- 
  Henrique Holschuh

Bug#842697: ITP: libpixelif -- Interface translating fizmo output into pixel data

[Christoph Ender]

Package: wnpp
Severity: wishlist
Owner: Christoph Ender 

* Package name: libpixelif
  Version : 0.7.2
  Upstream Author : Christoph Ender 
* URL : https://fizmo.spellbreaker.org
* License : BSD
  Programming Lang: C
  Description : Interface translating fizmo output into pixel data

This library transforms fizmo's raw Z-Machine output into pixel-based
output operations. Text is processed using the freetype2 library. It
greatly simplifies the implementation of a GUI-based Z-Machine
interpreter and is used by the fizmo-sdl2 frontend.

Bug#842698: ITP: fizmo-sdl2 -- SDL2-based Z-machine interpreter for Infocom/Inform games

[Christoph Ender]

Package: wnpp
Severity: wishlist
Owner: Christoph Ender 

* Package name: fizmo-sdl2
  Version : 0.8.4
  Upstream Author : Christoph Ender 
* URL : https://fizmo.spellbreaker.org
* License : BSD
  Programming Lang: C
  Description : SDL2-based Z-machine interpreter for Infocom/Inform games

Fizmo is used to play old Infocom text adventures (except version 6) and
modern interactive fiction as created by the Inform compiler. This
package implements a SDL2-based interface which allows for
proportional font display, supporting antialiasing and HiDPI-displays.

Bug#842700: ITP: r-cran-isocodes -- GNU R package providing tables for several ISO codes

[Sébastien Villemot]

Package: wnpp
Severity: wishlist
Owner: "Sébastien Villemot" 

* Package name: r-cran-isocodes
  Version : 2016.03.15
  Upstream Author : Kurt Hornik 
* URL : https://cran.r-project.org/package=ISOcodes
* License : GPL-2
  Programming Lang: R
  Description : GNU R package providing tables for several ISO codes

This R package provides ISO 639 language codes, ISO 3166 territory codes, ISO
4217 currency codes, ISO 15924 script codes, and the ISO 8859 character codes
as well as the UN M.49 area codes.

It will be maintained within the Debian Science Team.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: PGP signature

Bug#842701: ITP: gnome-shell-extension-hard-disk-led -- Shows harddisk activity (IO speed read/write and LED) in GNOME Shell

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-hard-disk-led
  Version : 13
  Upstream Author : bigi 
* URL : https://github.com/biji/harddiskled
* License : GPL-3+
  Programming Lang: JavaScript
  Description : Shows harddisk activity (IO speed read/write and LED) in 
GNOME Shell

Many new laptops and some tiny computers do not have hard disk LEDs.
.
This extension ads an indicator to GNOME Shell that can either show
read/write speeds or LED lights to indicate activity.

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Bálint Réczey]

2016-10-31 12:52 GMT+01:00 Henrique de Moraes Holschuh :
> On Mon, 31 Oct 2016, Ian Campbell wrote:
>> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> > ?
>>
>> Thanks, but that doesn't appear to help, I think the issue is to do
>> with the changed default in gcc rather than the hardening settings
>
> Which is actually a bug: hardening=-pie (now) needs to actually inject
> flags to disable PIE, instead.

It is indeed a bug, but not an easily solvable one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149

Cheers,
Balint

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Ian Campbell]

On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> > If possible I'd also prefer a solution which fixed qcontrol-static
> > without opting out for the normal dynamic/non-udeb binary.
> 
> I ran the build tests on amd64, this is why I have not caught this error.
> A rebuild of lua5.1 should fix the problem.
> 
> Dpkg changes are on their way, too in the next days. I would ask
> for a binNMU after dpkg is updated.

Thanks, to check I understand: I should wait for #835146 to be fixed in
sid (which is expected to happen via a dpkg upload in the next days)
and then ask for a binNMU of lua5.1 then qcontrol (or maybe I have
reason to upload a newer qcontrol anyway, we'll see)?

Ian.

Re: Release Architectures for Debian 9 'Stretch'

[Jonathan Wiltshire]

On 2016-10-31 13:31, Jonathan Wiltshire wrote:

The only change from Jessie is the removal of powerpc as a release
architecture.


...and adding of mips64el. Oops.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Bálint Réczey]

Hi Ian,

2016-10-31 14:19 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
>> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
>> > If possible I'd also prefer a solution which fixed qcontrol-static
>> > without opting out for the normal dynamic/non-udeb binary.
>>
>> I ran the build tests on amd64, this is why I have not caught this error.
>> A rebuild of lua5.1 should fix the problem.
>>
>> Dpkg changes are on their way, too in the next days. I would ask
>> for a binNMU after dpkg is updated.
>
> Thanks, to check I understand: I should wait for #835146 to be fixed in
> sid (which is expected to happen via a dpkg upload in the next days)
> and then ask for a binNMU of lua5.1 then qcontrol (or maybe I have
> reason to upload a newer qcontrol anyway, we'll see)?

Yes, this should fix qcontrol and maybe you don't even have to ask for
rebuilds.  I think there is already an archive-wide rebuild planned to
make reproducibility-related changes in dpkg take effect thus I suggest
waiting a few days to see if you need to ask for binNMUs.

Cheers,
Balint

Re: Rebuilds with unexpected timestamps

[Adrian Bunk]

On Sun, Oct 30, 2016 at 11:48:56PM +, Simon McVittie wrote:
>...
> * Source for generated files in the tarball: should be in both git and
>   tarball, but sometimes mistakenly omitted from tarballs (e.g. configure.ac,
>   m4/foo.m4, build-aux/git-version-gen). Leaving these out of the tarball is
>   also an upstream bug, IMO, because it means the "source" tarball
>   is not really its own source. I'd suggest sending patches upstream to
>   add these to EXTRA_DIST.
>...

The ChangeLog file in the "source" tarball of the hello package is 
generated from the git metadata.

You are saying it is a bug that .git is not shipped in the source 
tarball of GNU hello?

> Regards,

cu
Adrian

-- 

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

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

[Adrian Bunk]

On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
>...
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"):
> > Be prepared to see a lot of such issues when you touch random files.
> 
> I'm certainly expecting to see lots of issues.
> 
> IMO if a package FTBFS when its timestamps are permuted, that is
> probably an RC bug.  It means that there are some files in the
> package, which it thinks it needs as part of the build process, but
> which cannot actually be built.
> 
> If it does "sufficiently different" things, but still succeeds, when
> the timestamps are permited then that's probably a minor or normal
> bug: evidently it can build either way, but this kind of situation is
> probably not intentional and it is setting us up for a future latent
> FTBFS.

The case where I end up with a building but broken "hello" program 
worries me a lot more than the case where I get a FTBFS in hello.

"hello has an empty version number" sounds harmless, but in a lot of 
cases the program or other packages using it might actually parse the
version number.

And I'd guess you might end up with even more complicated runtime issues 
if you mess with the timestamps of random files.

> > If you want this to work properly, Debian has to move from using the 
> > generated release tarballs to the actual source in the upstream VCS.
> 
> If the upstream tarballs are sufficient and our clean target ensures
> that everything is built from source, it can still work.

It can be made to work.

But I do not think it makes sense to do it this way.

Release tarballs contain sources plus generated files.

Lets look at the common "upstream uses git and autotools" case:

Using release tarballs made sense back in the days when git did not 
exist and Debian used the generated files for
  ./configure && make && make install

This already changed when packages started to use autoreconf on
a larger scale.

What you will end up with in practice is basically removing all 
generated files in the clean target.

This means that packages will use the release tarballs,
and then remove all files that are not in git.

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

The much-used git-buildpackage is already in that direction, and hacks 
like pristine-tar would disappear with an alternative source package 
format.

> Ian.

cu
Adrian

-- 

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

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

[Ian Jackson]

Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more 
messages]"):
> On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
...
> > If it does "sufficiently different" things, but still succeeds, when
> > the timestamps are permited then that's probably a minor or normal
> > bug: evidently it can build either way, but this kind of situation is
> > probably not intentional and it is setting us up for a future latent
> > FTBFS.
> 
> The case where I end up with a building but broken "hello" program 
> worries me a lot more than the case where I get a FTBFS in hello.
> 
> "hello has an empty version number" sounds harmless, but in a lot of 
> cases the program or other packages using it might actually parse the
> version number.
> 
> And I'd guess you might end up with even more complicated runtime issues 
> if you mess with the timestamps of random files.

I'm confused by what your point is.  Are you saying that issues of the
category I quote myself describing, above, should be considered RC ?

I think the archive probably has a great many situations of that kind,
and that my proposed approach to detecting them may not survive
contact with reality.

If you are as worried as you say about this, then I look forward to
your help in trying to do rebuilds with timestamp-fiddling and trying
to analyise the copious piles of indigestible build logs which I
expect such a process to produce.

Personally given my view that such bugs are probably not too serious,
I was intending (when I get round to it, which may not be soon) to
take crude measures to try to keep the false positive rate down.

> This means that packages will use the release tarballs,
> and then remove all files that are not in git.

This could be easily achieved by a combination of dgit and my proposed
`3.0 (rsync)' source package format.  If you're concerned about this
aspect, perhaps you would care to help with `3.0 (rsync)' ?  I sent a
Request For Help here but sadly no-one stepped up.

If you are interested in that, it might be best if (unpopular as I
sometimes make myself) I fronted the proposals to the various
stakeholders.  But I could sure use help with (eg) support in dak, and
finishing off support in dpkg-source.

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

I think dgit is a part of this jigsaw.  It allows maintainers using
git to publish a canonically-useful git history in a canonical
location.

I think dgit plus the hypothetical `3.0 (rsync)' has all the
properties you would hope for.  (There would still have to be .origs;
it's up to each maintainer whether those would be upstream's, or made
by gbp calling git-archive, or whatever.)

Ian.

-- 
Ian JacksonThese opinions are my own.

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

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

[Adrian Bunk]

On Mon, Oct 31, 2016 at 03:58:12PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more 
> messages]"):
> > On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
> ...
> > > If it does "sufficiently different" things, but still succeeds, when
> > > the timestamps are permited then that's probably a minor or normal
> > > bug: evidently it can build either way, but this kind of situation is
> > > probably not intentional and it is setting us up for a future latent
> > > FTBFS.
> > 
> > The case where I end up with a building but broken "hello" program 
> > worries me a lot more than the case where I get a FTBFS in hello.
> > 
> > "hello has an empty version number" sounds harmless, but in a lot of 
> > cases the program or other packages using it might actually parse the
> > version number.
> > 
> > And I'd guess you might end up with even more complicated runtime issues 
> > if you mess with the timestamps of random files.
> 
> I'm confused by what your point is.  Are you saying that issues of the
> category I quote myself describing, above, should be considered RC ?
> 
> I think the archive probably has a great many situations of that kind,
> and that my proposed approach to detecting them may not survive
> contact with reality.
> 
> If you are as worried as you say about this, then I look forward to
> your help in trying to do rebuilds with timestamp-fiddling and trying
> to analyise the copious piles of indigestible build logs which I
> expect such a process to produce.
> 
> Personally given my view that such bugs are probably not too serious,
> I was intending (when I get round to it, which may not be soon) to
> take crude measures to try to keep the false positive rate down.

What I am trying to say is that you will be opening a huge amount
of bugs for a very exotic problem, and that there is a solution
that will automatically fix a large part of them.

Many of the problems you are trying to solve would not be present if 
Debian would not be using upstream release tarballs.

A new git source format and a gradual switch to that would be a clean 
solution to solve most of these issues for a large part of the archive.

>...
> I think dgit plus the hypothetical `3.0 (rsync)' has all the
> properties you would hope for.  (There would still have to be .origs;
> it's up to each maintainer whether those would be upstream's, or made
> by gbp calling git-archive, or whatever.)

I am talking about a source format where the sole contents of the 
.orig.tar is the upstream .git, and the sole contents of .debian.tar
is debian/.git

> Ian.

cu
Adrian

-- 

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

Bug#842729: ITP: tendermint-flowcontrol -- library for arbitrary data stream's transfer rate handling

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: tendermint-flowcontrol
  Version : 0.0~git20151022.0.84d9671
  Upstream Author : The Tendermint project
* URL : http://www.tendermint.com/
* License : Apache-2.0
  Programming Lang: Golang
  Description : library for arbitrary data stream's transfer rate handling

 Tendermint Core is Byzantine Fault Tolerant (BFT) middleware
 that takes a state transition machine, written in any
 programming language, and replicates it on many machines.
 .
 Package flowcontrol provides the tools for monitoring and
 limiting the transfer rate of an arbitrary data stream.
 .
 This package is a dependency of the Tendermint core.

Bug#842736: RFP: libjira-rest-perl -- Perl module implementing a thin wrapper around JIRA's REST API

[Salvatore Bonaccorso]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libjira-rest-perl
  Version : 0.012
  Upstream Author : Gustavo L. de M. Chaves 
* URL : https://metacpan.org/release/JIRA-REST
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module implementing a thin wrapper around JIRA's REST 
API

JIRA::REST implements a very thin wrapper around JIRA's REST API

The package should be maintained under the umbrella of the Debian Perl Group.

Bug#842738: ITP: python-webencodings -- Python implementation of the WHATWG Encoding standard

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-webencodings
  Version : 0.5
  Upstream Author : Simon Sapin
* URL : https://github.com/gsnedders/python-webencodings
* License : BSD
  Programming Lang: Python
  Description : Python implementation of the WHATWG Encoding standard

In order to be compatible with legacy web content when interpreting
something like Content-Type: text/html; charset=latin1, tools need to
use a particular set of aliases for encoding labels as well as some
overriding rules. For example, US-ASCII and iso-8859-1 on the web are
actually aliases for windows-1252, and an UTF-8 or UTF-16 BOM takes
precedence over any other encoding declaration. The Encoding standard
defines all such details so that implementations do not have to
reverse-engineer each other.

This module has encoding labels and BOM detection, but the actual
implementation for encoders and decoders is Python’s.

This package is a new dependency for html5lib, which in turn is a
dependency for python-pip, so it will need to be rewheeled.

I intend to package this as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYF6icAAoJEBJutWOnSwa/HggP/2V7UXMmQJg7l7cMeDH4rnOV
8cAGsYB2bAw+U8ShyI4Q27S+NfNm9Xa57voi0lv1pA1/SUn3Ragl6+NWr0XYrhBN
2oSm2myN5GWUZSCyAWAxletAIwPsYJXuuaiDBs1aMgALpd28YxROO1OY/KRyQNCJ
HRYMHi3vhA24+xTJucZGTC31p0USHMfnwnCmtfWRnNuiqunL/IHaImJKv18NuZC3
CtTMdIhtPiZZI0LpHjxoU/ONG/4x5BKHo6tOOJ3NWc8ulDAOGCyjymsywdeSZOy5
X8CQWxixVh48Xgo4OwKeexQDh0bCQtQCyqZbv2M762yFkAntpdmeaaV2CoKEAmVJ
9FVN07Oe7cdt7pUUA7Twpp45yAypOHDaOoEWSX29/Quourkr5FFGMyYd99QtJ/VA
FnTweeX7v/EzbkgSEfnEDMlXEAD3Zm/3esZNczcL902H/JSSNh/00S5XFXHgEuRi
X4ptEEMr/3fZ7Jet3LeMcZo6it5hwHSDTkmcmAXNSGfRCSvha8hgage277aP6UYe
oBMd4qEvXd+QJw2WWtXxbZkNoYWFZopoVdoS1Fzr7LlDGgPuDNEL6qEFbAnV9UK+
l/qOOtubM2rYXwBssOxYrREDXRaKAD+qQ+ZH/y4zaA2RvH/aItS2J5SBvky/9aw7
90G6hJnX54DpzDEW/YTj
=2T5D
-END PGP SIGNATURE-

Bug#842750: ITP: libjira-rest-perl -- thin wrapper around JIRA's REST API

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libjira-rest-perl
  Version : 0.012
  Upstream Author : Gustavo L. de M. Chaves 
* URL : https://metacpan.org/release/JIRA-REST
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : thin wrapper around JIRA's REST API

The JIRA::REST module is a thin wrapper around JIRA's REST API, which is
superseding it's old SOAP API, for which there is another Perl module called
JIRA::Client.

JIRA  is a proprietary bug tracking
system from Atlassian .

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

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

Bug#842767: ITP: node-detect-file -- Detect if a filepath exists and resolves the full filepath

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-detect-file
  Version : 0.1.0
  Upstream Author : Brian Woodward (https://github.com/doowb)
* URL : https://github.com/doowb/detect-file
* License : Expat
  Programming Lang: JavaScript
  Description : Detect if a filepath exists and resolves the full
filepath

Bug#842772: ITP: tendermint-go-autofile -- Library for creating log files, WAL files, and more

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: tendermint-go-autofile
  Version : 0.0~git20161028.0.916f3d7-1
  Upstream Author : Tendermint
* URL : https://github.com/tendermint/go-autofile
* License : Apache-2.0
  Programming Lang: Go
  Description : Library for creating log files, WAL files, and more

 Tendermint Core is Byzantine Fault Tolerant (BFT) middleware
 that takes a state transition machine, written in any
 programming language, and replicates it on many machines.
 .
 This package provides a Library for creating log files, WAL
 files, and more, and it's used by various components of the
 Tendermint core.

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

[Adam Borowski]

On Tue, Nov 01, 2016 at 09:09:56AM +0800, Paul Wise wrote:
> 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.

Ie, we want the repositories pruned.  Git supports incomplete repositories
just fine (aka shallow clones), although I'm not aware of existing tools
that would shape the pruning of an existing repository.  You can "git clone
--depth=X" to a temp directory but that'd result in a flat repository.  It's
trivial to emulate a primitive scheme like quilt with its linear stack of
patches, but why bother?  Neither tarballs nor quilt are anywhere close to
being able to represent a preferred form for modification.  Representing
that, ie, a non-linear history that enables both-way code transfers between
forks, meaningful bisect, etc, is much harder.

Even in this crippled form, though, it is strictly better than quilt: for
any given "3.0 (quilt)" source package you can produce a "3.0 (git)" package
that ships the exact same set of data bits (metadata differs). 
Metadata-wise, both can ship arbitrary comments on patches; git doesn't
allow file timestamps but that's probably better than an _inconsistent_ set
of file timestamps: quilt preserves those on unpatched files but loses if
there's any change.  Git also gives you hash references to commits you've
pruned, which you can then fill in from another repository.  You also get
native signing for any commit.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#842773: ITP: node-object.omit -- Return a copy of an object excluding the given key, or array of keys

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-object.omit
  Version : 2.0.1
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/object.omit
* License : Expat
  Programming Lang: JavaScript
  Description : Return a copy of an object excluding the given key,
or array of keys. Also accepts an optional filter function as the last
argument.

Bug#842774: ITP: node-resolve-dir -- Resolve a directory that is either local, global or in the user's home directory

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-resolve-dir
  Version : 1.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/resolve-dir
* License : Expat
  Programming Lang: JavaScript
  Description : Resolve a directory that is either local, global or
in the user's home directory.