nodejs 6.9 in unstable, manual transition, schedule

[Jérémy Lal]

Hi,

i really think it would be best to have nodejs 6.9 in next debian release.
That version is currently in experimental and i was about to upload it
to unstable, but i tried to do things right and prepared the addons
that need to be rebuilt and binNMUed, then opened a transition bug
#849505.
No answer yet, people are busy, and the number of concerned packages
is low (a dozen or so), should i just rebuild and upload them myself ?

Jérémy

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

Ian Jackson writes:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> I'm not sure I need "logind integration" in my X server but perhaps I
> do ?

Only if you want to start X as non-root.

> Simon McVittie writes ("Re: "not authorised" doing various desktoppy things"):
>> None of this works unless you have libpam-systemd installed and enabled.
>> That PAM module is somewhat mis-named: it's really for systemd-logind,
>> the user/login manager, and not the systemd init/service manager.
>
> In fact I didn't have libpam-systemd installed for some strange
> reason, but installing it hasn't helped.  (All the symptoms I report
> above are with it installed.)

How did you not have libpam-systemd installed?  network-manager has
Depends: policykit-1 and policykit-1 has Depends: libpam-systemd.

Ansgar

Re: nodejs 6.9 in unstable, manual transition, schedule

[Andrey Rahmatullin]

On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
> i really think it would be best to have nodejs 6.9 in next debian release.
> That version is currently in experimental and i was about to upload it
> to unstable, but i tried to do things right and prepared the addons
> that need to be rebuilt and binNMUed, then opened a transition bug
> #849505.
> No answer yet, people are busy, and the number of concerned packages
> is low (a dozen or so), should i just rebuild and upload them myself ?
The transition freeze was on Nov 5.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: nodejs 6.9 in unstable, manual transition, schedule

[Jérémy Lal]

2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin :
> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
>> i really think it would be best to have nodejs 6.9 in next debian release.
>> That version is currently in experimental and i was about to upload it
>> to unstable, but i tried to do things right and prepared the addons
>> that need to be rebuilt and binNMUed, then opened a transition bug
>> #849505.
>> No answer yet, people are busy, and the number of concerned packages
>> is low (a dozen or so), should i just rebuild and upload them myself ?
> The transition freeze was on Nov 5.

This is not very smart - i'm talking about something that will make future
maintenance and security patches easier, something that is easy to do
and that i can even do alone.
Contrast this with an openssl 1.1 upload few days before the transition freeze.
I don't get it.

Jérémy

Re: Call for testers: logrotate 3.11.0-0.1~exp1

[Matthias Klose]

