Bug#843955: ITP: node-grunt-legacy-log -- The Grunt 0.4.x logger

[Sruthi Chandran]

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

* Package name: node-grunt-legacy-log
  Version : 1.0.0
  Upstream Author : "Cowboy" Ben Alman (http://benalman.com/)
* URL : http://gruntjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : The Grunt 0.4.x logger

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

[Christoph Biedl]

Henrique de Moraes Holschuh wrote...

> There are some relevant issues, here.
> 
> 1. It does protect against passive snooping *from non-skilled
> attackers*.

Well, yes, no. The tools become better so thinking a few years into
the future sophisticated programs for that purpose might be available to
everyone. Imagine there was a time before wireshark/ethereal, and how
much work pcap analysis was back then.

> 2. It is unknown how much it can protect against passive snooping from
> skilled attackers capable of passive TCP metadata slooping and basic
> traffic analysis *FOR* something like the Debian archive and APT doing
> an update run against the Debian archive

The logical answer is pretty obvious: Not at all. It's a question of
efforts required and my gut feelings tell me it's not very much.

> Do not dismiss (2). TLS is not really designed to be able to fully
> protect object retrieval from a *fully known* *static* object store
> against traffic metadata analysis.   And an apt update run would be even
> worse to protect, as the attacker can [after a small time window from
> the mirror pulse] fully profile the more probable object combinations
> that would be retrieved depending on what version of Debian the user
> has.

Things are worse: There's a small set of clients, and their request
behaviour is quite deterministic. Another snooping aid is usage of
pdiff.

In total, I was not surprised if just given the frame metadata
(direction, high-res timestamp, payload size) it was possible to restore
the actual data transmitted with high accurancy. Even a dget/apt-get
source should have a pretty unique pattern; and I feel tempted to create
a proof of concept for all this (I can resist, though). The apt programs
could obfuscate their request behaviour, the TLS layer could add random
padding of data and time, but I doubt this would help much.

Another "wasn't surprised", applicances might already have that. If not,
the vendors could implement this easily.

> Now, hopefully I got all of that wrong and someone will set me straight.
>  It would make me sleep better at night...

Sorry Dorothy.

Christoph


signature.asc
Description: Digital signature

Bug#843952: ITP: node-grunt-legacy-util -- Some old grunt utils provided for backwards compatibility

[Sruthi Chandran]

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

* Package name: node-grunt-legacy-util
  Version : 1.0.0
  Upstream Author : "Cowboy" Ben Alman (http://benalman.com/)
* URL : http://gruntjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : Some old grunt utils provided for backwards
compatibility

Re: jquery 3.x uploaded to unstable

[Pirate Praveen]

[adding debian-ruby]

On Sunday 23 October 2016 04:23 AM, Antonio Terceiro wrote:
> jQuery 3.0 was release back in June, so in principle affected upstreams
> had at least a few months to deal with any fallout. If that's not the
> case, you can refer upstream to this upgrade guide, which documents the
> details:
> 
> https://jquery.com/upgrade-guide/3.0/

This broke diaspora, hopefully we can port it in time for stretch. Any
help is welcome. See https://github.com/diaspora/diaspora/issues/7179



signature.asc
Description: OpenPGP digital signature

Re: Building architecture:all packages

[Nikolaus Rath]

On Nov 11 2016, Christoph Biedl  wrote:
> b) This is a serious issue as John D. Rebuilder should be free to choose
>on which architecture to build "src:foo".
>
> Personally, I tend to b) since
>
> * there is no sane way for the maintainer to tell the world which
>   architecture should be used to rebuild this package. The .buildinfo
>   file will solve this, still
> * it is certainly rather unfriendly to expect John to have a box for
>   that particular architecture just to be able to do the rebuilding.

That's a good theoretical argument. But in practice, I think the subset
of architectures for which bar works correctly will always include
amd64, and John D. Rebuilder will have access to such a box for sure.

> In my opinion "src:foo" should see a "serious" bug report FTFBS,
> although it's just a victim of "bar". What about "bar"?
>
> Other suggestions?

Just fix it in "bar", and don't bother worrying about the right
severity?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

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

Building architecture:all packages

[Christoph Biedl]

Hello,

it is the nature of an arch:all binary package it can be installed on
any architecture regardless on which architecture it has been build.
Given this I deduced I'm at liberty on which architecture I'd want to
rebuild such a package, but I saw disagreement. So I'm asking for
clarification:

Given a simple source package "src:foo" that produces one arch:all
binary package "foo". The build needs the help of package "bar" which
happens to be arch:any, so technically speaking the build process isn't
identical while the result should be. (If you need an example, the
thousands of pure Perl library packages are of that kind.)

Now "bar" behaves different on different architectures, very likely
due to a bug, eventually resulting in a build failure on some while it
passes on other. More precisely, "bar" hasn't changed in years, the
problems began with a recent new upstream version of "foo". The
maintainer did the upload using a passing arch and probably never even
noticed.

Basically, there are two ways to judge this situation:

a) While "bar"'s behaviour certainly is questionable, this does not
   affect "foo" as long as it builds on at least one architecture (or a
   subset of the mostly used ones).

b) This is a serious issue as John D. Rebuilder should be free to choose
   on which architecture to build "src:foo".

Personally, I tend to b) since

* there is no sane way for the maintainer to tell the world which
  architecture should be used to rebuild this package. The .buildinfo
  file will solve this, still
* it is certainly rather unfriendly to expect John to have a box for
  that particular architecture just to be able to do the rebuilding.

On the other hand, option b) implies "src:foo" must build on *all*
architectures, and obviously such rebuild tests do not happen: Else the
build error I stumbled upon would have already been reported, and
hopefully fixed as well. In other words: This is a real story, I'm not
making it up. Also, the failing architecture isn't even an excotic one.

In my opinion "src:foo" should see a "serious" bug report FTFBS,
although it's just a victim of "bar". What about "bar"?

Other suggestions?

Christoph


signature.asc
Description: Digital signature

Work-needing packages report for Nov 11, 2016

[wnpp]

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

Total number of orphaned packages: 1002 (new: 20)
Total number of packages offered up for adoption: 154 (new: 1)
Total number of packages requested help for: 48 (new: 0)

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



The following packages have been orphaned:

   aoetools (#843435), orphaned 4 days ago
 Description: tools to assist in using ATA over Ethernet
 Installations reported by Popcon: 214
 Bug Report URL: http://bugs.debian.org/843435

   autodia (#843364), orphaned 4 days ago
 Description: generates UML diagrams from perl or C++ code
 Installations reported by Popcon: 189
 Bug Report URL: http://bugs.debian.org/843364

   capstone (#843440), orphaned 4 days ago
 Description: lightweight multi-architecture disassembly framework -
   devel files
 Reverse Depends: libcapstone-dev libradare2-0.10.6 libradare2-1.0
   python-capstone
 Installations reported by Popcon: 239
 Bug Report URL: http://bugs.debian.org/843440

   dimbl (#843328), orphaned 5 days ago
 Description: Distributed Memory Based Learner for Natural Language
   Processing
 Installations reported by Popcon: 104
 Bug Report URL: http://bugs.debian.org/843328

   distorm64 (#843445), orphaned 4 days ago
 Description: ultimate disassembler library for x86 code - header
   files
 Reverse Depends: libdistorm64-dev pyew
 Installations reported by Popcon: 80
 Bug Report URL: http://bugs.debian.org/843445

   gdevilspie (#843816), orphaned yesterday
 Description: User friendly interface for devilspie
 Installations reported by Popcon: 105
 Bug Report URL: http://bugs.debian.org/843816

   ipgrab (#843812), orphaned yesterday
 Description: tcpdump-like utility that prints detailed header
   information
 Installations reported by Popcon: 80
 Bug Report URL: http://bugs.debian.org/843812

   ldap2dns (#843591), orphaned 3 days ago
 Description: LDAP based DNS management system
 Installations reported by Popcon: 8
 Bug Report URL: http://bugs.debian.org/843591

   libarray-refelem-perl (#843358), orphaned 4 days ago
 Description: Set up array elements as aliases
 Reverse Depends: libdata-dumpxml-perl
 Installations reported by Popcon: 24
 Bug Report URL: http://bugs.debian.org/843358

   libdata-dumpxml-perl (#843357), orphaned 4 days ago
 Description: Dump arbitrary perl data structures as XML and restore
   them
 Installations reported by Popcon: 17
 Bug Report URL: http://bugs.debian.org/843357

   openwince-include (#843237), orphaned 5 days ago
 Description: Common include files for the open wince project
 Installations reported by Popcon: 17
 Bug Report URL: http://bugs.debian.org/843237

   openwince-jtag (#843238), orphaned 5 days ago
 Description: allows programming jtag capable devices such as CPUs or
   FPGAs
 Installations reported by Popcon: 38
 Bug Report URL: http://bugs.debian.org/843238

   pbnj (#843814), orphaned yesterday
 Description: a suite of tools to monitor changes on a network
 Installations reported by Popcon: 23
 Bug Report URL: http://bugs.debian.org/843814

   pyew (#843444), orphaned 4 days ago
 Description: Python tool like radare or *iew for malware analysis
 Installations reported by Popcon: 66
 Bug Report URL: http://bugs.debian.org/843444

   rat (#843443), orphaned 4 days ago
 Description: Unicast and multicast voice-over-IP application
 Installations reported by Popcon: 83
 Bug Report URL: http://bugs.debian.org/843443

   redmine-recaptcha (#843442), orphaned 4 days ago
 Description: Redmine plugin to add a reCAPTCHA to user
   self-registration
 Installations reported by Popcon: 17
 Bug Report URL: http://bugs.debian.org/843442

   ruby-recaptcha (#843437), orphaned 4 days ago
 Description: Ruby helpers for the reCAPTCHA API
 Reverse Depends: gitlab redmine-plugin-recaptcha
 Installations reported by Popcon: 35
 Bug Report URL: http://bugs.debian.org/843437

   swedish (#843755), orphaned yesterday
 Description: Swedish dictionary for ispell
 Reverse Depends: forensics-extra parl-desktop-eu parl-desktop-world
 Installations reported by Popcon: 683
 Bug Report URL: http://bugs.debian.org/843755

   yapps2 (#843359), orphaned 4 days ago
 Description: Yet Another Python Parser System
 Reverse Depends: keymapper yapps2
 Installations reported by Popcon: 106
 Bug Report URL: http://bugs.debian.org/843359

   zpb-ttf (#843820), orphaned yesterday
 Description: TTF parser
 Installations reported by Popcon: 43
 Bug Report URL: http://bugs.debian.org/843820

982 older package

Re: misleading timestamps in binnmus

[Aurelien Jarno]

On 2016-11-10 11:33, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson  (2016-11-09):
> > > What version of sbuild do buildds run ?  Ie, supposing that this is
> > > fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
> > > we need to update jessie, or what ?
> > 
> > sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> > going to summarize. The base version is close to what's in jessie (see the
> > first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
> ...
> > Repository seems to live under:
> >   https://apt.buildd.debian.org/
> 
> Thanks.  When Johannes has decided exactly what the sbuild patch looks
> like in sid, I will take a look at the repo there and backport the
> change.  In what form should I supply mhy update ?  As an source+all

When it's done, just ping us with the commit number, we will backport it
in our branch and we will deploy it on the build daemons.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#843934: ITP: django-redis-sessions -- Redis database backend for your sessions

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-redis-sessions
  Version : 0.5.6
  Upstream Author : Martin Rusev 
* URL : http://github.com/martinrusev/django-redis-sessions
* License : BSD
  Programming Lang: Python
  Description : Redis database backend for your Django sessions

 Session backend for Django that stores sessions in a Redis database 

I intend to maintain this within the Debian Python Modules Team.

Re: Issues when building armhf packages in sid chroot with merged-usr

[Marco d'Itri]

On Nov 10, Uwe Kleine-König  wrote:

> I tried to build the experimental linux package on an armhf machine
> using sbuild. It failed (after 7 hours, sigh) with:
This looks like #843073.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Issues when building armhf packages in sid chroot with merged-usr

[Uwe Kleine-König]

Hello,

I tried to build the experimental linux package on an armhf machine
using sbuild. It failed (after 7 hours, sigh) with:

dpkg-shlibdeps: error: no dependency information found for 
/usr/lib/ld-linux-armhf.so.3 (used by 
debian/linux-kbuild-4.9/usr/lib/linux-kbuild-4.9/scripts/pnmtologo)

I can reproduce the same problem with an easier package (memtool) from
unstable which already built fine on the buildd. On abel.d.o schroot -c
sid doesn't result in a system with /lib being a symlink to /usr/lib, so
I guess this still builds fine.

Maybe this is even not arm specific?

Best regards
Uwe


signature.asc
Description: PGP signature

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

[David Kalnischkies]

On Thu, Nov 10, 2016 at 12:39:40PM -0200, Henrique de Moraes Holschuh wrote:
> I'd prefer if we enhanced apt transports to run a lot more protected
> (preferably under seccomp strict) before any such push for enabling
> https transports in apt.  It would reduce the security impact a great
> deal.

I am helplessly optimistic, so I will say it again even if the past
tells me it pointless: Anyone in any way interest in improvements is
more than welcome to join deity@l.d.o / #debian-apt.

Very few things get done by just talking on d-d@ about nice to haves.


> Mind you, at fist look it seems like apt transports will *run as root*
> in Debian jessie.  HOWEVER I didn't do a deep check, just "ps aux" while
> apt was running.  And I didn't check in unstable.  So, I (hopefully)
> could be wrong about this.

For jessie you are right. The few of us took an awful lot of time to
basically reimplement many parts of the acquire subsystem in the last
few years. You can watch Michael talk about it at DC14, me at DC15 and
Julian at DC16 if you like, but the very basic summary is that in
stretch onwards all apt methods run effectively as _apt:nogroups (and
with no-new-privs) & apt itself requires repositories to be signed and
expects more than just SHA1 or MD5 (as usual, that applies to everything
related to apt like aptitude, synaptics, packagekit, apt-file, …).

There is still much we wanna do, but for now we are actually happy that
we seem to have managed to satisfy all the people who responded to those
changes: The army of complainers that it breaks their firewalls, strange
so called sneaker net abominations or other interesting workflows[0] …


> Can you imagine trying to contain an exploit in the wild that will take
> advantage of people trying to update their systems against said exploit
> to spread even further?  Well, this is exactly what would happen.  We

Let the code with no bugs cast the first stone – you could just as well
say that any http bug is if wrapped in https less critical. libcurl
depends on a crapload of stuff we don't actually need because we use it
just for https and not for ftp, samba, …. And then most TLS exploits
tend to be in tricking it to consider a cert valid while it isn't, which
is a big problem for most things, but for apt those kind of bugs are
a lot less critical as we don't trust the transport layer anyhow (if we
treat it more as a MITM annoyance instead of one-and-only security).
As such, completely non-empirical of course, but I think it would be
a net-benefit to have https sources available for use by default even if
its overrated in this context – but you will only die very tired if you
try to explain why https-everywhere is a requirement for your browser
and even most (language specific) package managers to add a tiny layer
of security to them, but our beloved apt doesn't strictly need it for
security (but happily accepts the tiny layer as addition).


As already said, we are open to consider replacing libcurl with
a suitable alternative like e.g. using libgnutls directly – but see
optimistic paragraph above, I still hope that a volunteer will show up…
(as the biggest TLS exploit is usually the implementor who hasn't worked
with the API before and I haven't).

And I would still like to have some for a-t-tor, too. The package is
even way smaller than even the smallest node packages [SCNR] nowadays
and someone with an eye for detail, integration and documentation could
do wonders… but I start to digress.


Best regards

David Kalnischkies

[0] https://xkcd.com/1172/


signature.asc
Description: PGP signature

Bug#843924: ITP: django-wkhtmltopdf -- Django module that provides views to wrap HTML to PDF conversions

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-wkhtmltopdf
  Version : 3.1.0
  Upstream Author : Incuna Ltd 
* URL : https://github.com/incuna/django-wkhtmltopdf
* License : MIT/Expat
  Programming Lang: Python
  Description : Django module that provides views to wrap HTML to PDF 
conversions

 Django Wkhtmltopdf provides Django views to wrap the HTML to PDF conversion
 of the `wkhtmltopdf `_ binary.

I intend to maintain this in the Debian Python Modules Team

Upstream did neglect to include the LICENSE file in the tarball (it's in git).
I already sent them a pull request to fix it and I'll add it locally for now.

Re: [buildd-tools-devel] Bug#843773: misleading timestamps in binnmus

[Ximin Luo]

(resending again to the correct addresses; I could never get used to debbugs CC 
behaviour.)

Ximin Luo:
> Ansgar Burchardt wrote:
>> The date from the last sourceful upload should probably still be used
>> for any date/time information included in generated files to ensure
>> they are identical on all architectures (or at least to try to do so).
>>
>> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
>> probably be set to the date of the last sourceful upload (instead of
>> just using the most recent changelog entry).
>>
> 
> Holger Levsen wrote:
>> On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
>>> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
>>> binNMU to a package.
>>>
>>> Any other ideas?
>>
>> set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
>> entry?
>>
> 
> I'm tending towards the latter suggestion because it's simpler. There's no 
> need to stick to a +1 second scheme etc, and it might mislead people into 
> thinking they can do calculations with this - such as reversing the original 
> timestamp of the sourceful-upload.
> 
> Our naming of "SOURCE_DATE_EPOCH" did not really take into account the fact 
> that a source package can be built with many different configurations to 
> create many different build products that are each reproducible themselves. 
> (Debian itself also doesn't do this too clearly, the "+bn" syntax "looks 
> like" it's just a suffix but actually signals an entirely different namespace 
> from source package versions.)
> 
> If it helps one sleep better, one can interpret the "SOURCE" in 
> "SOURCE_DATE_EPOCH" to refer to "all implicit and explicit inputs of the 
> build result, including the source code of the package being built but also 
> the binary build dependencies".
> 
> (If you want to be super-accurate, you can take the max() of all of the 
> changelogs of all of the transitive build-deps, but I think that's going a 
> bit too far.)
> 
> X
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#843915: ITP: django-organizations -- Django groups and multi-user account management module

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-organizations
  Version : 0.8.2
  Upstream Author : Ben Lopatin 
* URL : https://github.com/bennylope/django-organizations/
* License : BSD
  Programming Lang: Python
  Description : Django groups and multi-user account management module

 Django Organizations adds user-managed, multi-user groups to your Django
 project. Use Django Organizations whether your site needs organizations that
 function like social groups or multi-user account objects to provide account
 and subscription functionality beyond the individual user.
 .
   * Works with your existing user model, whether
  `  django.contrib.auth` or a custom model. No additional user
 or authentication functionality required.
   * Users can be belong to and own more than one organization (account, group)
   * Invitation and registration functionality works out of the box for many
 situations and can be extended as need to fit specific requirements.
   * Start with the base models or use your own for greater customization.

I intend to maintain this package in the Debian Python Modules Team

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

[Henrique de Moraes Holschuh]

On Mon, Oct 24, 2016, at 00:28, Russ Allbery wrote:
> The value of HTTPS lies in its protection against passive snooping. 

There are some relevant issues, here.

1. It does protect against passive snooping *from non-skilled
attackers*.  And this is not being made anywhere clear enough.

2. It is unknown how much it can protect against passive snooping from
skilled attackers capable of passive TCP metadata slooping and basic
traffic analysis *FOR* something like the Debian archive and APT doing
an update run against the Debian archive (i.e. this comment is NOT valid
for ANY OTHER USE of https).

Do not dismiss (2). TLS is not really designed to be able to fully
protect object retrieval from a *fully known* *static* object store
against traffic metadata analysis.   And an apt update run would be even
worse to protect, as the attacker can [after a small time window from
the mirror pulse] fully profile the more probable object combinations
that would be retrieved depending on what version of Debian the user
has.

apt-transport-https really exists to help people bypass half-hearted
filtering and logging by corporate or ISP web proxies, and it is very
good for that. It is a valid user case, and one we do want to support. 
But it shouldn't be sold as a strong privacy defense, *ever*.

There wouldn't be a reason to not enable apt-transport-https: at this
point of the analysis: it is still not making things really any worse,
so you'd likely have a net gain since it does raise the bar for the
attackers.

However, there are these little real world details called "attack
surface" and "implementation complexity" as sources of exploitable
security vulnerabilities, and the picture changes a lot when you start
looking at that angle:

(up-to-date Debian stable/jessie amd64 system):

ldd /usr/lib/apt/methods/http | cut -d '(' -f 1
linux-vdso.so.1
libapt-pkg.so.4.12 =>
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
/lib64/ld-linux-x86-64.so.2

compared with:

ldd /usr/lib/apt/methods/https | cut -d '(' -f 1
linux-vdso.so.1
libapt-pkg.so.4.12 =>
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
libcurl-gnutls.so.4 =>
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4
libgnutls-deb0.so.28 =>
/usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
libgssapi_krb5.so.2 =>
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
libldap_r-2.4.so.2 =>
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
/lib64/ld-linux-x86-64.so.2
libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
libkrb5support.so.0 =>
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6


I assume I don't have to remind anyone of the security history of the
above library s

Re: misleading timestamps in binnmus

[Johannes Schauer]

Hi,

Quoting Niko Tyni (2016-11-10 10:01:38)
> On Thu, Nov 10, 2016 at 10:34:33AM +, Holger Levsen wrote:
> > can someone please point at a real life/archive example of such a file?
> > (a binNMU .changes file with Binary-Only-Changes field…)
> 
> That's in the .buildinfo file (not .changes), and I don't think they are
> stored in the archive yet? But just try building a binNMU with sbuild
> and look at the resulting .buildinfo. Something like
> 
>   sbuild --make-binNMU="test rebuild" -m"Niko Tyni " 
> --binNMU=2 libxml-parser-perl_2.44-2

if you are using sbuild 0.69.0 or newer, then you do not need to add the
version to the package name as shown above, but you can just pass the source
package name and sbuild will automatically figure out the highest version.

If you don't have $distribution defined in your ~/.sbuildrc, then above call is
missing the -d/--dist option to specify the distribution you want to build for
or at least the -c/--chroot option to know which chroot to use for downloading
the source package.

> To reproduce a binNMU from a .buildinfo file, one would need to parse the
> Binary-Only-Changes field and extract the parts that needs to be passed to
> sbuild. This currently seems rather fragile as noted by Ian in #843773: the
> binNMU version needs to be parsed from the +bX notation, and the message
> needs to be separated from the "Binary-only [...]" text that's hardcoded in
> sbuild and might even change in the future. And then there's the timestamp
> issue where I'll defer to others :)

It seems to me that rather than passing all these values as individual options
to sbuild, there should be a way to pass the whole changelog entry all at one.
For example, imagine that sbuild at some point changes the "Binary-only
non-maintainer upload..." message. Or imagine other package builders supporting
binNMUs like pbuilder using a different message. Unfortunately, it's tricky to
pass multi-line values as a command line option.

But maybe this feature is only required when having a .buildinfo file available
anyway, in which case, sbuild would have access to the Binary-Only-Changes
field by just giving it the .buildinfo file.  But if we go that way and let
sbuild accept the .buildinfo file directly, then that would make efforts like
the debrebuild.pl script, which is just a wrapper to sbuild and other package
builders (see #774415), impossible. It would then be required to move the
debrebuild machinery directly into sbuild (and any other package builder which
wants to be able to test-rebuild a given .buildinfo file).

Thanks!

cheers, josch


signature.asc
Description: signature

Re: DEP14 policy for two dots

[Raphael Hertzog]

On Wed, 09 Nov 2016, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like
> > a reasonable extension.
> 
> Attached.  FYI I intend to implement this in dgit.

Thanks, committed to the dep svn repository.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Processed: reassign 843891 to akonadi, forcibly merging 843534 843891

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 843891 akonadi
Bug #843891 [general] general: mySQL update killed akonadi configuration and 
leaves Kmail and KOrganizer and Adressbook unusable
Bug reassigned from package 'general' to 'akonadi'.
Ignoring request to alter found versions of bug #843891 to the same values 
previously set
Ignoring request to alter fixed versions of bug #843891 to the same values 
previously set
> forcemerge 843534 843891
Bug #843534 [akonadi] [akonadi-server] Fails to start after mysql upgrade
Bug #843891 [akonadi] general: mySQL update killed akonadi configuration and 
leaves Kmail and KOrganizer and Adressbook unusable
There is no source info for the package 'akonadi' at version '1.13.0-2+deb8u1' 
with architecture ''
Unable to make a source version for version '1.13.0-2+deb8u1'
Marked as found in versions 1.13.0-2+deb8u1.
Added tag(s) newcomer, patch, and help.
Merged 843534 843891
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
843534: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843534
843891: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843891
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#843891: general: mySQL update killed akonadi configuration and leaves Kmail and KOrganizer and Adressbook unusable

[Rouven-Matthias Müller]

Package: general
Severity: important

Dear Maintainer,

the mySQL update killed the akonadi configuration and leaves Kmail and
KOrganizer and Adressbook unusable.

i report this to general, for the simple fact, that someone should have checked
in general that this update does not kill importat work related computers PIM
capabilities. I now have no email and my kalendar wich not only contains my
apointments but my journal and my todo list is also blocked.

here is the console output of akonadi failing to start:

Starting Akonadi Server...
   done.
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
rouven@BLACKBEAUTY:~$ search paths:  ("/usr/local/bin", "/usr/bin", "/bin",
"/usr/local/games", "/usr/games", "/usr/sbin", "/usr/local/sbin",
"/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec",
"/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
Found mysql_install_db:  "/usr/bin/mysql_install_db"
Found mysqlcheck:  ""
Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
arguments: ("--defaults-file=/home/rouven/.local/share/akonadi/mysql.conf", "--
datadir=/home/rouven/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-
rouven.nhrlME/mysql.socket")
stdout: ""
stderr: "/usr/sbin/mysqld: Error on realpath() on '/var/lib/mysql-files' (Error
2)
161110 14:24:55 [ERROR] Failed to access directory for --secure-file-priv.
Please make sure that directory exists and is accessible by MySQL Server.
Supplied value : /var/lib/mysql-files
161110 14:24:55 [ERROR] Aborting

"
exit code: 1
process error: "Unknown error"
"[
0: akonadiserver() [0x418c9a]
1: akonadiserver() [0x418f14]
2: /lib/x86_64-linux-gnu/libc.so.6(+0x350e0) [0x7fdab6c9d0e0]
3: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7fdab6c9d067]
4: /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fdab6c9e448]
5: /usr/lib/x86_64-linux-
gnu/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x12a) [0x7fdab84a7a9a]
6: akonadiserver() [0x41ad1d]
7: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x8a)
[0x7fdab854723a]
8: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x120855) [0x7fdab8556855]
9: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31)
[0x7fdab855f1b1]
10: akonadiserver() [0x481eee]
11: akonadiserver() [0x41b91f]
12: akonadiserver() [0x41e008]
13: akonadiserver() [0x4e29e9]
14: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x1e1)
[0x7fdab85d5e11]
15: /usr/lib/x86_64-linux-
gnu/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8d)
[0x7fdab85bc71d]
16: /usr/lib/x86_64-linux-
gnu/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x231)
[0x7fdab85bffc1]
17: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1b5bd3) [0x7fdab85ebbd3]
18: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d)
[0x7fdab6366c5d]
19: /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f48) [0x7fdab6366f48]
20: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)
[0x7fdab6366ffc]
21: /usr/lib/x86_64-linux-
gnu/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5d)
[0x7fdab85ebd1d]
22: /usr/lib/x86_64-linux-
gnu/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x41)
[0x7fdab85bb271]
23: /usr/lib/x86_64-linux-
gnu/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1a5)
[0x7fdab85bb5d5]
24: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99)
[0x7fdab85c1059]
25: akonadiserver() [0x4131c5]
26: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fdab6c89b45]
27: akonadiserver() [0x413bee]
]
"
ProcessControl: Application 'akonadiserver' returned with exit code 255
(Unknown error)
search paths:  ("/usr/local/bin", "/usr/bin", "/bin", "/usr/local/games",
"/usr/games", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec",
"/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin",
"/opt/mysql/sbin")
Found mysql_install_db:  "/usr/bin/mysql_install_db"
Found mysqlcheck:  ""
Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
arguments: ("--defaults-file=/home/rouven/.local/share/akonadi/mysql.conf", "--
datadir=/home/rouven/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-
rouven.nhrlME/mysql.socket")
stdout: ""
stderr: "/usr/sbin/mysqld: Error on realpath() on '/var/lib/mysql-files' (Error
2)
161110 14:24:55 [ERROR] Failed to access directory for --secure-file-priv.
Please make sure that directory exists and is accessible by MySQL Server.
Supplied value : /var/lib/mysql-files
161110 14:24:55 [ERROR] Aborting

"
exit code: 1
process error: "Unknown error"
"[
0: akonadiserver() [0x418c9a]
1: akonadiserver() [0x418f14]
2: /lib/x86_64-linux-gnu/libc.so.6(+0x350e0) [0x7fa1ef3890e0]
3: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7fa1ef389067]
4: /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) 

Bug#843889: ITP: django-maintenancemode -- django application that allows setting a site as down for maintenance (503)

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-maintenancemode
  Version : 0.11.2
  Upstream Author : Remco Wendt 
* URL : http://github.com/shanx/django-maintenancemode
* License : BSD
  Programming Lang: Python
  Description : django application that allows setting a site as down for 
maintenance (503)

 django-maintenancemode is a middleware that allows you to temporarily
 shutdown your site for maintenance work.
.
 Logged in users having staff credentials can still fully use the site as can
 users visiting the site from an IP address defined in Django's
 ``INTERNAL_IPS``.

I intend to maintain this withing the Debian Python Modules Team.

Re: misleading timestamps in binnmus

[Ansgar Burchardt]

On Thu, 2016-11-10 at 11:33 +, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson  (2016-11-09):
> > > What version of sbuild do buildds run ?  Ie, supposing that this
> > > is
> > > fixed in sbuild in stretch, will this be fixed on the buildds
> > > ?  Or do
> > > we need to update jessie, or what ?
> > 
> > sbuild on buildds uses a specific version of sbuild, for reasons
> > I'm not
> > going to summarize. The base version is close to what's in jessie
> > (see the
> > first lines of any build log which has “sbuild (Debian sbuild)
> > 0.65.2”).
> 
> ...
> > Repository seems to live under:
> >   https://apt.buildd.debian.org/
> 
> Thanks.  When Johannes has decided exactly what the sbuild patch
> looks
> like in sid, I will take a look at the repo there and backport the
> change.  In what form should I supply mhy update ?  As an source+all
> upload of sbuild, as if I were being sponsored ?  As a
> git-format-patch against a git import of what I find there (or a
> dgitish git branch) ?

The source for the sbuild variant used on the buildds lives in a branch
of the sbuild repository (`buildd-0.65` for the current version I
think).

Ansgar

Re: [buildd-tools-devel] Bug#843773: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> binNMU to a package.
> 
> Any other ideas?

set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
entry?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: misleading timestamps in binnmus

[Niko Tyni]

On Thu, Nov 10, 2016 at 10:34:33AM +, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 08:24:38AM -0200, Johannes Schauer wrote:
> > > I certainly hope it's part of the .buildinfo file as well, else, for
> > > reproducing binNMUs we would also need to store the .changes files in an
> > > easily accessable manner… (which we plan to do for .buildinfo files, but
> > > not for .changes files atm…)
> > 
> > for binary-only uploads, dpkg-genbuildinfo will add the Binary-Only-Changes
> > field to the .buildinfo file which contains the text of the last changelog
> > entry together with the maintainer name and date.
> 
> can someone please point at a real life/archive example of such a file?
> (a binNMU .changes file with Binary-Only-Changes field…)

That's in the .buildinfo file (not .changes), and I don't think they are
stored in the archive yet? But just try building a binNMU with sbuild
and look at the resulting .buildinfo. Something like

  sbuild --make-binNMU="test rebuild" -m"Niko Tyni " 
--binNMU=2 libxml-parser-perl_2.44-2

results in a .buildinfo file with

  Format: 0.1
  Source: libxml-parser-perl (2.44-2)
  Binary: libxml-parser-perl
  Architecture: amd64
  Version: 2.44-2+b2
  Binary-Only-Changes:
   libxml-parser-perl (2.44-2+b2) unstable; urgency=low, binary-only=yes
   .
 * Binary-only non-maintainer upload for amd64; no source changes.
 * test rebuild
   .
-- Niko Tyni   Tue, 05 Jul 2016 21:55:41 +0200
  Checksums-Md5:
 [...]

> I'm still confused, thinking that this Binary-Only-Changes field needs
> to be assembled into a file, called changelog.$arch, which is then put
> into the debian directory of the unpacked source package. (And which is
> then not included in the resulting binary packages…)

When asked to make a binNMU, sbuild will append an entry to
debian/changelog in the source, containing "binary-only=yes". During
package build, dh_installchangelogs (so debhelper not dpkg!) will
then extract that debian/changelog entry and install that in the
binary package as /usr/share/doc//changelog.Debian.,
separately from the rest of the changelog which goes to
/usr/share/doc//changelog.Debian. (This is done to not break
M-A:same coinstallability.)

As Johannes wrote, dpkg-genbuildinfo will also read debian/changelog in
the source and write out a corresponding Binary-Only-Changes field in the
resulting .buildinfo if the changelog entry contains "binary-only=yes".

To reproduce a binNMU from a .buildinfo file, one would need to parse
the Binary-Only-Changes field and extract the parts that needs to be
passed to sbuild. This currently seems rather fragile as noted by Ian
in #843773: the binNMU version needs to be parsed from the +bX notation,
and the message needs to be separated from the "Binary-only [...]" text
that's hardcoded in sbuild and might even change in the future. And then
there's the timestamp issue where I'll defer to others :)

But all that seems fixable on the sbuild side, and I think Johannes is
actively working on this stuff (thanks!)

Hope this clarifies a bit,
-- 
Niko Tyni   nt...@debian.org

Bug#843882: RFP: python-ramlfications -- Python parser for RAML

[Paolo Greppi]

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

--- Please fill out the fields below. ---

   Package name: python-ramlfications
Version: 0.1.9
Upstream Author: Lynn Root, Spotify AB
URL: https://github.com/spotify/ramlfications
License: Apache-2
Description: Python parser for RAML.
.
ramlfications is a reference implementation of a RAML parser in Python
intended to be used for parsing API definitions (e.g. for static
documentation-generation).
.
RESTful API Modeling Language (RAML) is a simple and succinct way of
describing practically-RESTful APIs. It encourages reuse, enables
discovery and pattern-sharing, and aims for merit-based emergence of
best practices. The goal is to help our current API ecosystem by solving
immediate problems and then encourage ever-better API patterns. RAML is
built on broadly-used standards such as YAML and JSON and is a
non-proprietary, vendor-neutral open spec.

Ciao, Paolo

P.S. the interest in this is that python-ramlfications is a
build-dependency for buildbox 0.9.1 (required during the docs build step)



signature.asc
Description: OpenPGP digital signature

Re: misleading timestamps in binnmus

[Ian Jackson]

Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> Ian Jackson  (2016-11-09):
> > What version of sbuild do buildds run ?  Ie, supposing that this is
> > fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
> > we need to update jessie, or what ?
> 
> sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> going to summarize. The base version is close to what's in jessie (see the
> first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
...
> Repository seems to live under:
>   https://apt.buildd.debian.org/

Thanks.  When Johannes has decided exactly what the sbuild patch looks
like in sid, I will take a look at the repo there and backport the
change.  In what form should I supply mhy update ?  As an source+all
upload of sbuild, as if I were being sponsored ?  As a
git-format-patch against a git import of what I find there (or a
dgitish git branch) ?

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: misleading timestamps in binnmus

[Adam D. Barratt]

On Thu, 2016-11-10 at 10:34 +, Holger Levsen wrote:
> I'm still confused, thinking that this Binary-Only-Changes field needs
> to be assembled into a file, called changelog.$arch, which is then put
> into the debian directory of the unpacked source package. (And which is
> then not included in the resulting binary packages…)

They're very much in the binary packages. On the jessie laptop I'm
typing this mail on:

adam@jacala:~$ find /usr/share/doc/ -name 'changelog.Debian.amd64.gz' | wc -l
236

Regards,

Adam

Re: [buildd-tools-devel] Bug#843773: misleading timestamps in binnmus

[Johannes Schauer]

Hi,

Quoting Emilio Pozuelo Monfort (2016-11-10 07:04:55)
> On 10/11/16 10:00, Ansgar Burchardt wrote:
> > The date from the last sourceful upload should probably still be used
> > for any date/time information included in generated files to ensure
> > they are identical on all architectures (or at least to try to do so).
> > 
> > If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
> > probably be set to the date of the last sourceful upload (instead of
> > just using the most recent changelog entry).
> 
> There are many differences among different architectures, see e.g.:
> 
> lame (3.99.5+repack1-9+b1) sid; urgency=low, binary-only=yes
> 
>   * Binary-only non-maintainer upload for amd64; no source changes.
>   * Rebuild against ncurses 6.0.
> 
>  -- amd64 / i386 Build Daemon (x86-csail-01)
>   Thu, 11 Jun 2015 12:33:22 +0200
> 
> But that is not a problem as the entry is added to changelog.$arch for this 
> reason.

ansgar is not just talking about the changelog which indeed lives in different
files, depending on the host architecture.

What if there are files that are shared by a M-A:same package but with content
that depends on SOURCE_DATE_EPOCH? If we just generate a new date for every
individual build, then these files will be different and the package not be
co-installable anymore.

Quoting Sven Joachim (2016-11-10 07:14:27)
> Wouldn't this cause dpkg-deb to clamp the mtime to that date, precisely
> the problem this thread is all about?

yes, which is why we probably shouldn't set SOURCE_DATE_EPOCH to the same value
again but find a different solution.

One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
binNMU to a package.

Any other ideas?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 08:24:38AM -0200, Johannes Schauer wrote:
> > I certainly hope it's part of the .buildinfo file as well, else, for
> > reproducing binNMUs we would also need to store the .changes files in an
> > easily accessable manner… (which we plan to do for .buildinfo files, but
> > not for .changes files atm…)
> 
> for binary-only uploads, dpkg-genbuildinfo will add the Binary-Only-Changes
> field to the .buildinfo file which contains the text of the last changelog
> entry together with the maintainer name and date.

can someone please point at a real life/archive example of such a file?
(a binNMU .changes file with Binary-Only-Changes field…)

I'm still confused, thinking that this Binary-Only-Changes field needs
to be assembled into a file, called changelog.$arch, which is then put
into the debian directory of the unpacked source package. (And which is
then not included in the resulting binary packages…)

Maybe I'm just confused because this is news to me and I've never seen
nor heart about it.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: misleading timestamps in binnmus

[Johannes Schauer]

Hi,

Quoiting Holger Levsen (2016-11-10 07:48:33)
> On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote:
> > > I see. And this changelog.$arch is neither part of the source package,
> > > the .changes file nor the .buildinfo file, it's just included in the
> > > binary packages? Or is it also part of the .changes file?
> > It's in .changes as well. No idea if (any of it) is in .buildinfo
>  
> I certainly hope it's part of the .buildinfo file as well, else, for
> reproducing binNMUs we would also need to store the .changes files in an
> easily accessable manner… (which we plan to do for .buildinfo files, but
> not for .changes files atm…)

for binary-only uploads, dpkg-genbuildinfo will add the Binary-Only-Changes
field to the .buildinfo file which contains the text of the last changelog
entry together with the maintainer name and date.

cheers, josch


signature.asc
Description: signature

Re: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote:
> > I see. And this changelog.$arch is neither part of the source package,
> > the .changes file nor the .buildinfo file, it's just included in the
> > binary packages? Or is it also part of the .changes file?
> It's in .changes as well. No idea if (any of it) is in .buildinfo
 
I certainly hope it's part of the .buildinfo file as well, else, for
reproducing binNMUs we would also need to store the .changes files in an
easily accessable manner… (which we plan to do for .buildinfo files, but
not for .changes files atm…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 10:33, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
>> These days, a changelog entry is added to a changelog.$arch. This is to avoid
>> problems when co-installing ma:same packages, as the changelog entries 
>> will/may
>> differ between different architectures.
> 
> I see. And this changelog.$arch is neither part of the source package,
> the .changes file nor the .buildinfo file, it's just included in the
> binary packages? Or is it also part of the .changes file?

It's in .changes as well. No idea if (any of it) is in .buildinfo

Cheers,
Emilio

Re: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
> These days, a changelog entry is added to a changelog.$arch. This is to avoid
> problems when co-installing ma:same packages, as the changelog entries 
> will/may
> differ between different architectures.

I see. And this changelog.$arch is neither part of the source package,
the .changes file nor the .buildinfo file, it's just included in the
binary packages? Or is it also part of the .changes file?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule [and 1 more messages]

[Emilio Pozuelo Monfort]

On 10/11/16 08:26, Christoph Biedl wrote:
> Ian Jackson wrote...
> 
>> I think what is really worrying people is the fear that they might
>> miss something, for good reasons, and then find that their work that
>> they care about is thrown out of stretch.
>>
>> It is difficult to address this fear with logical arguments intended
>> to demonstrate that "it won't happen to a responsible maintainer",
>> because it is so easy to think of scenarios where, at the very least,
>> it's hard to be sure that the right things would happen.
> 
> For me it's a bit different. If John S.(lacker) Maintainer ignored the
> messages about debhelper compat 4 removal for ten and about the
> openssl 1.1 transition for seven months, and in January suddenly finds
> his packages got kicked out and cannot return for stretch - he had it
> coming.
> 
> If however Jane R.(esponsible) Maintainer did everything right but did
> not realize somebody else's non-action affects her packages as well,
> through a build dependency or whatever ... until the "Your package was
> removed from testing" e-mail arrives: That's quite a nuisance.
> 
> So if I, in Jane's position, could be certain I'll learn about a
> pending removal that affects my packages early enough I can avoid this
> (by kicking the maintainer or NMU), my concerns were neglectable. A
> grace period of just a few days was sufficient. This mechanism is
> implemented for install dependencies, but after reading this thread
> I'm not sure it exists for other scenarios as well. 
> 
>> On the other hand, it would be really easy for the Release Team to
>> address this fear.  All they have to say is that if there is a really
>> good excuse (maintainer seriously ill; build-dependency broken and
>> maintainer not notified; or whatever), they will be willing to
>> consider exceptions.
> 
> I guess the Release Team plays tough in the first place so people do
> their job *now* instead of asking for exceptions later. I'd call that
> wise tactics. The e-thing still might happen if there's really, really
> good reason. But creating false hope sends the wrong signal. 
> 
> Finally, there's a thing called "trust": I trust the Release Team does
> this solely in order to keep the freeze time as short as possible,
> everybody hates that time anyway. This trust was created by the very
> people behind it, and the way they acted in the past months.

+1.

And yes, we will give exceptions on a case by case basis, as we have always 
done.

Also, as has been noted in this thread, it looks like some processes could be
improved (e.g. notifying rdeps when removing a package from unstable). Let's see
what affects the release process and then let's try to improve those things.

Cheers,
Emilio

Re: misleading timestamps in binnmus

[Sven Joachim]

On 2016-11-10 10:00 +0100, Ansgar Burchardt wrote:

> The date from the last sourceful upload should probably still be used
> for any date/time information included in generated files to ensure
> they are identical on all architectures (or at least to try to do so).
>
> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
> probably be set to the date of the last sourceful upload (instead of
> just using the most recent changelog entry).

Wouldn't this cause dpkg-deb to clamp the mtime to that date, precisely
the problem this thread is all about?

Cheers,
   Sven

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 10:00, Ansgar Burchardt wrote:
> On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
>> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
>>> It seems that sbuild indeed re-uses the timestamp from the last
>>> debian/changelog entry in the binNMU changelog entry.
>>
>> This has been done in an early attempt to make binNMUs co-installable 
>> in a multiarch world:
>>
>> ,
>>> sbuild (0.62.2-1) unstable; urgency=low
>>> [...]
>>> - Improve binNMU handling to permit binNMUs for multiarch
>>> packages
>>>   (Closes: #620112).  Currently, binary NMUs use the current
>>> date
>>>   in the new changelog entry, but co-installable packages
>>> require
>>>   an identical changelog.  To avoid this, take the date from
>>> the
>>>   previous changelog entry to ensure the same date for all
>>> binNMUs.
>>> [...]
>>>  -- Roger Leigh   Tue, 05 Apr 2011 10:46:49
>>> +0100
>>
>> `
>>
>> Which did not help, because the changelog is not actually identical
>> anyway.
> 
> The date from the last sourceful upload should probably still be used
> for any date/time information included in generated files to ensure
> they are identical on all architectures (or at least to try to do so).
> 
> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
> probably be set to the date of the last sourceful upload (instead of
> just using the most recent changelog entry).

There are many differences among different architectures, see e.g.:

lame (3.99.5+repack1-9+b1) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild against ncurses 6.0.

 -- amd64 / i386 Build Daemon (x86-csail-01)
  Thu, 11 Jun 2015 12:33:22 +0200

But that is not a problem as the entry is added to changelog.$arch for this 
reason.

Cheers,
Emilio

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 00:53, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 10:41:09PM +, Ian Jackson wrote:
>> Is this a recommended recipe ?  AIUI a buildd doing a binnmu will not
>> modify the debian/changelog file.
> 
> Are you sure? When last I checked, this was not true (it may have
> changed since, however).

These days, a changelog entry is added to a changelog.$arch. This is to avoid
problems when co-installing ma:same packages, as the changelog entries will/may
differ between different architectures.

Cheers,
Emilio

Re: misleading timestamps in binnmus

[Ansgar Burchardt]

On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
> > It seems that sbuild indeed re-uses the timestamp from the last
> > debian/changelog entry in the binNMU changelog entry.
> 
> This has been done in an early attempt to make binNMUs co-installable 
> in a multiarch world:
> 
> ,
> > sbuild (0.62.2-1) unstable; urgency=low
> > [...]
> > - Improve binNMU handling to permit binNMUs for multiarch
> > packages
> >   (Closes: #620112).  Currently, binary NMUs use the current
> > date
> >   in the new changelog entry, but co-installable packages
> > require
> >   an identical changelog.  To avoid this, take the date from
> > the
> >   previous changelog entry to ensure the same date for all
> > binNMUs.
> > [...]
> >  -- Roger Leigh   Tue, 05 Apr 2011 10:46:49
> > +0100
> 
> `
> 
> Which did not help, because the changelog is not actually identical
> anyway.

The date from the last sourceful upload should probably still be used
for any date/time information included in generated files to ensure
they are identical on all architectures (or at least to try to do so).

If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
probably be set to the date of the last sourceful upload (instead of
just using the most recent changelog entry).

Ansgar