On 04.01.2017 00:23, Christoph Biedl wrote:
> Hi there,
> 
> as the stretch freeze approaches, I'm getting concerned about the
> status of logrotate, most notably #734688. The maintainer (CC'ed)
> hasn't shown any sign of activity for a while, also no response to a
> private message (I admit, it's been just a few days).
> 
> Since the fix includes switching to a new upstream version, I refrained
> from doing a simple NMU. Instead I've uploaded a new version to
> experimental (as 3.11.0-0.1~exp1) and would appricate tests and
> feedback in the hope major breakage gets gets detected early.
> 
> My plan is to upload to unstable+2 during to weekend.
> 
> From the changelog (more extensive than I'd usually do, to ease review):
> 
>  logrotate (3.11.0-0.1~exp1) experimental; urgency=medium
>  .
>* Non-maintainer upload to experimental
>* New upstream version 3.11.0  Closes: #734688
>* Refresh patch queue
>  - Now upstream:
>+ datehack.patch
>+ mktime-718332.patch
>+ man-su-explanation-729315.patch
>  - deb-config-h.patch: New way to enforce status file location
>* Update watch file. Closes: #844578
>* Update Homepage: information
>* Allow failure in the clean target
>* Fix broken test suite runner

fyi, I NMUed logrotate yesterday to fix #849743, currently in delayed.  Please
add this fix to your upload.

Matthias

Re: Converting to dgit

[Tzafrir Cohen]

On Tue, Jan 03, 2017 at 07:01:22PM -0800, Nikolaus Rath wrote:

> When talking about percentages, I think it's worth keeping in mind the
> 1000% longer that it takes to comprehend a diff of two patches-unapplied
> trees (as gbp produces them) over a diff of two patches-applied trees
> (as git-dpm and dgit with maint-merge workflow produce). I don't
> understand how gbp became so much more popular than git-dpm.

Some minor points and not an attempt for a complete answer:

0. Chances are you'll use gbp to build packages from git. So it is
easier to know gpq pq if you are already familiar with gbp
buildpackage. Anyone wants to either better integrate the two or
re-implement dpm inside gbp? Have gbp (e.g.: dch) behave differently
with either the option --git-dpm or with the presense of the file
debian/.git-dpm?

1. It is more complex. I have a genuine fear of messing it up. Yes, this
applies to git as well, but I long got over it.

2. The price of having patches represented but also representing their
history is a complex history. More complex than it should be if you
don't know how to edit it. Editing it is one point that I could not find
in the man page (which is comprehensive, indeed).

3. No tab completion. Unlike gbp that completes commands well, though
not always in a timely manner. Furthermore, I had to remember to run
'git-dpm --help', as 'git dpm --help' would give me a man page.


Disclaimer: I have hardly used git-dpm in the recent year or so and
switched mostly to gbp-pq. I like the idea, but the implementation was
not comfortable enough for me to work with. And there were also some
arguments of personal preference that don't apply in this discussion.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Re: nodejs 6.9 in unstable, manual transition, schedule

[Jonas Smedegaard]

Quoting Jérémy Lal (2017-01-04 10:12:44)
> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin :
>> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
>>> i really think it would be best to have nodejs 6.9 in next debian release.
>>> That version is currently in experimental and i was about to upload it
>>> to unstable, but i tried to do things right and prepared the addons
>>> that need to be rebuilt and binNMUed, then opened a transition bug
>>> #849505.
>>> No answer yet, people are busy, and the number of concerned packages
>>> is low (a dozen or so), should i just rebuild and upload them myself ?
>> The transition freeze was on Nov 5.
>
> This is not very smart - i'm talking about something that will make 
> future maintenance and security patches easier, something that is easy 
> to do and that i can even do alone.
> Contrast this with an openssl 1.1 upload few days before the 
> transition freeze. I don't get it.

libssl transition was coordinated with the release team well before the 
freeze.

Apart from giving up and let things rest as they are (or fall apart and 
get kicked out), I believe there is also the option of asking the 
release team for permission to do the transition even if late.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#850117: ITP: node-common-path-prefix -- Computes the longest prefix string that is common to each path, excluding the base component

[Ameya Apte]

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

* Package name: node-common-path-prefix
  Version : 1.0.0
  Upstream Author : Mark Wubben (https://novemberborn.net/)
* URL :
https://github.com/novemberborn/common-path-prefix#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Computes the longest prefix string that is common to
each path, excluding the base component

Bug#850121: ITP: node-tough-cookie -- RFC6265 Cookies and Cookie Jar for node.js

[Roshan]

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

* Package name: node-tough-cookie
  Version : 2.3.2
  Upstream Author : Jeremy Stashewsky 
* URL : https://github.com/salesforce/tough-cookie
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : RFC6265 Cookies and Cookie Jar for node.js

Bug#850119: ITP: node-binary-extensions -- List of binary file extensions

[Vivek Bhave]

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

* Package name: node-binary-extensions
  Version : 1.8.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/binary-extensions#readme
* License : Expat
  Programming Lang: JavaScript
  Description : List of binary file extensions

Bug#850118: ITP: node-slice-ansi -- Slice a string with ANSI escape codes

[Sumedh Pendurkar]

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

* Package name: node-slice-ansi
  Version : 0.0.4
  Upstream Author : David Caccavella 
* URL : https://github.com/chalk/slice-ansi#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Slice a string with ANSI escape codes

Bug#850120: ITP: node-clean-yaml-object -- Clean up an object prior to serialization

[Prathamesh Mane]

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

* Package name: node-clean-yaml-object
  Version : 0.1.0
  Upstream Author : James Talmage  (
github.com/jamestalmage)
* URL : https://github.com/tapjs/clean-yaml-object#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Clean up an object prior to serialization

Bug#850123: ITP: node-has-unicode -- Try to guess if your terminal supports unicode

[Yogiraj Kulkarni]

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

* Package name: node-has-unicode
  Version : 2.0.1
  Upstream Author : Rebecca Turner 
* URL : https://github.com/iarna/has-unicode
* License : ISC
  Programming Lang: JavaScript
  Description : Try to guess if your terminal supports unicode

Bug#850127: ITP: node-aws4 -- Signs and prepares requests using AWS Signature Version 4

[Vinay Desai]

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

* Package name: node-aws4
  Version : 1.5.0
  Upstream Author : Michael Hart  (
http://github.com/mhart)
* URL : https://github.com/mhart/aws4#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Signs and prepares requests using AWS Signature Version
4

Bug#850126: ITP: node-aproba -- A rediculously light-weight argument validator

[Tushar Agey]

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

* Package name: node-aproba
  Version : 1.0.4
  Upstream Author : Rebecca Turner 
* URL : https://github.com/iarna/aproba
* License : ISC
  Programming Lang: JavaScript
  Description : A rediculously light-weight argument validator

Bug#850125: ITP: node-ci-info -- Get details about the current Continuous Integration environment

[Siddhesh Rane]

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

* Package name: node-ci-info
  Version : 1.0.0
  Upstream Author : Thomas Watson Steen  (
https://twitter.com/wa7son)
* URL : https://github.com/watson/ci-info
* License : Expat
  Programming Lang: JavaScript
  Description : Get details about the current Continuous Integration
environment

Bug#850122: ITP: node-buf-compare -- Node.js `Buffer.compare()` ponyfill

[nikhil gawande]

Package: node-buf-compare
Severity: wishlist
Owner: Nikhil Gawande 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-buf-compare
  Version : 1.0.1
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/buf-compare#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js `Buffer.compare()` ponyfill

Bug#850130: ITP: node-is-generator-fn -- Check if something is a generator function

[Aarti Kashyap]

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

* Package name: node-is-generator-fn
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/is-generator-fn
* License : Expat
  Programming Lang: JavaScript
  Description : Check if something is a generator function

Bug#850129: ITP: node-onetime -- Ensure a function is only called once

[Tejas Nayak]

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

* Package name: node-onetime
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/onetime#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Ensure a function is only called once

Re: Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Evgeni Golov]

Hey,

On Wed, Jan 04, 2017 at 01:04:12AM +0100, Toni Mueller wrote:
> On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> > Unfortunately, we don't build ansible off of the git repository, but
> > rather from the released tarballs.
> 
> I found them only on PyPI. Did you find them elsewhere?

http://releases.ansible.com/ansible/

> > It's been a while since we made the decision not to pull from upstream's
> > git; Toni, I'd be happy to work with you on seeing if it's doable now.
> 
> Let's get the -doc package into stretch first if it's not too late
> already.

I fear that is too late :(
It would have to be in stretch (not sid) tomorrow, which is not possible
given a 10day migration period.

Regards
Evgeni

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Ansgar Burchardt writes ("Re: "not authorised" doing various desktoppy things 
[and 1 more messages]"):
> Ian Jackson writes:
> > In fact I didn't have libpam-systemd installed for some strange
> > reason, but installing it hasn't helped.  (All the symptoms I report
> > above are with it installed.)
> 
> How did you not have libpam-systemd installed?  network-manager has
> Depends: policykit-1 and policykit-1 has Depends: libpam-systemd.

I'm afraid I don't know for sure.  I think this was probably a
weirdness on my system due to odd things I did to it, and not a bug in
any package dependencies.  When I asked apt-get to install
libpam-systemd, it upgraded a number of other packages.  I don't think
this is worth investigating further.

I think #844785 needs a fix though.  Tips for where to look would be
very welcome.

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.

Bug#850131: ITP: node-is-obj -- Check if a value is an object

[Gaurav Juvekar]

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

* Package name: node-is-obj
  Version : 1.0.1
  Upstream Author : Sindre Sorhus  
(sindresorhus.com)

* URL : https://github.com/sindresorhus/is-obj#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Check if a value is an object

 .
 Node.js is an event-based server-side JavaScript engine.

Bug#850132: ITP: aws-sign2 -- AWS signing. Originally pulled from LearnBoost/knox, maintained as vendor in request, now a standalone module.

[Srushti Chaudhari]

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

* Package name: node-aws-sign2
  Version: 0.6.0
  Upstream Author: Mikeal Rogers  (
http://www.futurealoof.com)
* URL: http://github.com/mikeal/aws-sign#readme
* License: Apache-2.0
  Programming Lang: JavaScript
  Description: AWS signing. Originally pulled from LearnBoost/knox,
maintained as vendor in request, now a standalone module.

Bug#850133: ITP: node-fn-name -- Get the name of a named function

[Shirish Togarla]

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

* Package name: node-fn-name
  Version : 2.0.1
  Upstream Author : Sindre Sorhus  (
http://sindresorhus.com)
* URL : https://github.com/sindresorhus/fn-name
* License : Expat
  Programming Lang: JavaScript
  Description : Get the name of a named function

Bug#850136: ITP: node-asynckit -- Minimal async jobs utility library, with streams support

[Aditya Neralkar]

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

* Package name: node-asynckit
  Version : 0.4.0
  Upstream Author : Alex Indigo 
* URL : https://github.com/alexindigo/asynckit#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Minimal async jobs utility library, with streams support

Bug#850135: ITP: node-asn1 -- Contains parsers and serializers for ASN.1 (currently BER only)

[akshay kemekar]

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

* Package name: node-asn1
  Version : 0.2.3
  Upstream Author : Mark Cavage 
* URL : https://github.com/mcavage/node-asn1
* License : Expat
  Programming Lang: JavaScript
  Description : Contains parsers and serializers for ASN.1 (currently
BER only)

Bug#850137: ITP: node-stringstream -- Encode and decode streams into string streams

[Rushi Bhadane]

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

* Package name: node-stringstream
  Version : 0.0.5
  Upstream Author : Michael Hart  (
http://github.com/mhart)
* URL : https://github.com/mhart/StringStream#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Encode and decode streams into string streams

Bug#850139: ITP: node-assert-plus -- Extra assertions on top of node;s assert module

[saurabhagrawal]

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

* Package name: node-assert-plus
  Version : 1.0.0
  Upstream Author : Mark Cavage 
* URL : https://github.com/mcavage/node-assert-plus#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Extra assertions on top of node's assert module

Re: Feedback on 3.0 source format problems

[Jonas Smedegaard]

Quoting Vincent Bernat (2017-01-04 08:12:08)
>  ❦  4 janvier 2017 04:52 GMT, Scott Kitterman  :
> 
> >>> It's surprisingly awkward, and, at least for me, it turns out that
> >>> externalizing my rebased branch as a patch series solves many of
> >>> problems surprisingly well.  All the other solutions I can think of
> >>> require one or more things I don't really want to do: rebase the
> >>> debian/master branch, not be able to run dpkg-buildpackage from the
> >>> debian/master branch easily, or require that dpkg-buildpackage do
> >>> more mucking about with source control than I want it to.
> >>
> >>I believe the git-dpm approach would give you everything you want.  The
> >>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
> >>
> >>I personally think that technically git-dpm's approach is the best -
> >>but
> >>unfortunately the program itself is effectively unmaintained and
> >>apparently/consequently not used by many people.
> >
> > The Debian Python Modules Team (DPMT) has about 1,000 packages with
> > git-dpm repositories.  While it took a bit of getting used to and
> > there have been a few problems, overall I think it's worked very well.
> > It's biggest problem is the lack of a maintainer.
> 
> There have been a lot of complaints about it. For me, it is a pain to
> use. Its integration with gbp is poor, it produces a messy history when
> you are working on your patches and I often run into problems with
> .debian/.git-dpm file it maintains (import a new upstream, make some
> changes, notice that somebody else also pushed a change, pull --rebase,
> everything is broken). Since we started using it, we opened a lot of bug
> reports and not a single one of them has been fixed. I think that nobody
> wants to work on it because it is an extremely fragile tool and the
> first one to try to fix it will inherit of all the problems to solve.
> 
> Isn't "gbp pq" a correct execution of the same principles?
> -- 
> Make your program read from top to bottom.
> - The Elements of Programming Style (Kernighan & Plauger)

Do _any_ of the systems reliably handle a "git rebase" involving a merge 
of new upstream release?  In my experience gbp also fails that.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#850140: ITP: node-delegates -- delegate methods and accessors to another property

[Nupur Malpani]

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

* Package name: node-delegates
  Version : 1.0.0
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/node-delegates#readme
* License : Expat
  Programming Lang: JavaScript
  Description : delegate methods and accessors to another property

Re: Converting to dgit

[Sean Whitton]

Hello,

On Tue, Jan 03, 2017 at 04:33:39PM -0800, Russ Allbery wrote:
> Curating a patch series is only 5% slower than commiting directly to the
> Git repository to me.  I just have to remember to gbp pq import before
> making new changes, gbp pq export when I'm done, and once in a great while
> I have to do a small bit of rebasing to merge changes back into other
> patches.  It's quite easy for someone who is very familiar with Git, using
> good tools.  That 5% would be even less if I did it more often.

Development of most software involves diverging branches of development
that have to be merged into each other at various points and for various
reasons.  To my mind, Debian's patching of upstream source is just
another kind of branching, parts of which will hopefully be merged back,
and parts of which never will be.

Most git-using upstreams handle this divergence and merging with
standard git tools.  Using workflows like dgit-maint-merge(7), we can
handle our Debian divergence and merging in just the same way.  You can
use gbp-pq to curate a series of patches.  But then we're singling out
the Debian branch as somehow special and inconvenient.  We wouldn't
suggest an upstream developer working on a feature branch use gbp-pq...

I'm grateful that you've noted in this discussion that you find `gbp pq
import` and `gbp pq export` not to be burdensome.  However, while I
haven't had nearly as much experience as you, I have to add that I find
gbp-pq to be a complete pain.  I just want to switch to a new git
branch, iterate on my problem with as much committing as I need, and
then merge back (possibly with --squash).  This takes up so much fewer
of my brain cycles.

(this is not to say that gbp-pq isn't a cool piece of software -- dgit
uses it internally, for one thing)

On Tue, Jan 03, 2017 at 06:50:53PM -0800, Nikolaus Rath wrote:
> On Jan 03 2017, Sean Whitton  wrote:
> > On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote:
> >> I still haven't really made up my mind if I want to use git-maint-merge
> >> or git-dpm. Russ recently raised a valid point with the Debian
> >> modifications over-time becoming all tangled up and impossible to
> >> separate.
> >
> > I also read Russ's e-mail, but I'm not yet convinced that powerful tools
> > like `git diff` and `git log` won't be able to give you the information
> > you need pretty quickly.
> 
> Can you give an example? Eg if I have to Debian patched that both
> produced merge conflicts at some point, how do I disentangle them into
> two separate patches with just git log and git diff?

Use the `git log` command I gave previously, and cherry-pick the commits
you want.  Thanks to the merges, they won't apply cleanly, and you'll
have to manually resolve the cherry-picks.  However, as evidenced by
Russ's examples, manual resolution will always be required in these
sorts of cases, and git minimises the amount of it you have to do.

> > It might take a little time to craft the right command, but that is
> > easily outweighed by the time saved curating a patch series.
> 
> Well - that is obviously very much dependent on the git-fu of the person
> doing the work.

Yes, fair enough, this is moderately advanced git-fu.

On Tue, Jan 03, 2017 at 07:36:46PM -0800, Russ Allbery wrote:
> That said, gbp pq does something else I really like, namely it exports in
> the source package all of the metadata that anyone else would need to pick
> up the package without needing a copy of my Git repository (except for
> history).

On Wed, Jan 04, 2017 at 12:52:44AM +, Scott Kitterman wrote:
> And the thing that gets source delivered to users is the source
> package, not a git repository.  A proper set of patches is far more
> understandable than an undifferentiated pile of diff.
> 
> Sometimes I feel like people lose track of the fact that the VCS is a
> means to an end and not the end target of the work we're doing.

The official dgit-repos fixes both these issues.

`dgit clone foo jessie,-security` is at least a good a way of delivering
source to users as `apt-get source`.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Ian Jackson]

Russ Allbery writes ("Re: Feedback on 3.0 source format problems"):
> Even if we never used tarballs, and instead our unit of operation was the
> upstream Git repository plus Debian branches, I would maintain a rebased
> branch of Debian changes to upstream

I think this is definitely the right thing for many packages.

I don't think this depends on the interchange format representing the
changes as patches rather than commits.  At a technical level, they
represent roughly the same information and it is possible to
interconvert.  However:

  * There are many changes that patches cannot represent.

  * git (working with a rebasing branch) is a much more powerful tool
for editing a patch series than quilt or diff/patch or emacs
(working with a series of patches as files).  Ie, patches are a
poor editing format.  Consequently most people actually gateway to
git at the first opportunity, and out again for export.

  * Few people outside Debian work with quilt stacks any more.

All of these things mean that patches are a really poor interchange
format.

The only difficulty is this one:

> This is actually, in a way, *harder* if we were using pure Git, since if I
> have a rebased branch of Debian changes on top of upstream, and I need a
> place to integrate that with Debian packaging, what does that
> debian/master branch look like?  I don't really want it to be a constantly
> rebased branch; I want it to be a conventional branch.  But I want to keep
> merging the changes against upstream into it (but not maintain them on
> that branch, only maintain the Debian packaging files on that branch).

My preferred answer is that it is a constantly rebasing branch topped
with a series of pseudomerges to make it fast-forwarding.

git-dpm sort of does this.  I have been experimenting with and
blundering towards another approach, which is closer to raw git.

Something like this:

 --/--A-/---B3---/--> interchange view
  ///
 //3
///
   222
  ///
 111
///
---p-p--Ap---B---> `packaging-only' branch
  / /   /
   --#-#---#-> upstream

Key:   1,2,3   commits touching upstream files
   A,B commits touching debian/ only
   B3  mixed commit (eg made by an NMUer)
   #   upstream releases

  -p-  special merge, takes contents of debian/
  /  from the previous `packaging only'
 commit and rest from upstream

  -/-  pseudomerge; contents are identical to
  / parent lower on diagram.

Looking from the tip of the interchange view, it is I think always
possible to classify these commits appropriately: pseudomerges are
fairly obvious (if all three trees are identical, we descend to the
parent with the most recent commit date), and the `p' special merge is
the only non-psuedo merge and has a special form.

So it would be possible to write a `git-debian-rebase' tool which
would take (for example) B3, above, and be able to perform functions
like:

 * Strip pseudomerges: Rewrite the current branch so it contains no
   pseudomerges, turning ...B3 into ...p-A-1-2-B3.  (This should make
   a note, in your .git/ somewhere, of the latest pseudomerge to be
   deleted.)

 * Cleanup branch: Reorganise the current branch so that the debian/
   changes come first, turning -p-A-1-2-B3 into ...p-A-B-1-2.

 * New upstream rebase: Start rebasing onto a new upstream version,
   turning ...#...p-A-B-1-2 into ...#'...p'-1-2.  This would be a
   wrapper around git-rebase, which prepares p' and then tries to
   rebase 1 2 onto p'.  So if you ask for an interactive rebase p'
   doesn't appear in your commit list.

   Note that the rebasing of p into p' cannot fail because p' simply
   copies debian/ from B and and everything else from #'.  (Rebasing A
   and B is undesirable.  We want the debian/ files to be non-rebasing
   so we can `git log' and get the packaging history.)

 * Record pseudomerge.  This is like "committing" your patch queue.
   The LH parent is taken from the previous strip pseudomerge.  (We
   should probably check that this is consistent with what we see in
   debian/changelog, but that is not a sufficient check.)

Maybe some of these operations should automatically edit
debian/changelog.

The only thing that this can't easily do is permit nonlinear (ie,
merging) history on the `packaging-only' branch, because upstream
might contain debian/ files too, so it is not possible to distinguish
a merge of two `packaging-only' branches from the special merge `p'.
(Indeed I since upstream might copy debian/ from us, I think it is not
easy to reliably distinguish the two parents of a `p'.  In the most
exciting edge case, upstream might `git merge' a previous i

Re: Converting to dgit

[Ian Jackson]

Nikolaus Rath writes ("Re: Converting to dgit"):
> I still haven't really made up my mind if I want to use git-maint-merge
> or git-dpm. Russ recently raised a valid point with the Debian
> modifications over-time becoming all tangled up and impossible to
> separate. I thought I could solve this with git-debcherry, but that
> seems to be more of a technology demo than an actual solution (it's
> getting noticebly slow even on a small test tree and is implemented in
> 330 lines of bash...).

Mmmm.  I do agree actually with Russ about this more than I do with
Sean.  I agree that for many packages keeping a rebasing patch stack
is very desirable.  Where I disagree with Russ is how we should store
and exchange that patch stack.  I think we should do that by suitable
git trickery rather than by exporting and reimporting as patches.

> Incidentally, where would you like to see dgit discussions? On the bug
> tracker, or on debian-devel? I'm surprised that there is no dgit mailing
> list.

We have been occasionally using
vcs-pkg-disc...@lists.alioth.debian.org for development type
discussions.  There isn't really a user-focused list.  I'm happy to
have the conversation here if others don't mind.

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.

Bug#850152: ITP: node-tweetnacl -- Port of TweetNaCl cryptographic library to JavaScript

[Yashashree Kolhe]

Package: tweetnacl
Severity: wishlist
Owner: Yashashree Kolhe 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-tweetnacl
  Version : 0.14.5
  Upstream Author : TweetNaCl-js contributors
* URL : https://tweetnacl.js.org
* License : Unlicense
  Programming Lang: JavaScript
  Description : Port of TweetNaCl cryptographic library to JavaScript

Re: Feedback on 3.0 source format problems

[Scott Kitterman]

On January 4, 2017 6:23:23 AM EST, Jonas Smedegaard  wrote:
>Quoting Vincent Bernat (2017-01-04 08:12:08)
>>  ❦  4 janvier 2017 04:52 GMT, Scott Kitterman
> :
>> 
>> >>> It's surprisingly awkward, and, at least for me, it turns out
>that
>> >>> externalizing my rebased branch as a patch series solves many of
>> >>> problems surprisingly well.  All the other solutions I can think
>of
>> >>> require one or more things I don't really want to do: rebase the
>> >>> debian/master branch, not be able to run dpkg-buildpackage from
>the
>> >>> debian/master branch easily, or require that dpkg-buildpackage do
>> >>> more mucking about with source control than I want it to.
>> >>
>> >>I believe the git-dpm approach would give you everything you want. 
>The
>> >>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>> >>
>> >>I personally think that technically git-dpm's approach is the best
>-
>> >>but
>> >>unfortunately the program itself is effectively unmaintained and
>> >>apparently/consequently not used by many people.
>> >
>> > The Debian Python Modules Team (DPMT) has about 1,000 packages with
>> > git-dpm repositories.  While it took a bit of getting used to and
>> > there have been a few problems, overall I think it's worked very
>well.
>> > It's biggest problem is the lack of a maintainer.
>> 
>> There have been a lot of complaints about it. For me, it is a pain to
>> use. Its integration with gbp is poor, it produces a messy history
>when
>> you are working on your patches and I often run into problems with
>> .debian/.git-dpm file it maintains (import a new upstream, make some
>> changes, notice that somebody else also pushed a change, pull
>--rebase,
>> everything is broken). Since we started using it, we opened a lot of
>bug
>> reports and not a single one of them has been fixed. I think that
>nobody
>> wants to work on it because it is an extremely fragile tool and the
>> first one to try to fix it will inherit of all the problems to solve.
>> 
>> Isn't "gbp pq" a correct execution of the same principles?
>> -- 
>> Make your program read from top to bottom.
>> - The Elements of Programming Style (Kernighan & Plauger)
>
>Do _any_ of the systems reliably handle a "git rebase" involving a
>merge 
>of new upstream release?  In my experience gbp also fails that.

My experience with git-dpm, including with packages that have stacked 
patches/commits, is that it's pretty reliable, although not perfect. In the 
end, most, if not all the problems I've had turned out to be pilot error.

Scott K

Re: Converting to dgit

[Simon McVittie]

On Tue, 03 Jan 2017 at 22:17:33 -0800, Russ Allbery wrote:
> Usually what I have to do (and I think this is a pretty common use case
> for anyone who customizes Debian packages) is that I need to start from a
> package from unstable (or at least newer than stable, or oldstable, or
> ancient Ubuntu, or whatever crap I'm having to work on), apply some local
> patches, and backport it
...
> But what happens
> to me a lot is that [changes] *do* conflict, or maybe the new upstream is a
> completely new version of the package (and then it's pretty much
> guaranteed to conflict).

I think the bottom line here is that what you are doing *is* rebasing: you
are treating the new upstream (or new security-patched downstream)
as the new baseline for your local work, discarding any of your changes
that are no longer necessary, and adjusting the rest to apply on top of
the new version.

That's also what we do as Debian maintainers (and, in my day job, as a
maintainer in a Debian derivative) when we update the patch stack in a
package. You can tell it's (in git terms) a rebase rather than a merge,
because as a community we have spent 20+ years going to significant
effort to separate pristine upstream source from distro changes. We
don't treat upstream and downstream as equivalent: we (IMO correctly)
give the upstream code that we share with other distributions a privileged
position, and often treat downstream changes as a costly thing, to be
tolerated when they're justified, but minimized whenever we can.

> None of this is unique to me or requires any deep knowledge of the Debian
> package format.  It's that individual patches are a way easier unit to
> work with when resolving conflicts than a patched tree.

Yes. There's a reason git users (and git commands) often work in terms
of changesets (the differences between commits) rather than in terms of
the commits themselves, even though git's data model is fundamentally
about commits and trees.

S

Re: Migration despite an RC bug? [and 1 more messages]

[Ian Jackson]

Niels Thykier writes ("Re: Migration despite an RC bug?"):
> An exception in my experience: In process is cheaper when the
> (de)compressor is available in the PerlIO Layer as native C code.
> Notable example being libperlio-gzip-perl where you use "open(my $fd,
> '<:gzip', $file)".
>   At least that was the case when I benchmarked on Lintian in 2.5.10 (2
> releases ago).

Surely this depends a lot on what you are doing with the data.  If the
consumer is doing any significant computation, you save elapsed time
by being able to do decompression and consumption in parallel.

Russ Allbery writes ("Re: Migration despite an RC bug?"):
> Ah, I didn't try that!  I was only playing around with IO::Uncompress.  I
> may have to go revisit that project, since managing the external process
> was a huge pain.

Maybe there should be a library to do the process management.

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: Feedback on 3.0 source format problems

[Simon McVittie]

On Wed, 04 Jan 2017 at 13:59:26 +0800, Paul Wise wrote:
> On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote:
> > But I am not sure if a package structure like
> >
> > mypkg/upstream/*
> > mypkg/debian/*
> > mypkg/patches/* (?)
> >
> > would have any *practical* benefits over the current situation
> 
> TBH, I haven't thought much about what an alternative should look like.

We could have a directory containing a tarball, some patches, and some
sort of spec for how to build it? I hear some people with brightly-coloured
headgear might have tried this particular design :-P

Joking aside, the attempts I've seen at managing SRPMs in a version
control system have either not tracked upstream source at all (Fedora), or
invented a layout that is actually a lot like Debian's but with packaging/
instead of debian/ (Tizen).

S

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Simon McVittie]

On Wed, 04 Jan 2017 at 02:10:56 +, Ian Jackson wrote:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> > Check if your session is marked as active and local
> > $ loginctl show-session $XDG_SESSION_ID
> 
> I see (amongst other things):
> 
>   Remote=no
>   Active=yes
>   State=active

Looks like the situation where polkit should allow most things.

If you were using the systemd service (and cgroup) manager, I'd ask you
to run `systemd-cgls` and/or `loginctl user-status` to visualize the
hierarchy of processes and cgroups that logind would use to match
processes to sessions, specifically looking for the process that you
think should be allowed to communicate with NetworkManager or udisks2
or other privileged services; but I don't know whether that works under
systemd-shim.

> I have frankly no idea what to expect from the
> communication between systemd-shim and systemd-logind

Mostly D-Bus, I think? Arranging for `dbus-monitor --system` to be run
as root and directed to a log before you log in might be useful. (To
work properly this requires at least stretch's version of dbus.)

> or even where to look for logs

If you were using systemd, the answer would be the Journal, or the
human-readable subset of the Journal that ends up in syslog. But you're
not, so I don't know. syslog? /proc/kmsg?

> I found this in my .xsession-errors:
> 
>  dbus-update-activation-environment: systemd --user not found, ignoring 
> --systemd argument

That should be harmless: I don't think systemd-shim is meant to start
systemd --user.

If you were using the full systemd suite, logind would have asked the
system service manager (/lib/systemd/systemd, pid 1, uid 0) to start a
user service manager (/lib/systemd/systemd --user, pid > 1, your own
uid) on your behalf, and dbus-update-activation-environment would have
communicated with the user service manager to update its idea of what
the environment should be to include whatever came from your Xsession.d.
That's a secondary function: d-u-a-e's main job is to communicate with
dbus-daemon --session to do the same thing.

polkit interactions are about system-level functionality (pid 1,
dbus-daemon --system, *dm, PAM), and not about what happens among
an individual user's processes (systemd --user, dbus-daemon --session,
.xinitrc or equivalent).

S

Re: Feedback on 3.0 source format problems

[Tzafrir Cohen]

On Wed, Jan 04, 2017 at 12:53:12PM +, Simon McVittie wrote:

> Joking aside, the attempts I've seen at managing SRPMs in a version
> control system have either not tracked upstream source at all (Fedora), or
> invented a layout that is actually a lot like Debian's but with packaging/
> instead of debian/ (Tizen).

>From what I see, at least some people in Fedora to start putting the
files in version control: tito[1] indeed maintains data in .tito in
addition to the toplevel $PACKAGE.spec file.

[1] https://github.com/dgoodwin/tito

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Re: Converting to dgit

[Nikolaus Rath]

On Jan 04 2017, Sean Whitton  wrote:
>> > I also read Russ's e-mail, but I'm not yet convinced that powerful tools
>> > like `git diff` and `git log` won't be able to give you the information
>> > you need pretty quickly.
>> 
>> Can you give an example? Eg if I have to Debian patched that both
>> produced merge conflicts at some point, how do I disentangle them into
>> two separate patches with just git log and git diff?
>
> Use the `git log` command I gave previously, and cherry-pick the commits
> you want.  Thanks to the merges, they won't apply cleanly, and you'll
> have to manually resolve the cherry-picks.  However, as evidenced by
> Russ's examples, manual resolution will always be required in these
> sorts of cases, and git minimises the amount of it you have to do.

No, that's a misunderstanding.

"The information I need" is the Debian-specific modifications to the
current upstream source, separated into logically independent patches.

Having separate patches in debian/patches gives me this information very
quickly.

Having to run git log, and then to manually merge the the commits gives
me the same information, but it is not "very quickly".


This is the drawback of the single-debian-patch approach. The fact that
the patches are available in individual Git commits no longer helps
after a few merges.


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: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 04 2017, Vincent Bernat  wrote:
>  ❦  4 janvier 2017 04:52 GMT, Scott Kitterman  :
>
 It's surprisingly awkward, and, at least for me, it turns out that
 externalizing my rebased branch as a patch series solves many of
 problems surprisingly well.  All the other solutions I can think of
 require one or more things I don't really want to do: rebase the
 debian/master branch, not be able to run dpkg-buildpackage from the
 debian/master branch easily, or require that dpkg-buildpackage do
 more mucking about with source control than I want it to.
>>>
>>>I believe the git-dpm approach would give you everything you want.  The
>>>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>>>
>>>I personally think that technically git-dpm's approach is the best -
>>>but
>>>unfortunately the program itself is effectively unmaintained and
>>>apparently/consequently not used by many people.
>>
>> The Debian Python Modules Team (DPMT) has about 1,000 packages with
>> git-dpm repositories.  While it took a bit of getting used to and
>> there have been a few problems, overall I think it's worked very well.
>> It's biggest problem is the lack of a maintainer.
>
> There have been a lot of complaints about it. For me, it is a pain to
> use. Its integration with gbp is poor,

Well, I think that is because it is mostly an *alternative* to
gbp. Other than gbp dch (which I think should work fine), what features
of gbp would you like to use with git-dpm?

> Since we started using it, we opened a lot of bug reports and not a
> single one of them has been fixed. I think that nobody wants to work
> on it because it is an extremely fragile tool and the first one to try
> to fix it will inherit of all the problems to solve.

Yes, I think that falls under "lack of a maintainer".
>
> Isn't "gbp pq" a correct execution of the same principles?

No, absolutely not.

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: Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

On Tue, Jan 03, 2017 at 09:14:59PM -0500, Harlan Lieberman-Berg wrote:
> Toni Mueller  writes:
> > I found them only on PyPI. Did you find them elsewhere?
> 
> We get them from releases.ansible.com.  Are the docs in the tarballs in
> PyPi?

Nope, there are only man pages.


Cheers,
--Toni++

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Michael Biebl]

Am 04.01.2017 um 12:07 schrieb Ian Jackson:
> I think #844785 needs a fix though. 

Agreed. Does anyone who uses sysvinit want to look into this?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Request for help - scilab segfaults with TSX

[Gilles Filippini]

Control: tag -1 + help

Hi,

On Wed, 28 Dec 2016 02:23:24 +0200 Adrian Bunk  wrote:
> This looks like a threading bug in Scilab exposed by TSX.

I've just noticed this RC bug [1] against scilab. After reading through
the recent thread on this subject [2] I must admit I have no clue what
to do.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
[2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210

I don't have access to any box with TSX enabled, and failed to find any
porterbox as well. Would building with '-fsanitize=thread' expose the
bug on a TSX disabled box?

Thanks in advance for any piece of advice,

_g.



signature.asc
Description: OpenPGP digital signature

Re: Request for help - scilab segfaults with TSX

[Samuel Thibault]

Hello,

Gilles Filippini, on Wed 04 Jan 2017 19:31:28 +0100, wrote:
> On Wed, 28 Dec 2016 02:23:24 +0200 Adrian Bunk  wrote:
> > This looks like a threading bug in Scilab exposed by TSX.
> 
> I've just noticed this RC bug [1] against scilab.

FYI, glibc is about to just disable TSX entirely in version 2.24-9,
which will just get rid of the issue for Stretch.

Samuel

Re: Request for help - scilab segfaults with TSX

[Ian Jackson]

Gilles Filippini writes ("Request for help - scilab segfaults with TSX"):
> Control: tag -1 + help
...
> I've just noticed this RC bug [1] against scilab. After reading through
> the recent thread on this subject [2] I must admit I have no clue what
> to do.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
> [2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210
> 
> I don't have access to any box with TSX enabled, and failed to find any
> porterbox as well. Would building with '-fsanitize=thread' expose the
> bug on a TSX disabled box?

Have you tried helgrind ?

I'm afraid the TSX-enabled machine I had before is a laptop belonging
to my partner and I can't really borrow it for debugging scilab.

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: Migration despite an RC bug?

[Margarita Manterola]

Hi,

On Fri, Dec 30, 2016 at 5:25 AM, Emilio Pozuelo Monfort 
wrote:

> We thought about rolling back to the previous state, but that means testing
> users who have already upgraded would need to manually downgrade... which
> is not
> good.
>
> So we may just wait for the auto-removal hinter to do its job for
> non-key-packages, and for the rest to be fixed or manually downgraded, or
> whatever other solution...
>

Can we accelerate the removal of non key packages, please?

One example: https://tracker.debian.org/pkg/libsigc++-1.2 migrated to
testing on Dec 29th even though it has an RC bug that was intended to keep
it out of it.

For whatever unexplicable reason, this package is marked "Priority:
important" which means that it gets installed by debootstrap (and, at least
with my preseeds, makes the installation fail).

-- 
Besos,
Marga

Re: Feedback on 3.0 source format problems

[Vincent Bernat]

 ❦  4 janvier 2017 09:47 -0800, Nikolaus Rath  :

> It's surprisingly awkward, and, at least for me, it turns out that
> externalizing my rebased branch as a patch series solves many of
> problems surprisingly well.  All the other solutions I can think of
> require one or more things I don't really want to do: rebase the
> debian/master branch, not be able to run dpkg-buildpackage from the
> debian/master branch easily, or require that dpkg-buildpackage do
> more mucking about with source control than I want it to.

I believe the git-dpm approach would give you everything you want.  The
explanation on http://git-dpm.alioth.debian.org/ is pretty good.

I personally think that technically git-dpm's approach is the best -
but
unfortunately the program itself is effectively unmaintained and
apparently/consequently not used by many people.
>>>
>>> The Debian Python Modules Team (DPMT) has about 1,000 packages with
>>> git-dpm repositories.  While it took a bit of getting used to and
>>> there have been a few problems, overall I think it's worked very well.
>>> It's biggest problem is the lack of a maintainer.
>>
>> There have been a lot of complaints about it. For me, it is a pain to
>> use. Its integration with gbp is poor,
>
> Well, I think that is because it is mostly an *alternative* to
> gbp. Other than gbp dch (which I think should work fine), what features
> of gbp would you like to use with git-dpm?

gbp import-orig --uscan (the whole import with git-dpm is flawed, there
are too many ways to fail, like a patch that cannot be rebased and the
pristine-tar branch is not updated, like the previous upstream was not
tagged because not released [and git-dpm only tags upstream when master
is tagged] and it fails in the middle of the process, gbp rollbacks when
there is a problem).
-- 
Few things are harder to put up with than the annoyance of a good example.
-- "Mark Twain, Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Bug#850182: Please disable TSX in stretch and backport to jessie

[Ian Jackson]

Package: eglibc

Gilles Filippini writes ("Request for help - scilab segfaults with TSX"):
> I've just noticed this RC bug [1] against scilab. [...]
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
> [2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210
...
> I don't have access to any box with TSX enabled, and failed to find any
> porterbox as well. [...]

amd64 with TSX is for the purposes of pthreads like a new
architecture: the locking primitives behave differently and expose
extra bugs.

These extra bugs will be discovered only by chance (as we see in that
bug report and in the earlier bugs #843324 and maybe #842796).  As
more TSX-capable hardware becomes available, we will discover more of
them, during the life of stretch, when they are hard to fix.

Also, we don't have the capability to debug them.  I don't think we
can have a release architecture for stretch that has no porterboxes.

So please would the libc be changed not to make use of these features
for stretch.  The downsides will be somewhat lower performance and
not detecting some preexisting bugs; but the upsides are not shipping
undetected bugs, and not throwing useful software out of Debian.

Please would you make a decision quickly.

Regards,
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: Request for help - scilab segfaults with TSX

[Ian Jackson]

Control: severity 844134 normal

Samuel Thibault writes ("Re: Request for help - scilab segfaults with TSX"):
> Gilles Filippini, on Wed 04 Jan 2017 19:31:28 +0100, wrote:
> > On Wed, 28 Dec 2016 02:23:24 +0200 Adrian Bunk  wrote:
> > > This looks like a threading bug in Scilab exposed by TSX.
> > 
> > I've just noticed this RC bug [1] against scilab.
> 
> FYI, glibc is about to just disable TSX entirely in version 2.24-9,
> which will just get rid of the issue for Stretch.

Oh, hooray!  I have just filed a bug requesting just that.

That means #844134 isn't an FTBFS in scilab any more either.

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: Request for help - scilab segfaults with TSX

[Gilles Filippini]

On 2017-01-04 19:51, Samuel Thibault wrote:

Hello,

Gilles Filippini, on Wed 04 Jan 2017 19:31:28 +0100, wrote:

On Wed, 28 Dec 2016 02:23:24 +0200 Adrian Bunk  wrote:
> This looks like a threading bug in Scilab exposed by TSX.

I've just noticed this RC bug [1] against scilab.


FYI, glibc is about to just disable TSX entirely in version 2.24-9,
which will just get rid of the issue for Stretch.


Thanks!

_g.

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Michael Biebl writes ("Re: "not authorised" doing various desktoppy things [and 
1 more messages]"):
> Am 04.01.2017 um 12:07 schrieb Ian Jackson:
> > I think #844785 needs a fix though. 
> 
> Agreed. Does anyone who uses sysvinit want to look into this?

Um, me ?  Well, I don't particularly want to but I intend to.
Help from all quarters gratefully accepted.

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: Migration despite an RC bug?

[Michael Biebl]

Am 04.01.2017 um 19:53 schrieb Margarita Manterola:

> Can we accelerate the removal of non key packages, please?
> 
> One example: https://tracker.debian.org/pkg/libsigc++-1.2 migrated to
> testing on Dec 29th even though it has an RC bug that was intended to
> keep it out of it.
> 
> For whatever unexplicable reason, this package is marked "Priority:
> important" which means that it gets installed by debootstrap (and, at
> least with my preseeds, makes the installation fail).

Hm, we should remove this package completely (along with the only
remaining rdep). I'll repurpose #817551 for that.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Migration despite an RC bug?

[Adam D. Barratt]

On Wed, 2017-01-04 at 20:33 +0100, Michael Biebl wrote:
> Am 04.01.2017 um 19:53 schrieb Margarita Manterola:
> 
> > Can we accelerate the removal of non key packages, please?
> > 
> > One example: https://tracker.debian.org/pkg/libsigc++-1.2 migrated to
> > testing on Dec 29th even though it has an RC bug that was intended to
> > keep it out of it.
> > 
> > For whatever unexplicable reason, this package is marked "Priority:
> > important" which means that it gets installed by debootstrap (and, at
> > least with my preseeds, makes the installation fail).
> 
> Hm, we should remove this package completely (along with the only
> remaining rdep). I'll repurpose #817551 for that.

In the meantime I've added a removal hint for the two packages.

Regards,

Adam

Re: Feedback on 3.0 source format problems

[Sebastian Andrzej Siewior]

On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
> Looked at another way, it is trying to be a version control system,
> layered on top of the Debian archive.  But it is only about a quarter
> of a VCS.  There are no formal interfaces to do proper VCS operations.
> If there is a formal interface, it is quilt(1) (which is itself very
> poor.  NB that is not quilt's fault: quilt inevitably has a hard job
> because can't make enough assumptions).

there quilt push, pop and header which seems enough.

> I think if we want to be storing patch queues we should be doing so in
> a real version control system.  Indeed, most people are doing that.
> For now many people are using `3.0 (quilt)' as an interchange format,
> but ideally we would switch to a useable git workflow that did a
> similar thing, and then we could use git as our history interchange
> format.

I read this a few times in this thread that people want the patches in a
VCS. I never saw this a missing feature or requirement on my side. I
usually have git-dpm which creates the quilt series and I try to keep
patches documented. 
Once upstream releases a new version I need to rebase all patches and
this might involve manual handling if the patch(es) don't apply cleanly.
Once that is resolved I have one patch again which I take as-is and can
submit upstream.
I can't think of an example where having a patch history somewhere else
than within the patch itself is useful. My thinking is probably limited
by my workflow :) Would you have an example where and how this could be
usefull?

> 
> Regards,
> Ian.
> 

Sebastian

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 04 2017, Vincent Bernat  wrote:
>  ❦  4 janvier 2017 09:47 -0800, Nikolaus Rath  :
>
>> It's surprisingly awkward, and, at least for me, it turns out that
>> externalizing my rebased branch as a patch series solves many of
>> problems surprisingly well.  All the other solutions I can think of
>> require one or more things I don't really want to do: rebase the
>> debian/master branch, not be able to run dpkg-buildpackage from the
>> debian/master branch easily, or require that dpkg-buildpackage do
>> more mucking about with source control than I want it to.
>
>I believe the git-dpm approach would give you everything you want.  The
>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>
>I personally think that technically git-dpm's approach is the best -
>but
>unfortunately the program itself is effectively unmaintained and
>apparently/consequently not used by many people.

 The Debian Python Modules Team (DPMT) has about 1,000 packages with
 git-dpm repositories.  While it took a bit of getting used to and
 there have been a few problems, overall I think it's worked very well.
 It's biggest problem is the lack of a maintainer.
>>>
>>> There have been a lot of complaints about it. For me, it is a pain to
>>> use. Its integration with gbp is poor,
>>
>> Well, I think that is because it is mostly an *alternative* to
>> gbp. Other than gbp dch (which I think should work fine), what features
>> of gbp would you like to use with git-dpm?
>
> gbp import-orig --uscan (the whole import with git-dpm is flawed, there
> are too many ways to fail, like a patch that cannot be rebased and the
> pristine-tar branch is not updated, like the previous upstream was not
> tagged because not released [and git-dpm only tags upstream when master
> is tagged] and it fails in the middle of the process, gbp rollbacks when
> there is a problem).

I agree that's a mess. But I would much rather see the git-dpm import
fixed than interoperability with gbp increased.

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: Converting to dgit

[Russ Allbery]

Simon McVittie  writes:

> I think the bottom line here is that what you are doing *is* rebasing:
> you are treating the new upstream (or new security-patched downstream)
> as the new baseline for your local work, discarding any of your changes
> that are no longer necessary, and adjusting the rest to apply on top of
> the new version.

Sort of, but here's the tricky part: I want to rebase the upstream
changes, but I want to merge the Debian changes, because merging usually
works better there than rebasing.  I also don't want this represented as a
rebase because I'd like to git pull my new archive in various places
without having to delete and recreate my branch.

I agree that there's nothing special about patches for this, and you can
do the whole thing with pure Git (and indeed that seems to basically be
what git-dpm does: rebase the upstream patches and merge the packaging).
I think the question of whether you do the rebasing via manipulating
patches or via git rebase on a specially-created branch for that purpose
is something of a matter of taste.  I find fiddling with patches with the
help of gbp pq to be more straightforward and comprehensible; other people
will be more comfortable with git rebase -i and friends.

The important part to me isn't so much the precise set of tools as it is
that people not push me into merging when I want to rebase (because I
think rebase is the better strategy), and that I can make available the
rebased patches in some easily interchangeable form both upstream and
downstream.

Everyone understands patches, so patches are a really nice export format
to achieve that latter goal.  I don't have any technical support
conversations about how to deal with the patches.  In theory, a rebased
Git branch should be equally accessible, and has some practical
advantages, but I do still work with upstreams who use Subversion, and I
*know* patches work.

-- 
Russ Allbery (r...@debian.org)   

Bug#850195: ITP: extinction -- Fast interstellar dust extinction laws

[Florian Rothmaier]

Package: wnpp
Severity: wishlist

* Package name: Extinction
  Version : 0.3.0
  Upstream Author : Kyle Barbary 
* URL : https://github.com/kbarbary/extinction
* License : MIT
  Programming Lang: Python/Cython
  Description : Fast interstellar dust extinction laws

Extinction provides a library with Cython-optimised implementations of
empirical dust extinction laws found in the astronomical literature.

This library is a dependency of the sncosmo software. Hence packaging
Extinction is a prerequisite of packaging sncosmo.

It will be maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [1].

Best regards,

Florian

[1] https://anonscm.debian.org/cgit/debian-astro/packages/extinction.git

Re: Feedback on 3.0 source format problems

[Brian May]

Vincent Bernat  writes:

> There have been a lot of complaints about it. For me, it is a pain to
> use. Its integration with gbp is poor, it produces a messy history when
> you are working on your patches and I often run into problems with
> .debian/.git-dpm file it maintains (import a new upstream, make some
> changes, notice that somebody else also pushed a change, pull --rebase,
> everything is broken). Since we started using it, we opened a lot of bug
> reports and not a single one of them has been fixed. I think that nobody
> wants to work on it because it is an extremely fragile tool and the
> first one to try to fix it will inherit of all the problems to solve.

It also has a number of bugs that are not getting fixed.

Plus if conflicts occur because multiple people unexpectedly make
changes at the same time it (i.e. you can't push because somebody else
already pushed changes) can be a world of confusion trying to sort out
the mess. I have had to sort out the mess when the Debian package upload
did not match my git tree because another maintainer didn't correctly
merge in my changes.

I believe there is increasing feeling that DPMT should switch away from
git dpm. I think at least one project has already done so. Just nobody
has raised the issue on the mailing list, or come up with an proposal to
change yet.

> Isn't "gbp pq" a correct execution of the same principles?

No, my understanding that is git pq is something quite different, and
does not maintain the history of changes in git - except by commiting
the debian/patches/* files. It is a while since I looked at this in
depth however.

"gbp pq" is probably way better then using quilt however.
-- 
Brian May 

um:

[CHESTER PHILLIPS]

http://houstonknanayacatholics.com/xuowwnd.php





























...A happy life consists in tranquillity of 
mind.Kelsi Guillemette

Re: Feedback on 3.0 source format problems

[Russ Allbery]

Brian May  writes:

> No, my understanding that is git pq is something quite different, and
> does not maintain the history of changes in git - except by commiting
> the debian/patches/* files. It is a while since I looked at this in
> depth however.

That's correct.  gbp pq is equivalent to maintaining the upstream patches
as a Git branch that you rebase against each new upstream version.  You
retain some history of changes to those commits (unlike a pure git rebase
branch) in commit messages of the exported patches, but only as the commit
messages on commits of diffs (so not hugely human-readable).

> "gbp pq" is probably way better then using quilt however.

I like it because quilt is a fairly primitive revision control system, so
while it has tools for rebasing patches, they're not very good compared to
git rebase.

-- 
Russ Allbery (r...@debian.org)   

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 05 2017, Brian May  wrote:
> Vincent Bernat  writes:
>
>> There have been a lot of complaints about it. For me, it is a pain to
>> use. Its integration with gbp is poor, it produces a messy history when
>> you are working on your patches and I often run into problems with
>> .debian/.git-dpm file it maintains (import a new upstream, make some
>> changes, notice that somebody else also pushed a change, pull --rebase,
>> everything is broken). Since we started using it, we opened a lot of bug
>> reports and not a single one of them has been fixed. I think that nobody
>> wants to work on it because it is an extremely fragile tool and the
>> first one to try to fix it will inherit of all the problems to solve.
>
> It also has a number of bugs that are not getting fixed.

Yeah, I think we heard before that git-dpm is not being maintained. I
said it, Vincent said it in his reply, and now you are saying it
again. No one is disputing the point.

> Plus if conflicts occur because multiple people unexpectedly make
> changes at the same time it (i.e. you can't push because somebody else
> already pushed changes) can be a world of confusion trying to sort out
> the mess.

Yes, it is a mess. But I don't think it's any worse than having to
resolve conflicts in debian/patches/, which is the equivalent problem
when multiple people use gbp at the same time.

> I have had to sort out the mess when the Debian package upload
> did not match my git tree because another maintainer didn't correctly
> merge in my changes.

I don't understand... how does a Debian package upload affect any of the
work on your git-dpm tree?


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: Feedback on 3.0 source format problems

[Brian May]

Nikolaus Rath  writes:

>> I have had to sort out the mess when the Debian package upload
>> did not match my git tree because another maintainer didn't correctly
>> merge in my changes.
>
> I don't understand... how does a Debian package upload affect any of the
> work on your git-dpm tree?

I can't remember the exact details now. However I suspect that some
people get so frustrated with git dpm problems and end up using "git
push -f" to fix them up. I think a maintainer may have missed the fact
that I had made changes, and did a "git push -f" without noticing he was
creating a new fork without my changes. Which caused no end of confusion
- I can see my changes in my git tree, but they didn't appear in Debian
upload.

I think the problems git-dpm can create can result in bad habbits - with
people rushing to fix problems without understanding what the underlying
cause was, that can lead to this sort of thing.
-- 
Brian May 

Re: armel after Stretch

[Stefan Monnier]

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

FWIW, I just went through a cross-grade of a Lil'Debi chroot from armel
to armhf.  I wouldn't recommend it to someone who's not used to command
line use of dpkg and apt.  But it worked nicely in the end (the
get-selection/set-selection step seemed to create trouble more than
anything, OTOH).


Stefan

Bug#850218: ITP: node-pinkie -- Itty bitty little widdle twinkie pinkie ES2015 Promise implementation

[Roshan]

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

* Package name: node-pinkie
  Version : 2.0.4
  Upstream Author : Vsevolod Strukchinsky  (
github.com/floatdrop)
* URL : https://github.com/floatdrop/pinkie
* License : Expat
  Programming Lang: JavaScript
  Description : Itty bitty little widdle twinkie pinkie ES2015 Promise
implementation

Bug#850220: ITP: node-get-port -- Get an available port

[Nupur Malpani]

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

* Package name: node-get-port
  Version : 2.1.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/get-port
* License : Expat
  Programming Lang: JavaScript
  Description : Get an available port

Bug#850222: ITP: node-plur -- Pluralize a word

[Abhishek Lolage]

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

* Package name: node-plur
  Version : 2.1.2
  Upstream Author : Sindre Sorhus  (sindresorhus.com)

* URL : https://github.com/sindresorhus/plur
* License : Expat
  Programming Lang: JavaScript
  Description : Pluralize a word

Re: Bug#734688: Call for testers: logrotate 3.11.0-0.1~exp1

[Christoph Biedl]

Matthias Klose wrote...

> fyi, I NMUed logrotate yesterday to fix #849743, currently in delayed.  Please
> add this fix to your upload.

Thanks for the heads-up, included in ~exp2 I had to do for other
reasons as well.

Christoph


signature.asc
Description: Digital signature